문서유형ㅣ기술정보
분야ㅣ백업/복구
적용제품버전ㅣ7PS02
문서번호ㅣTBATI038
개요
본 문서에서는 Tibero를 운영 시, 예상치 못한 장애로 인해 정상적인 데이터베이스 운영이 어려운 상황이 발생할 경우에 복구를 진행하는 과정에 대해 설명합니다.
방법
1. 복구의 개요
- 복구를 하려면 백업 된 데이터베이스가 있어야 합니다.
- Tibero는 데이터베이스에서 일어나는 모든 변화를 로그 파일에 기록하므로, 백업 이후에 데이터베이스에 일어난 모든 변화에 대해서는 로그를 적용하면 복구할 수 있습니다.
참고
로그 파일에는 commit 되지 않은 Tranaction이 수정한 데이터도 포함되어, 복구할 때 Archive log file과 로그 파일 모두 사용할 수 있습니다.
2. 복구의 과정
1) 데이터 파일에 기록되지 않는 변화를 로그를 사용하여 적용하는 과정
- 데이터 파일에 모든 로그의 변화를 기록하는 과정을 통해서 데이터베이스는 안정된 상태가 됩니다.
- 데이터베이스 운영 상의 특정 시점까지 모든 작업이 반영되고 그 이후의 변화는 발생하지 않아야 합니다.
- 데이터베이스에 정상적인 복구가 이루어져 안정된 상태가 되어야만 기동할 수 있습니다.
2) commit 되지 않는 데이터로 복구하는 과정
- 데이터베이스를 종료할 때 commit 하지 않은 Tranaction이 수정한 내용으로 복구를 진행합니다.
3. 복구의 유형
1) 장애 유형 별 복구 유형(백업이 있을 경우)
| 옵션 | Archive mode | No archive mode | ||
|---|---|---|---|---|
완전 복구 | 불완전 복구 | 완전 복구 | 불완전 복구 | |
| Data file 일부 손상 | O |
|
| O |
| Data file 전체 손상 | O |
|
| O |
| Control file 일부 손상 | O |
| O |
|
| Control file 전체 손상 | O |
| O |
|
| inactive redo log 손상 | O |
| O |
|
| current redo log 손상 |
| O |
| O |
| 전체 redo log 손상 |
| O |
| O |
2) 기동 모드 별 복구
| 기동 모드 | 복구 및 설명 |
|---|---|
| NOMOUNT |
|
| MOUNT |
|
| OPEN |
|
3) 완전 복구와 불완전 복구
완전 복구
- 온라인 로그 파일의 가장 최근 로그까지 모두 반영하는 미디어 복구입니다.
불완전 복구
- 온라인 로그 파일의 최근이 아닌 그 이전의 특정 시점까지 복구하는 것을 의미합니다.
- 불완전 복구 후에는 반드시 RESETLOGS 모드로 Tibero를 기동해야 합니다.
- RESETLOGS는 온라인 로그 파일을 초기화하여 기존에 백업 된 것과 호환이 되지 않으므로, 새롭게 백업을 해야 합니다.
4. 복구의 방법
1) NOARCHIVE MODE 복구 방법
- ARCHIVELOG 모드를 사용하지 않으면 미디어 복구를 할 수 없으므로, 특정 데이터 파일이 손상된 경우 해당 파일의 백업으로부터 복구하는 과정만이 가능합니다.
- 백업은 Tibero를 완전 종료하고 나서 Tibero를 구성하는 모든 파일을 그대로 백업 받아야 합니다. 단, 임시 파일은 백업 대상에 포함하지 않습니다.
- 백업 된 파일을 복구하여 백업 받을 당시의 Tibero의 상태로만 복구할 수 있으며, 그 이후에 발생한 작업은 모두 다시 수행해야 합니다.
참고
이 과정에서 발생할 수 있는 문제는 해당 디스크에 물리적 오류가 발생하여 처음 있던 위치로 복구할 수 없는 경우가 발생할 수 있습니다.
데이터 파일이나 온라인 로그 파일을 해당 위치에 복원할 수 없는 경우에는 다른 위치로 복원을 한 후에 컨트롤 파일에 설정된 데이터 파일의 위치를 수정합니다.
$ tbboot mount Change core dump dir to /tibero/tibero7/bin/prof. Listener port = 8629 Tibero 7 TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. Tibero instance started up (MOUNT mode). $ tbsql sys/tibero SQL> select file#, name from v$datafile; FILE# NAME ---------- ---------------------------------------- 0 /tbdata/system001.dtf 1 /tbdata/undo001.dtf 2 /tbdata/usr001.dtf 3 /tbdata/tpr_ts.dtf 4 rows selected. SQL> alter database rename file '/tbdata/system001.dtf' to '/tbdata2/system001.dtf'; Altered. SQL> tbdown immedate Tibero instance was terminated. SQL> quit $ tbboot
2) ARCHIVELOG MODE 복구 방법
- ARCHIVELOG 모드를 사용하는 경우에는 미디어 복구를 할 수 있으며, 데이터 파일과 Archive log 파일을 백업하면 됩니다.
- 로그 파일에 장애가 발생하면 해당 로그 파일이 속한 로그 그룹의 다른 로그 멤버 파일을 복사하여 복구합니다.
참고
로그 그룹에 속한 모든 로그 파일에 장애가 발생하면 현재 로그 그룹에 장애가 발생한 그룹을 제거한 후 다른 그룹을 추가하면 됩니다. 하지만, 해당 로그 그룹이 현재 로그 그룹이면 commit 시점의 내용만 복구하는 불완전한 복구가 필요합니다.
시스템 Tablespace에 속한 데이터 파일은 Tibero 운영에 필요한 구성 요소이므로 반드시 복원되어야 하지만, 특정 데이터 파일이 손상된 경우 해당 데이터 파일을 백업으로부터 복원하여 복구를 진행합니다.
TBR-1024 : Database needs media recovery failed(/tbdata/system001.dtf)
v$recover_file view를 조회하여 MISSING된 데이터가 있는지 확인
기존 백업 된 데이터 파일을 copy하여 적용
v$recover_file view를 조회하여 CREATE FILE된 데이터가 있는지 확인
RECOVER AUTOMATIC 실행: alter database recover automatic database
v$recover_file View를 조회하여 ERROR난 데이터가 있는지 확인
- tbboot 후 정상 시행되는지 확인
3) 비 시스템 Tablespace의 데이터 파일이 손상된 경우
- 비 시스템 Tablespace 의 데이터 파일을 복원하여 복구하는 방법 과 해당 Tablespace를 제거하는 방법이 있습니다.
- 데이터 파일을 복원하여 복구하는 방법은 위의 예제와 동일하며, Tablespace의 내용이 별로 중요하지 않거나, 삭제해도 문제가 없는 경우는 다음과 같습니다.
TBR-1024 : Database needs media recovery failed(/tbdata/test1.dtf)v$recover_file View를 조회하여 ERROR 부분 확인
OFFLINE DATAFILE ALTER: alter database datafile 4 offline for drop
tbdown immediate
tbboot
tbsql 접속: tbsql sys/tibero
DROP Tablespace: drop tablespace <Tablespace명> including contents and datafiles;
데이터 파일 조회: select file#, name from v$datafile;
4) 백업이 안된 데이터 파일에 장애가 발생
- ALTER DATABASE CREATE DATAFILE 문을 사용하여 데이터 파일을 새로 생성한 후 복구합니다.
해당 Tablespace가 생성된 시점에서 생성된 모든 Archive log file이 존재해야 가능합니다.
v$recover_file View 조회하여 ERROR 부분 확인
삭제된 Tablespace 생성 : alter database create datafile <데이터 파일 경로>;
v$recover_file View 조회하여 FILE CREATE 된 데이터 있는지 확인
recover automatic 실행: alter database recover automatic database;
v$recover_file View 조회하여 에러 데이터 있는지 확인
tbdown 후 tbboot
- 로그인 후 데이터 확인 (select * from <테이블명>;
5) Control file에 장애가 발생한 경우
- CREATE CONTROLFILE 문을 사용하여 컨트롤 파일을 새로 생성해야 합니다.
- Control file의 경우 장애에 대비하여 여러 개의 복사본을 유지하는 미러링(mirroring) 방식을 사용하는
것이 좋습니다. 미러링 된 파일 중 장애가 발생하지 않은 파일이 있으면 이를 사용하여 장애가 발생한 파일에 복사한 후 Tibero를 다시 기동하면 됩니다. 컨트롤 파일을 생성할 때 임시 파일(=TEMP TABLESPCAE)이 존재하지 않으므로 반드시 추가해야 합니다.
ERROR_TCCF_READ_FAILED(-24003) [ Unable to read control file ]
복구 절차
tbboot 실행 시 컨트롤 파일 Open 에러 확인
$ tbboot listener port = 8629 change core dump dir to /tibero/tibero7/bin/prof ******************************************************** * Critical Warning : Raise svmode failed. The reason is * TBR-24003 : Unable to read control file. * Current server mode is NOMOUNT. ******************************************************** Tibero 7 TmaxTibero Corporation Copyright (c) 2020-. All rights reserved. Tibero instance started up (NOMOUNT mode).- 논리 백업 된 control file의 내용을 가지고 실행 (create controlfile reuse database….)
- 재 기동 : tbdown immediate, tbboot
- 미디어 복구 수행 : alter database recover automatic;
- dba_temp_files view조회하여 temp Tablespace 확인
- temp Tablespace 추가: alter tablespace temp add tempfile [파일 경로] size 사이즈 reuse(기존 논리 백업 된 컨트롤 파일에 해당 내용 존재)
- Log file에 장애가 발생한 경우에는 해당 로그 파일이 속한 그룹의 다른 로그 파일을 복사하여 복원을 시도합니다. (미러링 되어 있을 경우)
- 로그 그룹에 속한 모든 로그 파일이 장애가 발생한 경우에는 현재 로그 그룹이 장애가 발생한 그룹을 제거한 후 다른 그룹을 추가하면 됩니다. 하지만 해당 로그 그룹이 Current 로그 그룹이라면 불완전 복구를 통해 복구해야 합니다.
| STATUS | Archive 여부 | 설명 |
|---|---|---|
| INACTIVE | YES | 현재 사용하지 않으며 Archive도 모두 완료된 상태 |
| ACTIVE | YES | Current 상태에서 Log Switch 되면서 Active 상태로 변경되는 것으로 Archiving은 완료된 상태입니다. 곧 Inactive 상태로 변경될 상태 |
| ACTIVE | NO | Current 상태에서 Log Switch 되면서 Active 상태로 변경되는 것으로 Archiving은 미 완료 된 상태 |
| CURRENT | NO | 현재 lgwr가 Write하고 있는 상태 |
| UNUSED | NO | 한번도 사용되지 않는 LOG파일 |
- 현상(Tibero7 버전, 장애 이후 tbboot시 관련 내용)
[표] 로그 상태 및 장애에 따른 boot 상황
| STATUS | 장애 구분 | 설명 |
|---|---|---|
| INACTIVE | 그룹 멤버 일부 | 정상 기동 되며 sys.log 에 아래와 같은 로그가 남습니다.
open (stat) failed (errno=2) (flag=010002 ) (filename=/tbdata/redo022.redo) |
| 그룹 전체 | Mount 모드로 기동 되며, 부팅 시 에러 발생합니다. TBR-1042 : Unable to read log member file in group 2, member -1 (), block 512. | |
| CURRENT | 그룹 멤버 일부 | Mount 모드로 기동 되며, 부팅 시 에러 발생합니다. TBR-1042 : Unable to read log member file in group 1, member 0 |
| 그룹 전체 모두 동일 |
- 처리 순서
[표] 로그 상태 및 장애에 따른 복구 방법
| STATUS | 장애 구분 | 처리 순서 |
|---|---|---|
| INACTIVE | 일부 그룹 멤버 | 같은 그룹 내의 로그 파일을 복사하여 복구 |
| 그룹 전체 | 해당 로그 그룹을 삭제 후 재 생성 예) alter database drop logfile group 2; alter database add logfile group 2 ('/tbdata/redo021.redo', '/tbdata/redo022.redo') SIZE 100m; | |
| CURRENT | 일부 그룹 멤버, 그룹 전체 모두 동일 |
|
복구 운영 절차
Media Recovery – 완전 복구 (Complete Recovery)
- Datafile이 삭제되는 등의 장애가 생겼을 경우에 대한 복구 방법을 설명
- 예) [장애 발생] datafile이 삭제된 경우[Data File 삭제: 설명을 위한 단계]
[예제] datafile이 삭제된 경우의 장애
$ tbdown immediate
$ cp /tbdata /tbdata_bak --backup 받은 위치
$ tbboot
$ tbsql tibero/tmax
SQL> CREATE TABLE T1 (C1 VARCHAR(5)); -- 새로운 데이터가 입력됨.
created.
SQL> INSERT INTO T1 (C1) VALUES ('00011');
SQL> INSERT INTO T1 (C1) VALUES ('00012');
SQL> INSERT INTO T1 (C1) VALUES ('000113');
SQL> COMMIT;
SQL> conn sys/tibero
SQL> ALTER SYSTEM SWITCH LOGFILE; --Archive Log에 새로운 데이터 반영됨.
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> exit
$ tbdown immediate
$ rm /tbdata/my_file001.dtf --데이터파일이 삭제되었을 경우Backup 이후에 테이블과 데이터가 생성/입력된 상태이고, Archive Log에 데이터가 반영된 상태.
복구 절차 – Backup File 적용 복구
- MOUNT모드로 실행: 데이터 파일이 삭제되었을 경우 MOUNT모드로 실행합니다.
- 시스템 계정으로 로그인: sys 계정으로 로그인합니다.
- RECOVER AUTOMTIC 실행: "ALTER DATABASE RECOVER AUTOMATIC"으로 구문을 실행합니다.
- tbdown 이후 tbboot 로그인하여 데이터를 확인합니다.
[예제] 완전 복구(Backup 데이터 적용 후 복구)
$ cp /tbdata/my_file001.dtf /tbdata --기존 backup 받은 데이터파일을 원래 위치로 복사
$ tbboot mount
$ tbsql sys /tibero
SQL> ALTER DATABASE RECOVER AUTOMATIC;
SQL> exit
$ tbdown immediate
$ tbboot
$ tbsql tibero/tmax
SQL> select * from t1; C1
-----
00011
00012
00013
3 rows selected.
Media Recovery – 불완전 복구 (Incomplete Recovery)
Archive log mode 에서 이전 시점으로 DB를 되돌리는 경우에 대한 복구
예) [데이터 시간 확인] 시간 기반 불완전 복구 (Archive log mode)
[예제] 시간 기반 불완전 복구(데이터 시간 확인)
$ tbdown immediate
$ cp /tbdata /tbdata_bak --백업 파일
$ tbboot
$ tbsql tibero/tmax
SQL> select * from t1; --첫 번째 데이터 입력
C1
----------
00011
SQL> !date --시간 확인 2023. 11. 29. (수) 18:01:04 KST
SQL> INSERT INTO T1 (C1) VALUES ('00021'); --두 번째 데이터 입력SQL> COMMIT;
SQL> select * from t1;
C1
----------
00011
00021
SQL> exit
$ tbdown immediate
복구 절차 - Backup File 적용
Backup File 전체 적용
1. MOUNT모드로 기동
2. sys 계정으로 로그인
3. 특정 시점 이전의 시점까지 복구
SQL> alter database recover automatic database until time '[이전시점: 'YYYY-MM-DD HH24:MI:SS']';4. COMMAND라인에서 tbdown immediate
5. RESETLOGS 실행: tbboot resetlogs
로그인하여 데이터 확인
예) [시간 기반 복구] 시간 기반 불완전 복구(Archive log mode)\
[예제] 불완전 복구(시간 기반 복구)
$ cp /tbdata_bak /tbdata --백업 파일 적용 시에 반드시 backup file 전체를 적용합니다
$ tbboot –t mount
$ export TB_NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS' -- 클라이언트 DATE 포맷설정
$ tbsql sys/tibero
SQL> alter database recover automatic database until time '2023-11-29 18:01:04'; --복구 기준 시간 적용
Altered.
SQL>exit
$ tbdown immediate
$ tbboot resetlogs --RESETLOGS 실행
$ tbsql sys/tibero
SQL> select * from t1; --이전 시점으로 데이터 원복
C1
--------
00011
1 row selected.
Recovery 확인
- Tibero가 정상 기동(Normal mode)완료되면 바로 Tibero로 접속하여 사용이 가능합니다.
- Media Recovery 불완전 복구 (Incomplete Recovery) 수행 후
resetlogs 기동 되었을 경우 에는 기존의 backup 된 datafile, Archive log file 등은 사용할 수 없으므로
반드시 다시 Database online Backup을 수행하여 backup본을 다시 만들어 두어야 합니다. - tbexport / tbimport / flashback 기능은 Tibero가 정상 기동[Normal mode] 되어 있을 때에 수행이 가능합니다.
Recovery 관련 참조
복구 관련 참조 View
[표] Recovery 관련 참조 View
| View | 설명 |
|---|---|
| V$LOGFILE | 로그 Member파일의 정보 제공 |
| V$CONTROLFILE | Control file에 대한 정보 제공 |
| V$LOG | 로그 Group에 대한 정보 제공 |
| V$RECOVER_FILE | 미디어 Recovery가 필요한 file에 대한 정보 제공 |
| V$RECOVERY_FILE_STATUS | Recovery가 된 파일에 대한 상태 정보 제공 |