Tibero는 시스템의 예상치 못한 오류 등으로 인해 데이터베이스가 비정상적으로 종료하거나 시스템에 물리적인 손상을 입은 상황을 대처하려고 다양한 백업과 복구 방법을 제공한다.
본 장에서는 이러한 백업과 복구 방법을 설명한다.
Tibero의 파일은 컨트롤 파일(Control file), 데이터 파일(Data file), 임시 파일(Temp file), 로그 파일(Log file)로 구성된다.
플래시백 데이터베이스(Flashback Database) 기능 사용 시에는 플래시백 로그 파일(Flashback Log File)이 추가된다. 플래시백 데이터베이스 기능에 대해서는 “11.6. 플래시백 데이터베이스”를 참고한다.
각 파일의 특징과 역할은 다음과 같다.
컨트롤 파일은 Tibero를 구성하는 모든 파일의 위치와 데이터베이스의 이름 등 데이터베이스의 구조를 저장하는 파일이다. 특히, Tibero가 사용하는 데이터 파일, 로그 파일 등의 상태 정보가 기록된다. 컨트롤 파일은 Tibero를 기동할 때 복구가 필요한지를 판단하는 데 사용된다.
컨트롤 파일은 데이터베이스의 복구에 매우 중요한 파일이므로 다른 물리적 파티션에 여러 개 지정하기를 권장한다. 여러 개를 유지하면 한 파티션에 장애가 발생하여 컨트롤 파일을 사용하지 못하더라도 다른 컨트롤 파일을 이용하여 복구할 수 있다.
컨트롤 파일은 현재의 데이터베이스를 구성하는 파일에 관한 정보를 담고 있으므로 반드시 최신 것으로 유지해야 한다. 컨트롤 파일의 백업은 현재의 컨트롤 파일 자체를 백업하는 방식으로 이루어지지 않고, 컨트롤 파일을 생성하는 CREATE CONTROLFILE 문을 백업해 두었다가 복구가 필요한 경우 백업해 놓은 컨트롤 파일 생성문을 사용하여 컨트롤 파일을 다시 생성하는 방식으로 이루어진다.
최신의 컨트롤 파일을 유지하기 위해서는 데이터베이스에 파일을 추가하거나 변경하는 등 구조상 변화가 있을 때마다 컨트롤 파일의 생성문을 백업해야 한다. 컨트롤 파일 자체를 백업해 두었다가 사용하는 것은 NOARCHIVELOG 모드에서처럼 데이터베이스 전체를 백업하는 경우에만 사용할 수 있다.
데이터 파일은 사용자의 데이터를 저장하는 파일로써 로그 파일과 함께 데이터베이스를 구성하는 가장 중요한 파일이다.
Permanent 테이블 스페이스와 Undo 테이블 스페이스에서 정의한 파일로 테이블, 인덱스 등의 데이터베이스 객체를 저장한다. 테이블 스페이스는 한 개 이상의 데이터 파일로 이루어지며, 한 데이터 파일은 하나의 테이블 스페이스에 속한다. 데이터 파일은 사용자의 데이터가 물리적으로 저장되는 공간이므로 반드시 백업해야 한다.
임시 파일은 데이터베이스가 메모리에서 처리할 수 없는 방대한 양의 데이터를 다루는 경우 임시로 사용하기 위한 공간이다.
Tibero는 사용자의 질의를 처리하기 위해 정렬 등의 연산을 수행할 때와 임시 테이블(Temporary Table)의 데이터를 저장할 때 데이터 파일을 사용한다. 데이터 파일은 임시 테이블 스페이스(Temporary Tablespace)에서만 정의할 수 있고, 임시 테이블 스페이스는 하나 이상의 데이터 파일을 가질 수 있다. 임시 파일은 데이터베이스를 구성하는 데이터가 물리적으로 저장되지는 않고 운영 중에 임시로 사용되는 영역이므로 백업할 필요가 없다.
로그 파일은 로그를 저장하는 파일이다. 데이터 파일에 기록되는 내용을 시간 순으로 기록하는 파일로써 데이터베이스를 복구할 때 사용한다. 로그 파일은 운영 중에 순환적으로 재사용되는 온라인 로그 파일과 재사용된 온라인 로그 파일을 보관하는 아카이브 로그 파일로 나뉜다.
ARCHIVELOG 모드로 운영 중일 때만 아카이브 로그 파일이 만들어진다. NOARCHIVELOG 모드에서는 온라인 로그 파일만 사용한다. NOARCHIVELOG 모드에서는 재사용되어 없어진 로그 파일이 있을 수 있으므로 복구할 때 많은 제약이 따른다. 로그 파일은 데이터베이스 복구할 때 복원된 데이터 파일을 최신 상태로 복구하기 위해, 데이터베이스가 어떻게 변경되어 왔는지에 대한 모든 정보를 기록한다. 따라서 데이터 파일과 함께 반드시 백업을 해야 한다.
플래시백 로그 파일(Flashback Log File)
플래시백 로그 파일은 플래시백 로그를 저장하는 파일이다. 데이터 파일이 변경되기 직전 내용들을 블록 단위로 기록하는 파일로써 플래시백 데이터베이스 기능으로 데이터베이스를 가까운 과거로 되돌릴 때 사용한다. 일반적인 사용 방법과 특징은 로그 파일과 같다.
ARCHIVELOG 모드로 운영 중이어야만 플래시백 로그를 기록할 수 있다. 플래시백 아카이브 로그 파일을 오래 보관할수록 플래시백 데이터베이스 기능으로 돌아갈 수 있는 과거가 더 오래된다. 하지만, 백업 파일 사용하여 복구 시 플래시백 로그 파일은 모두 무용지물이 되기 때문에 일반 아카이브 로그 파일과 다르게 백업 대상이 아니다. 일반 로그 파일과 다르게 Tibero Standby Cluster의 동기화 대상이 아니다.
백업(Backup)은 여러 가지 유형의 장애로부터 데이터베이스를 보호하는 것을 뜻한다. 즉, 시스템 장애가 발생했을 때 복구를 하거나 시스템 작동을 유지하기 위한 절차 또는 기법이다.
Tibero는 데이터베이스를 백업하는 방법을 크게 두 가지로 나누어 수행할 수 있다.
논리적 백업이란 테이블, 인덱스, 시퀀스와 같은 데이터베이스의 논리적 단위를 백업하는 것을 뜻한다. Tibero에서는 이를 위해 tbExport와 tbImport 유틸리티를 제공하고 있다. tbExport와 tbImport에 대한 자세한 내용은 "Tibero 유틸리티 안내서"를 참고한다.
물리적 백업이란 데이터베이스를 구성하는 물리적인 파일을 백업하는 것이며 운영체제에서 파일 복사 명령(COPY)으로 백업하는 것을 뜻한다. 물리적 백업이 필요한 파일에는 데이터 파일과 아카이브 로그 파일이 있다. 온라인 로그 파일은 NOARCHIVELOG 모드에서 데이터베이스 전체를 백업하여 복구할 경우에만 의미가 있다.
데이터베이스가 운영 중일 때 운영체제의 파일 복사 명령을 사용하는 것은 안전하지 않으므로 주의한다.
다음은 Tibero가 제공하는 백업의 종류이다.
모드별 백업
데이터베이스를 ARCHIVELOG 모드로 운영할 때와 그렇지 않았을 때 사용할 수 있는 백업 방법이 다르다.
Tibero를 정상적으로 종료한 상태에서 백업하는 방법이다. 실행 예는 “11.2.2. 백업 실행”의 "Consistent 백업"을 참고한다.
Tibero의 데이터베이스가 운영 중일 때 백업하거나 정상적으로 종료되지 않은 상태에서 백업하는 방법이다. 실행 예는 “11.2.2. 백업 실행”의 "Inconsistent 백업"을 참고한다. 단, NOARCHIVELOG 모드에서는 정합성 문제가 발생할 수 있으므로 이 방법은 허용되지 않는다.
본 절에서는 Tibero가 제공하는 물리적 및 논리적인 백업 방법에 따라 백업을 실행하는 예를 설명한다.
데이터 파일이나 로그 파일의 경우에는 데이터베이스 상태에 따라서 백업 받는 방법이 다르므로 이를 각각 데이터베이스가 운영 중인 경우(Inconsistent 백업)와 그렇지 않은 경우(Consistent 백업)로 나누어서 설명한다.
컨트롤 파일은 물리적인 백업과 논리적인 백업을 모두 지원하지만, Tibero에서는 컨트롤 파일의 논리적인 백업을 추천한다. 물리적 백업은 제약사항과 사용법이 복잡하기 때문에 실수를 방지하기 위해 보통 사용하지 않는 것이 좋다. 물리적 백업시 데이터의 정합성을 맞춰주기 위해 모든 데이터 파일을 백업한 후 마지막에 컨트롤 파일을 백업해 주어야 한다. 데이터베이스의 구조에 변화가 일어난 경우에는 컨트롤 파일의 생성문을 백업하는 논리적 백업을 사용하는 것을 권장한다.
다음은 컨트롤 파일을 물리적 백업으로 tibero7/backup 디렉터리에 있는 ctrlfile1.ctl 파일에, 논리적 백업으로 컨트롤 파일의 생성문을 ctrlfile1.sql 파일에 백업하는 예이다.
생성된 ctrlfile1.sql 파일은 다음과 같은 내용을 포함한다.
[예 11.3] 백업된 컨트롤 파일 생성문
CREATE CONTROLFILE REUSE DATABASE "inventory" LOGFILE GROUP 0 ( '/disk1/log001.log', '/disk2/log002.log' ) SIZE 1M, GROUP 1 ( '/disk1/log003.log', '/disk2/log004.log' ) SIZE 1M, GROUP 2 ( '/disk1/log005.log', '/disk2/log006.log' ) SIZE 1M NORESETLOGS DATAFILE '/disk1/system001.dtf', '/disk1/undo001.dtf' NOARCHIVELOG MAXLOGFILES 255 MAXLOGMEMBERS 8 MAXDATAFILES 100 MAXBACKUPSET 500 CHARACTER SET MSWIN949 NATIONAL CHARACTER SET UTF16 ;
RESETLOGS는 컨트롤 파일의 생성문에 지정한 대로 만들어진다. 이 생성문은 트레이스 파일을 생성한 후 RESETLOGS를 필요로 할 경우에 사용하며, RESETLOGS가 필요하지 않은 경우는 NORESETLOGS로 수정하여 컨트롤 파일을 생성할 때 적용할 수 있다.
컨트롤 파일의 생성문에는 임시 파일을 생성하는 내용이 없다. 컨트롤 파일을 생성한 후 Tibero를 기동하면 임시 파일은 존재하지 않는다. 컨트롤 파일을 새로 생성한 경우 반드시 임시 파일을 추가해야 임시 파일을 이용한 기능을 사용할 수 있다.
생성된 컨트롤 파일은 $TB_SID.tip 파일에 경로를 설정한다.
다음과 같이 MOUNT나 OPEN 상태에서 컨트롤 파일의 목록을 조회하려면 동적 뷰 V$CONTROLFILE를 조회한다.
[예 11.5] 컨트롤 파일 조회
SQL> SELECT NAME FROM V$CONTROLFILE;
NAME
------------------------------------------------------------
/disk1/c1.ctl
/disk2/c2.ctl
2 selected.
컨트롤 파일을 다시 생성하기 위해서는 $TB_SID.tip 파일에 설정된 컨트롤 파일의 위치를 [예 11.5]의 질의 결과와 동일하게 설정한 후 CREATE CONTROLFILE 문을 실행해야 한다.
본 절에서는 Tibero가 정상적으로 종료한 후에 백업하는 방법을 설명한다.
Consistent 백업을 실행 하기에 앞서 백업할 컨트롤 파일, 데이터 파일, 로그 파일을 조회한다.
다음은 MOUNT나 OPEN 상태에서 동적 뷰 V$DATAFILE를 통해 데이터 파일을 조회하는 방법이다. 여기서 MOUNT는 Tibero의 인스턴스가 시작된 상태이며, OPEN은 컨트롤 파일에 정의한 모든 파일이 오픈된 상태를 의미한다.
[예 11.6] 데이터 파일의 조회
SQL> SELECT NAME FROM V$DATAFILE;
NAME
------------------------------------------------------------
/disk1/system001.dtf
/disk2/undo001.dtf
/disk3/user001.dtf
3 selected.
다음은 온라인 로그 파일을 MOUNT나 OPEN 상태에서 조회하는 방법이다.
[예 11.7] 온라인 로그 파일의 조회
SQL> SELECT MEMBER FROM V$LOGFILE;
MEMBER
------------------------------------------------------------
/disk1/log001.log
/disk2/log002.log
/disk2/log003.log
/disk3/log004.log
/disk3/log005.log
/disk1/log006.log
6 selected.
온라인 로그 파일은 ARCHIVELOG 모드가 아닌 경우에는 백업하지 않는 것이 좋다. ARCHIVELOG 모드에서는
온라인 로그 파일이 아카이브되기 때문에 아카이브된 파일을 백업하면 안 된다. 참고로 아카이브된 파일은
LOG_ARCHIVE_DEST 초기화 파라미터에 설정된 위치에 저장된다.
데이터베이스는 다음과 같이 NORMAL 모드로 종료해야 한다.
SQL> tbdown NORMAL; Tibero instance was terminated.
데이터베이스가 정상적으로 종료되면 운영체제별로 제공하는 파일 복사 명령을 사용하여 백업한다.
본 절에서는 Tibero가 운영 중일 때 백업하는 방법을 설명한다.
데이터베이스가 운영 중이면 운영체제의 명령어를 사용해 데이터 파일을 복사하는 것은 안전하지 않다. 따라서 다음과 같은 문장을 실행하여 Tibero에 백업의 시작과 종료를 통보해야 한다.
alter tablespace {tablespace name} begin backup
...
alter tablespace {tablespace name} end backup
begin backup과 end backup 문장 사이에는 해당 테이블 스페이스의 변경 사항에 대한 로그가 늘어나기 때문에 데이터베이스에 부담이 가중되게 된다. begin backup을 시작한 이후에는 신속하게 백업을 완료하고 end backup 상태로 복귀시켜야 한다.
Inconsistent 백업의 전체 과정은 다음과 같다.
먼저 백업할 테이블 스페이스를 선정한다.
[예 11.8] Inconsistent 백업 - 테이블 스페이스의 선정
SQL> select name,type from v$tablespace; NAME TYPE ------------------------------ ---- SYSTEM DATA UNDO UNDO USER DATA TEMP TEMP 3 selected.
백업할 테이블 스페이스에 속한 데이터 파일을 조회한 후 begin backup, end backup 명령어를 사용하여 백업을 수행한다. 예를 들어 USER 테이블 스페이스를 백업할 경우를 가정하고 수행한다.
[예 11.9] Inconsistent 백업 - begin backup, end backup 명령어의 사용
SQL> select f.name
from v$tablespace t join v$datafile f on t.ts# = f.ts#
where t.name = 'USER';
NAME
------------------------------------------------------------
/disk3/user001.dtf
1 selected
SQL> alter tablespace SYSTEM begin backup;
Altered.
SQL> !cp /disk3/user001.dtf /backup/
SQL> alter tablespace SYSTEM end backup;
Altered.
Tibero를 운영하다 보면, 예상치 못한 장애로 인해 정상적인 데이터베이스 운영이 어려운 상황이 발생할 수 있다. 복구는 장애가 발생하는 경우 복원하는 일련의 과정이다.
복구를 하려면 백업된 데이터베이스가 있어야 한다. Tibero는 데이터베이스에서 일어나는 모든 변화를 로그 파일에 기록한다. 따라서 백업 이후에 데이터베이스에 일어난 모든 변화에 대해서는 로그를 적용하면 복구할 수 있다. 로그 파일에는 커밋되지 않은 트랜잭션이 수정한 데이터도 포함되어 있다. 복구할 때 아카이브 로그 파일과 로그 파일 모두 사용할 수 있다.
복구 과정은 다음과 같이 두 가지 경우로 수행할 수 있다.
데이터 파일에 기록되지 않는 변화를 로그를 사용하여 적용하는 과정
데이터 파일에 모든 로그의 변화를 기록하는 과정을 통해서 데이터베이스는 안정된 상태가 된다. 즉, 데이터베이스 운영상의 특정 시점까지 모든 작업이 반영되고 그 이후의 변화는 발생하지 않아야 한다. 데이터베이스에 정상적인 복구가 이루어져 안정된 상태가 되어야만 기동할 수 있다.
커밋되지 않는 데이터로 복구하는 과정
데이터베이스를 종료할 때 커밋하지 않은 트랜잭션이 수정한 내용으로 복구하는 과정이다.
Tibero는 부트 모드별로 발생되는 작업을 복구 측면에서 보면 다음과 같다.
NOMOUNT 모드로는 언제나 복구할 수 있다. 이 모드에서는 데이터베이스와 컨트롤 파일을 생성할 수 있다. MOUNT 모드로 동작하기 위해서는 컨트롤 파일이 있어야 한다. 컨트롤 파일이 없거나 컨트롤 파일에 장애가 발생한 경우에는 NOMOUNT 모드로 동작하며 컨트롤 파일을 생성하면 MOUNT 모드로 동작할 수 있다.
MOUNT 모드에서는 데이터 파일, 온라인 로그 파일, 컨트롤 파일 사이의 상태를 검사하여 Tibero를 기동할 준비를 한다. 세 파일이 모두 최신 상태이면 OPEN 모드로 동작할 수 있다. 파일에 물리적인 장애가 발생하였거나, 복원된 파일이라면 미디어 복구가 필요하며 MOUNT 모드로 동작한다. MOUNT 모드에서는 제한된 뷰의 조회가 가능하고, 미디어 복구를 수행할 수 있다.
Tibero의 데이터 파일, 온라인 로그 파일, 컨트롤 파일이 일관성을 유지할 때에만 OPEN 모드로 동작할 수 있다. OPEN 모드에서 Tibero는 세 파일을 열고 정상으로 동작한다. 일반 사용자는 데이터베이스를 이용할 수 있다. 오프라인 상태인 테이블 스페이스에 사용자가 접근하려면 우선 해당 테이블 스페이스를 온라인 상태로 전환해야 한다. 이때 다른 파일들과 일관성을 유지하기 위해 해당 테이블 스페이스에 온라인 미디어 복구를 수행해야 한다.
파손 복구(Crash Recovery)는 Tibero를 운영하는 중에 정전, 시스템 이상, 강제 종료 등으로 데이터베이스가 비정상적으로 종료되었을 때 사용자의 명령 없이 자동으로 복구되는 것을 의미한다. 복구가 완료되면 Tibero가 정상적으로 동작한다.
파손 복구는 온라인 로그 파일의 내용 중 아직 데이터 파일에 반영되지 않은 부분을 기록하여 Tibero가 비정상적으로 종료되기 직전에 운영 시점의 상태로 복구하는 과정과 이러한 상태로 복구된 시점에서 커밋되지 않은 트랜잭션이 발생시킨 변화를 되돌리는 과정으로 나눌 수 있다.
파손 복구의 모든 과정은 파일의 손상이 없으면 DBA의 도움 없이 자동으로 이루어진다.
Tibero를 구성하는 파일이 물리적인 손상이나 정상적으로 동작할 수 없는 경우가 발생할 수 있다. 이러한 경우 데이터베이스가 정상적으로 동작할 수 있도록 복구하는 과정이 미디어 복구(Media Recovery)이다.
미디어 복구 과정은 자동으로 이루어지지 않는다. DBA가 상황을 파악해서 필요한 과정을 지시하는 일련의 작업이 필요하다. 복구 완료시점을 오류가 발생하기 이전의 가장 최근 시점까지로 할지, 과거의 특정 시점까지로 할지 여부에 따라서 완전 복구(Complete Recovery)와 불완전 복구(Incomplete Recovery)로 구분된다.
온라인 로그 파일의 가장 최근 로그까지 모두 반영하는 미디어 복구이다.
온라인 로그 파일의 최근까지가 아닌 그 이전의 특정 시점까지 복구하는 것을 말한다. 불완전 복구 후에는 반드시 RESETLOGS 모드로 Tibero를 기동해야 한다. RESETLOGS는 온라인 로그 파일을 초기화하는 것이며, 현재 온라인 로그 파일로 데이터베이스를 시작하지 않을 때 사용한다.
RESETLOGS가 필요한 경우는 다음과 같다.
불완전 미디어 복구를 한 경우
RESETLOGS로 컨트롤 파일을 생성한 경우
RESETLOGS로 시작하면 새로운 데이터베이스가 만들어진 것과 같다. RESETLOGS 이전의 데이터 파일, 로그 파일과 RESETLOGS 이후의 파일은 서로 호환되지 않는다. RESETLOGS 이전의 백업 파일이나 로그 파일을 이용하여 RESETLOGS 이후로 복구할 수 없다. 또한 RESETLOGS 이후의 파일을 RESETLOGS 이전 상태로 불완전 복구를 하는 것도 불가능하다. 따라서 RESETLOGS 모드로 기동한 경우에는 반드시 새로 백업을 하기를 권장한다.
RESETLOGS로 데이터베이스를 기동하는 방법은 다음과 같다.
미디어 복구 과정은 MOUNT 모드에서만 이루어진다. 백업된 파일을 사용하여 오류가 발생한 파일을 복원하는 과정과 복원된 파일을 백업한 시점으로부터 최근 또는 특정 시점까지 반영되지 않은 변화를 로그 파일을 사용하여 복구하는 과정으로 나눌 수 있다. 단순한 복원 과정만으로는 Tibero의 정상적인 운영이 불가능하다.
미디어 복구를 위해 장애가 발생한 파일을 찾아 복구해야 한다. 이를 위해 다음과 같은 뷰를 제공한다.
V$LOGFILE
V$CONTROLFILE
V$LOG
V$RECOVER_FILE
V$RECOVERY_FILE_STATUS
미디어 복구는 로그 파일을 하나씩 데이터베이스에 순서대로 반영하여 진행한다. 데이터베이스는 현재 복구에 필요한 로그 파일만을 반영할 수 있다. 현재 필요한 로그 파일을 찾기 위해 시퀀스 번호가 사용된다. 시퀀스 번호는 데이터베이스가 생성된 이후로 만들어진 로그 파일의 일련 번호이며, 모든 로그 파일은 하나의 유일한 시퀀스 번호를 갖는다. 시퀀스 번호가 큰 로그 파일이 최근 로그 파일이다. 시퀀스 번호는 아카이브 로그 파일의 경우 파일 이름을 통해 알 수 있고, 온라인 로그 파일의 경우 V$LOG 뷰를 통해 알 수 있다.
Tibero는 다양한 백업 및 복구 시나리오를 제공한다. 숙련된 데이터베이스 관리자라면 상황에 맞는 적절한 방법을 선택하고 활용할 수 있을 것이다. 허나 너무 다양한 기능을 제공함으로써 오히려 사용자에게 혼란을 줄 수도 있다. 이러한 면을 보완하기 위하여 Tibero는 복구 관리자(이하 RMGR)를 제공한다.
RMGR은 다양한 백업/복구 시나리오를 지원하도록 구성되어 있다. Tibero에서 제공되는 RMGR의 기능은 다음과 같다.
Tibero 데이터베이스에 속한 전체 데이터 파일을 온라인 백업한다. 온라인 백업을 위해서는 데이터베이스가 ARCHIVELOG 모드이여야 한다. RMGR은 자동으로 데이터베이스의 Begin Backup 기능을 사용하여 모든 테이블 스페이스를 Hot Backup 상태로 만들고 백업을 진행한다.
백업을 완료하면 데이터베이스의 End Backup 기능을 사용하여 모든 테이블 스페이스를 Hot Backup 상태로부터 해제한다. 명령과 옵션들을 통해 백업이 진행/완료되어 하나의 Backup Set(백업 셋)이 생성되면, V$BACKUP_SET을 통해 진행 상황 및 해당 Backup Set에 사용한 옵션들을 확인할 수 있다.
RMGR를 통해 온라인 백업을 받았으면 이를 이용하여 Incremental Backup을 할 수 있다. Incremental Backup이란 백업을 받을 때 전체 파일을 받는 것이 아니라 이전 백업과의 차이만을 기록하는 방식으로 백업에 소모되는 디스크 공간을 획기적으로 줄일 수 있다.
Incremental Backup을 하려면 이전에 RMGR를 통해 Online Full Backup을 받았어야 한다. 현재 데이터베이스와 백업본과의 차이를 구하여 백업 파일을 만든다. 이러한 기능은 RMGR를 통해서만 사용할 수 있다.
Incremental Backup은 이전 백업과 현재 운영 중인 데이터 파일 간의 변경된 사항만을 기록하여야 하기 때문에 전체 데이터 파일을 스캔하여 백업본과의 차이점을 구하는 동작을 수행한다. 이러한 동작은 데이터 파일이 큰 경우에는 데이터 파일을 모두 스캔하는 오버헤드가 크기 때문에 백업되는 파일의 용량은 적지만 시간이 오래 걸리는 단점이 있다. 이런 단점을 보완하기 위해 Tibero 서버가 마지막 백업시점 이후의 데이터 파일의 변화 내역을 기록하고 백업할 때 활용한다. 이 기능은 어떤 블록만 백업하면 될지 추적하기가 쉽기 때문에 Incremental Backup의 수행속도가 비약적으로 빨라질 수 있다. 이를 위해 RMGR 및 Tibero 서버는 Block Change Tracking(BCT)기능을 제공한다.
BCT 기능을 사용하기 위해서는 Tibero 서버 tip 파일에 BCT 관련 파라미터를 설정하고 BCT 기능을 컨트롤하는 DDL을 수행해야 하며, LGWR AIO 기능과는 호환되지 않는다.
[예 11.11] Tibero 서버 tip 파일에 BCT 설정
BLOCK_CHANGE_TRACKING="/database/emp/emp_change.bct" LGWR_USE_AIO=N
RMGR은 Incremental Backup을 수행할 때 이 BCT 파일을 사용하여 백업할 블록들의 리스트를 빠른 시간내에 탐색하여 백업을 효과적으로 수행할 수 있다. 해당 파일이 운영 중에 삭제되거나 장애가 생길 때에 Tibero 서버는 자동적으로 BCT 기능을 중지하며 사용자는 다시 BCT 기능을 DDL로 수행해야 한다.
수동으로 BCT 기능을 중지하기 위해서는 다음의 DDL을 수행한다.
RMGR은 Tibero 서버에 현재 BCT 기능이 켜져있는지를 질의하여 이전 백업부터의 블록 변화가 BCT 파일에 온전히 기록이 되었는지 확인한 후 유효한 BCT 파일이 존재할 때만 BCT를 이용한 Incremental Backup을 수행한다. Tibero 서버는 Incremental Backup이 끝나면 백업이 끝난 시점부터 변경된 사항들을 BCT 파일에 기록하게 된다.
RMGR을 이용하여 만들어진 백업본을 이용하여 자동 복구를 진행한다. 백업 정보는 컨트롤 파일에 저장이 되어있다. 컨트롤 파일에 저장된 정보를 기반으로 Online Full Backup/Incremental Backup 정보를 분석하여 자동으로 Merge 후 복구를 진행한다. 컨트롤 파일이 접근 불가능할때에는 백업된 컨트롤 파일을 이용하여 복구를 진행한다. 단, 이때에는 특정 옵션을 사용하여 백업이 존재하는 백업 경로를 명시해주어야 한다.
TAC 환경에서 RMGR을 이용한 복구를 진행하기 위해서는 구성 노드 중 한 개의 노드만 떠있는 상황에서 복구를 진행해야 한다.
Datafile/Tablespace 단위 백업 및 복구
전체 데이터베이스를 백업/복구하는 대신에 필요한 데이터 파일 또는 테이블 스페이스만 대상으로 백업/복구 작업을 수행할 수 있다. 복구할 때에는 데이터 파일 또는 테이블 스페이스는 각 백업 파일들을 가져온 후 복구 자체는 전체 복구로 MOUNT 모드에서 진행된다.
RMGR을 이용하여 컨트롤 파일에 등록된 Backup Set(백업 셋)을 삭제할 수 있다. 삭제 대상이 되는 Target Backup Set은 Backup Set ID를 직접 지정할 수 있으며(--bakcup-set 옵션), 특정 시간을 명시하여 특정 시간 이전에 생성된 Backup Set들을 모두 지정할 수 있다(--beforetime 옵션).
삭제하고자 하는 Backup Set이 존재하는 백업 경로는 컨트롤 파일을 참조하여 결정하므로, 백업이 이루어진 이후에 백업 경로가 변경된 경우에는 삭제하고자 하는 Backup Set이 존재하는 백업 경로(-o 옵션)를 명시해주어야 한다. 만약 컨트롤 파일에 등록된 Backup Set을 사용자가 수동으로 삭제하였거나, 잘못된 백업 경로를 명시하여 백업 경로에서 삭제 대상으로 지정된 Backup Set을 찾을 수 없는 경우에는 컨트롤 파일에 등록된 Backup Set Entry만을 삭제하고 종료할 수 있다(--cf-only 옵션).
RMGR을 이용하여 Tibero Standby Cluster 환경의 standby에서 백업을 진행할 수 있다. Standby의 백업 파일을 이용하여 standby, primary 모두 복구가 가능하다. Standby 환경에서 백업을 진행할 때는 다음과 같은 제약사항이 추가된다.
--for-standby 옵션은 사용할 수 없다.
-w, --with-archivelog 옵션을 사용하려면 primary 접속에 필요한 정보를 tbdsn.tbr에 설정한 후에 primary의 SID를 $TB_SID.tip 파일에 초기화 파라미터 RMGR_PRIMARY_SID로 설정해야 한다.
[예 11.14] Primary SID 설정
# tbdsn.tbr primary=( (INSTANCE=(HOST=168.1.1.33) (PORT=8629) (DB_NAME=tibero) ) ) # $TB_SID.tip RMGR_PRIMARY_SID=primary
RMGR은 셸 명령으로 실행되며 다양한 옵션을 지정하여 원하는 기능을 사용할 수 있다.
| 옵션 | 설명 |
|---|---|
| backup | RMGR를 통해 백업을 진행하여 Backup Set을 생성한다. |
| recover | RMGR로 백업한 Backup Set을 원하는 경로에 복원하여 복구를 진행한다. |
| delete | RMGR로 받아놓은 백업본 중 사용자 입력으로 주어진 조건에 맞는 Backup Set을 삭제한다. |
| --userid | 데이터베이스에 접속할 사용자명과 패스워드 및 SID를 아래와 같은 형식으로 지정한다. --userid USERID[[/PASSWD][@SID]] 화면상에 비밀번호 노출을 원치 않을 때에는 비밀번호를 공백으로 입력한 후 비밀번호를 입력하라는 문구가 나오면 비공개로 번호를 입력할 수 있다. --userid USERID/[@SID] OS 인증을 받은 계정으로 로그인하는 경우 Userid와 Passwd를 입력하지 않아도 로그인 가능하다(단, 현재는 backup과 delete 기능만 가능). --userid / |
| --help | RMGR의 옵션 사용법을 출력한다. |
| --interval | RMGR 백업/복구 진행률을 확인하여 출력해주는 실시간 시간 간격을 초 단위로 조절한다. 기본값은 1 초이며, 최소 0.01 초까지 설정 가능하다. 0으로 설정하는 경우 실시간 진행률을 확인하지 않는다. |
| -v, --verbose | RMGR 백업/복구를 진행하는 경우 각 데이터 파일마다의 절대 경로를 출력한다. |
| -s, --silent | RMGR 백업/복구를 진행하는 경우 각 데이터 파일마다의 진행률을 출력하지 않는다. |
| -l, --log-level | 클라이언트 측 RMGR 로그(tbrmgr_trace.log)의 기록 레벨을 설정한다. 레벨은 1부터 5까지 있으며 숫자가 커질 수록 더 자세히 기록된다. 기본 레벨은 4이다. |
| -L | tbrmgr_trace.log의 기록될 위치를 지정한다. 기본 경로는 $TB_HOME/client/tbrmgr_log/이다. |
| -o | 백업, 복구 및 삭제에 사용될 디렉터리 경로를 지정한다. 백업할 때 옵션을 사용하지 않을 경우 RMGR_BACKUP_DEST가 기본 경로로 설정된다. 복구의 경우 옵션을 사용하지 않으면 각 Backup Set마다 백업된 경로를 자동으로 찾아간다. 옵션을 사용할 경우 모든 Full/Incremental Backup Set 및 아카이브 로그 백업 셋들이 해당 경로에 있어야 한다. 콤마(,)로 구분된 다중경로를 16개까지 지원한다. 백업을 제외한 복구 및 삭제에서 다중경로 옵션을 사용하는 경우, 명시한 디렉터리 경로는 모두 유효해야 한다. tbrmgr backup -o /backup/ tbrmgr backup -o /backup1/,/backup2/ 아카이브 로그의 경우 다중경로 삭제 기능을 지원하지 않는다. |
| -n | NetBackup을 사용하는 경우 백업/복구에 사용될 NetBackup 경로를 지정한다. 백업할 때 옵션을 사용하지 않을 경우 RMGR_NBU_BACKUP_DEST가 기본 경로로 설정된다. 이외 특이 사항은 -o 옵션과 동일하며, 복구/삭제가 동작할 때 -o와 -n을 동시에 사용할 수 있다. USE_NBU_FOR_BACKUPSET 파라미터를 Y로 사용할 경우 기본 백업/경로는 로컬이 아닌 NetBackup 경로가 우선적이다. |
| -i, --incremental | 가장 최신 백업에 대한 Incremental backup을 수행한다. |
| -C, --cumulative | 마지막 Full backup에 대한 Incremental backup을 수행한다. |
| -w, --with-archivelog | 백업/복구를 수행할 때 hot backup을 복구하기 위한 아카이브 로그 파일도 함께 백업/복원한다. 기본적으로 클러스터 환경에서는 모든 Instance들이 Shared disk로 모두 같은 LOG_ARCHIVE_DEST를 공유해야 정상적으로 동작한다. 이는 Active stroage를 사용하는 경우도 마찬가지이다. NetBackup을 사용하는 경우 USE_NBU_FOR_ARCHIVELOG=Y인 경우엔 옵션 사용 불가하다. 백업된 아카이브 로그 파일은 다음의 형식으로 관리된다. bkl_<BACKUPSET#>_t<THREAD#>-r<RESETLOGS_TSN>-s<SEQUENCE#>.arc 예를 들어 BACKUPSET#는 1, THREAD#는 0, RESETLOGS TSN는 0, SEQEUNCE#는 1인 경우 파일명은 'bkl_1_t0-r0-s1.arc'이 된다. |
| -a, --archive-only | 가장 최근에 백업한 아카이브 로그 백업 셋 이후에 생성된 아카이브 로그 파일들을 모두 백업한다. 복구할 때 필요한 경우 자동으로 함께 사용된다. tbrmgr backup --archive-only특정 Redo 스레드의 아카이브 로그의 특정 시퀀스를 지정하여 해당 시퀀스 이상부터 최신까지의 아카이브 로그 파일들을 백업할 수도 있다(--thread, --from-seq 옵션). tbrmgr backup --archive-only --thread <THREAD#> --from-seq <SEQUENCE#> NetBackup을 사용하는 경우 USE_NBU_FOR_ARCHIVELOG=Y인 경우엔 옵션 사용 불가하다. |
| -p, --parallel | 복구 전용 Process의 스레드들은 각자 하나의 데이터 파일을 담당하는데, 스레드 개수를 명시하여 여러 스레드를 할당하여 병렬적으로 백업/복구를 수행한다. 기본값은 1이며 최대값은 16이다. 이는 (RECO_PROC_WTHR_CNT - _CACHE_RECO_DOP -3)/2로 조정할 수 있다. tbrmgr backup --parallel <THREAD_COUNT> |
| -u, --skip-unused | 아직 사용되지 않은 깨끗한 블록은 백업하지 않는다. 보통 백업에 소용되는 시간은 늘어나고 생성되는 파일 크기를 줄일 수 있다. |
| -c, --compress | 백업을 수행할 때 데이터를 압축하여 저장한다. LOW, MEDIUM, BASIC, HIGH로 옵션을 추가하여 압축 정도를 지정할 수 있다. 옵션을 지정하지 않으면 BASIC 옵션으로 압축이 진행된다. LOW > MEDIUM > BASIC > HIGH 순으로 압축속도가 빠르며, HIGH > BASIC > MEDIUM > LOW 순으로 압축률이 높다. tbrmgr backup --compress [LOW|MEDIUM|BASIC|HIGH] |
| -d, --datafile | 백업/복구할 대상 데이터 파일을 지정한다. 지정할 때에는 데이터 파일 번호를 명시해야 하며, 콤마(,)를 사용하여 여러 개를 명시할 수 있다. tbrmgr backup --datafile <DATAFILE#1,DATAFILE#2,...> |
| -t, --tablespace | 백업/복구할 대상 테이블 스페이스를 지정한다. 지정할 때에는테이블 스페이스 이름을 명시해야 하며, 콤마(,)를 사용하여 여러 개를 명시할 수 있다. tbrmgr backup --tablespace <TABLESPACE_NAME1,TABLESPCE_NAME2,...> |
| -T, --skip-tablespace | 백업/복구 대상에서 제외할 테이블 스페이스를 지정한다. 지정할 때에는테이블 스페이스 이름을 명시해야 하며, 콤마(,)를 사용하여 여러 개를 명시할 수 있다. tbrmgr backup --skip-tablespace <TABLESPACE_NAME1,TABLESPACE_NAME2,...> |
| --skip-readonly | 백업/복구 대상에서 Read only 테이블 스페이스들은 제외한다. |
| --skip-offline | 백업/복구 대상에서 Offline 테이블 스페이스들은 제외한다. |
| --untiltime | 시간기반 불완전 복구를 수행한다. 옵션에서 지정한 시간까지 변경된 내용만 복구된다. 시간은 YYYYMMDDHH24MISS의 형식이다. tbrmgr recover --untiltime <YYYYMMDDHH24MISS> |
| --untilchange | 변경 기반 불완전 복구를 수행한다. 옵션에서 지정한 TSN까지 변경된 내용만 복구된다. tbrmgr recover --untilchange <TSN> |
| --from-seq | 해당 옵션 사용하여 아카이브 로그의 특정 시퀀스를 지정할 수 있고, 해당 시퀀스 부터 마지막 시퀀스, 또는 특정 시퀀스까지 백업/복구한다(--to-seq 옵션). 무조건 Redo 스레드를 지정해주어야 한다(--thread 옵션). tbrmgr backup --thread <THREAD#> --from-seq <SEQUENCE#> |
| --to-seq | 해당 옵션 사용하여 아카이브 로그의 특정 시퀀스를 지정할 수 있고, 해당 시퀀스까지 모두 복구한다. 무조건 Redo 스레드를 지정해주고(--thread 옵션), 구간을 정해주어야 한다(--from-seq 옵션). tbrmgr recover --thread <THREAD#> --from-seq <SEQUENCE#> --to-seq <SEQUENCE#> |
| --thread | 아카이브 로그 백업/복구할 때 Redo 스레드를 지정한다. |
| --arc-dest-force | 아카이브 로그 백업/복구할 때 대상 구간에 임의의 아카이브 로그 파일을 찾을 수 없어도 실패하지 않고 진행되게 한다. |
| --delete-original | 아카이브 로그 백업/복구 후 백업 본이 아닌 원본 파일들을 삭제한다. |
| --with-password-file | MOUNT 모드에서 SYS 계정 로그인에 필요한 password file을 함께 백업/복구한다. |
| --no-rollback | 백업 도중 취소/실패하는 경우 기존에 백업한 파일들을 롤백하지 않고 보존한다. |
| --continue | 백업 파일을 가져오지 않고 복구만 진행한다. 주로 아카이브 로그 파일들을 소량씩 가져오며 불완전 복구를 단계적으로 하려고할 때 사용할 수 있다. MOUNT 모드에서만 사용 가능하다. |
| --for-standby | Standby 구축을 위한 백업/복구를 진행한다. 모든 데이터 파일들과 복구에 필요한 아카이브 로그 파일, 그리고 온라인 Redo 로그 파일들까지 백업/복구한다. 클러스터 환경에 대한 제약 사항이 --with-archivelog와 동일하다. NetBackup 연동을 지원하지 않는다. |
| --at-standby | Standby에서의 복구를 진행한다. --for-standby와 다르게 standby에서 별개의 Media recovery를 진행해야할 때 사용된다. |
| --recover-to | Backup Set을 지정한 특정 경로에 가져온 후 복구를 수행한다. 데이터베이스와 컨트롤 파일이 알고 있는 파일들의 경로도 함께 변경된다. Active storage 경로도 가능하다. tbrmgr recover --recover-to <NEW_DIRECTORY> |
| --restore-only | 대상 백업 데이터 파일들을 가져온 후 복구는 수행하지 않는다. MOUNT 또는 NORMAL 모드에서 사용 가능하며, NORMAL 모드에서는 무조건 Offline 테이블 스페이스들을 지정해야 한다. tbrmgr recover --restore-only |
| --restore-archive-only | 대상 백업 아카이브 로그 파일들을 가져온 후 복구는 수행하지 않는다. 무조건 --from-seq, --to-seq, --thread 옵션을 함께 사용해야 한다. MOUNT 또는 NORMAL 모드에서 사용 가능하다. NetBackup을 사용하는 경우 USE_NBU_FOR_ARCHIVELOG=Y인 경우엔 옵션 사용이 불가하다. |
| --restore-incremental-only | 대상 incremental backup 파일들을 가져와서 대응되는 데이터파일과 병합한다. 단, incremental backup이 백업될 당시 기준으로 한 full backup 데이터파일 상태여야한다. 이 기능은 주로 테스트 장비에서 full backup set으로 resetlogs 부팅하여 테스트 후, flashback database로 full backup set 상태로 다시 돌아오고 나서 사용된다. 즉, 해당 상태에서 운영기의 incremental backup을 병합하여 테스트 장비가 운영기를 간헐적 동기화 될 수 있게 한다. MOUNT 또는 NORMAL 모드에서 사용 가능하다. |
| --incrementally-updated | 존재하는 full backup set을 해당 backup set을 base로 하는 incremental/cumulative backup set로 incremental update한다. 즉, 존재하는 full backup set과 incremental/cumulative backup set을 병합하여 하나의 full backup set으로 만드는 기능이다. 이를 통해 저장 공간 확보 및 추후 복구 시간 축소의 장점을 갖는다. |
| --wallet | 암호화된 테이블 스페이스에 접근하기 위한 인증작업을 수행한다. 사용자가 명시한 PASSWORD를 통해 WALLET을 열고 복구를 시작한다. tbrmgr recover --wallet <WALLET_PASSWORD> |
| -b, --backup-set | 지정한 Backup Set을 삭제하거나 복구 시에는 지정한 Backup Set부터 탐색하여 가져온다. |
| --archivelog | 컨트롤 파일에 기록된 아카이브 로그들을 삭제하고, 사용자가 경로를 지정한 경우에는 해당 경로에 있는 아카이브 로그들도 삭제한다. --beforetime, --beforechange 혹은 --sent-to-standby 옵션과 같이 사용되어야 한다. |
| --beforetime | 명시한 시점 이전의 Backup Set들 혹은 아카이브 로그들을 삭제한다. 시간은 YYYYMMDDHH24MISS의 형식이다. tbrmgr delete --beforetime <YYYYMMDDHH24MISS> |
| --beforechange | 명시한 TSN 이전의 아카이브 로그들을 삭제한다. |
| --redundancy | 명시한 숫자만큼의 full backup set 개수보다 오래된 backup set들을 삭제한다. |
| --recovery-window | 명시한 숫자만큼의 일 수보다 오래된 backup set들을 삭제한다. |
| --cf-only | 실제 Backup Set 혹은 아카이브 로그의 물리적 파일은 삭제하지 않고 컨트롤 파일에서만 정보를 삭제한다. 백업 파일을 사용자가 수동으로 삭제하였거나, 삭제 대상 Backup Set을 물리적으로 찾지 못할 때 사용 가능하다. |
| --sent-to-standby | Standby로 전송이 완료된 아카이브 로그들을 삭제한다. --archivelog 옵션과 같이 사용되어야 하며, --beforetime 또는 --beforechange와 같이 사용될 수 있다. |
| --switch | 데이터베이스의 파일이름을 Backup Set의 백업 파일의 이름으로 바꿔준다. 테이블 스페이스를 지정할 수 있다. NetBackup을 사용한 Backup Set에 대해서는 지원하지 않는다. tbrmgr recover --switch |
| --no-image-logging | 백업을 수행할 때 기존의 image logging 방식이 아닌 block consistency check 방식을 이용한다. standby에서 백업을 수행할 경우 옵션 사용 여부 상관없이 block consistency check 방식으로 진행한다. 백업에 소요되는 시간은 늘어나지만 백업하는 동안 발생하는 온라인 redo 로그의 크기는 줄어든다. |
본 절에서는 다음의 백업/복구 시나리오를 통해서 RMGR을 이용한 백업/복구를 설명한다.
RMGR의 Online(Full / Incremental) Backup을 통해 생성된 Backup Set을 이용하여 복구를 수행하기 위해서는 Archive Log File이 반드시 필요하다. 따라서 Archive Log File이 유실될 경우에 대비하여 Online(Full / Incremental) Backup의 경우 Archive Log File도 함께 Backup (--with-archivelog / --archive-only 옵션) 해두는 것이 바람직하다. 또한, TAC 환경에서는 RMGR을 이용한 Archive Log Backup을 위해서는 모든 노드들의 Archive Log File에 접근할 수 있도록, 모든 노드들은 공유 디스크의 동일한 LOG_ARCHIVE_DEST에 Archive Log File을 저장해야한다.
RMGR은 대부분의 과정을 자동으로 진행하기 때문에 사용자가 실행 명령을 통해 작업을 명시해준 이후에는 특별히 관리해야 할 사항이 없다. RMGR이 작업을 진행하는 동안에는 작업의 진행 과정을 살펴볼 수 있다.
RMGR을 통해 Backup을 진행한 이후에는 V$BACKUP_SET을 통해 Backup Set 정보를 조회할 수 있으며, V$BACKUP_ARCHIVED_LOG를 통해 Archive Log Backup 정보를 조회할 수 있다. V$BACKUP_SET_TABLESPACE를 조회하면 각 Backup Set에 대한 테이블 스페이스 정보를 확인할 수 있다.
데이터 파일이 Raw Device 파일 및 Tibero Active Storage인 경우에도 RMGR을 이용한 백업 및 복구가 가능하다. 단, Active Storage를 사용할 때 미리 Active Storage Instance를 설정 및 부팅을 해야 한다.
RMGR을 이용하여 임의의 백업 경로에서 Online Full Backup을 수행할 수 있으며(-o 옵션), 백업 경로를 명시하지 않은 경우에는 RMGR_BACKUP_DEST가 기본 dest로 설정된다.
[예 11.15] Online Full Backup 시나리오
$ tbrmgr backup -o /home/tbrdb/work/7/backup/ ================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ================================================================== ============================================= RMGR - ONLINE backup ============================================= DB connected archive log check succeeded 100.00% |=======================================>| 12800/12800 blks 0.08s Synchronizing... 100.00% |=======================================>| 25600/25600 blks 0.18s Synchronizing... 100.00% |=======================================>| 12800/12800 blks 0.10s Synchronizing... 100.00% |=======================================>| 1280/1280 blks 0.02s Synchronizing... Database full backup succeeded DB disconnected RMGR backup ends $ tbsql sys/tibero SQL> set line 200 SQL> col START_TIME for a20 SQL> col FINISH_TIME for a20 SQL> select * from V$BACKUP_SET a; SET_ID START_TIME ---------- ---------------------------------------------------------------- FINISH_TIME START_TSN ---------------------------------------------------------------- ---------- FINISH_TSN RESETLOGS_TSN BASE_SET SIZE(KB) IS_PARTIAL IS_INCREMENTAL ---------- ------------- ---------- ---------- ---------- -------------- WITH_ARCHIVELOG --------------- 1 2018/06/11 2018/06/11 36321 36338 0 0 453588 NO NO NO 1 row selected. SQL> select * from V$BACKUP_ARCHIVED_LOG; 0 row selected.
데이터를 압축하여 Backup Set을 생성하는 Compress(-c) 옵션과 실제로 사용되지 않은 블록을 백업 대상에서 제외하는 Skip Unused(-u) 옵션을 함께 적용하여 Online Full Backup을 수행할 수 있다.
[예 11.16] Compress 옵션과 Skip Unused 옵션을 적용한 Online Full Backup 시나리오
$ tbrmgr backup -c -u -o /home/tbrdb/work/7/backup/ ================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ================================================================== ============================================= RMGR - ONLINE backup ============================================= DB connected archive log check succeeded 100.00% |=======================================>| 12800/12800 blks 1.00s Synchronizing... 100.00% |=======================================>| 25600/25600 blks 1.85s Synchronizing... 100.00% |=======================================>| 12800/12800 blks 0.00s Synchronizing... 100.00% |=======================================>| 1280/1280 blks 0.06s Synchronizing... Database full backup succeeded DB disconnected RMGR backup ends
RMGR을 이용한 Backup을 수행하는 경우 with Archive Log(--with-archivelog) 옵션을 적용함으로써, 백업 경로에 데이터 파일에 대한 백업과 함께 Archive Log Backup을 생성할 수 있다. Online Backup을 이용하여 복구를 수행하기 위해서는 Archive Log가 반드시 필요하므로, Archive Log Backup을 생성함으로써 원본 Archive Log File이 유실되는 경우에도 정상적으로 복구를 진행할 수 있다.
백업된 아카이브 로그 파일은 다음의 형식으로 관리된다.
bkl_<BACKUPSET#>_t<THREAD#>-r<RESETLOGSTSN>-s<SEQUENCE#>.arc
예를 들어 BACKUPSET#는 1, THREAD#는 0, RESETLOGS TSN는 0, SEQEUNCE#는 1인 경우 파일명은 'bkl_1_t0-r0-s1.arc'이 된다.
V$BACKUP_SET을 조회함으로써 각 Backup Set에 Archive Log Backup이 존재하는지 확인할 수 있으며, V$BACKUP_ARCHIVED_LOG를 조회함으로써 Archive Log Backup의 정보를 확인할 수 있다.
[예 11.17] With Archive Log 옵션을 적용한 Online Full Backup 시나리오
$ tbrmgr backup --with-archivelog -o /home/tbrdb/work/7/backup/ ================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ================================================================== ============================================= RMGR - ONLINE backup ============================================= DB connected archive log check succeeded 100.00% |=======================================>| 12800/12800 blks 0.08s Synchronizing... 100.00% |=======================================>| 25600/25600 blks 0.18s Synchronizing... 100.00% |=======================================>| 12800/12800 blks 0.08s Synchronizing... 100.00% |=======================================>| 1280/1280 blks 0.02s Synchronizing... Database full backup succeeded DB disconnected RMGR backup ends $ tbsql sys/tibero SQL> set line 200 SQL> col START_TIME for a20 SQL> col FINISH_TIME for a20 SQL> select * from V$BACKUP_SET a; SET_ID START_TIME ---------- ---------------------------------------------------------------- FINISH_TIME START_TSN ---------------------------------------------------------------- ---------- FINISH_TSN RESETLOGS_TSN BASE_SET SIZE(KB) IS_PARTIAL IS_INCREMENTAL ---------- ------------- ---------- ---------- ---------- -------------- WITH_ARCHIVELOG --------------- 1 2016/06/16 2016/06/16 34386 34441 0 0 453588 NO NO YES 1 row selected. SQL> set line 200 SQL> col MIN_LOG_TIME for a20 SQL> col MAX_LOG_TIME for a20 SQL> col RESETLOG_TIME for a20 SQL> select * from V$BACKUP_ARCHIVED_LOG a; SET_ID MIN_LOG_TSN MAX_LOG_TSN MIN_LOG_TIME MAX_LOG_TIME ---------- ----------- ----------- -------------------- -------------------- 1 34386 34441 2016/06/16 2016/06/16 MIN_LOG_SEQUENCE MAX_LOG_SEQUENCE RESETLOG_TSN RESETLOG_TIME ---------------- ---------------- ------------ -------------------- 2 2 0 1 row selected.
앞서 Online Full Backup을 통해 생성된 Full Backup Set이 최소 1개 이상 존재하는 경우에는 가장 최신의 Backup Set과 현재 상태를 비교하여 변경사항만을 백업하는 Incremental Backup을 수행할 수 있다. 변경사항만을 백업하므로 Full Backup Set에 비해 Backup Set의 Size를 획기적으로 줄일 수 있지만, 앞선 Backup Set이 유실되어 비교 대상이 사라지게 되면 Backup Set을 데이터베이스 복구에 사용할 수 없는 위험성이 존재한다.
V$BACKUP_SET을 조회함으로써 각 Backup Set이 Incremental Backup Set인지 확인할 수 있으며, Incremental Backup의 경우 비교 대상이 되는 Backup Set(Base Set)의 ID를 확인할 수 있다. Full Backup Set의 경우 Base Set이 존재하지 않으므로 Base Set ID가 0으로 표기된다.
[예 11.18] With Archive Log 옵션을 적용한 Incremental Backup 시나리오
$ tbrmgr backup -i --with-archivelog -o /home/tbrdb/work/7/backup/ ================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ================================================================== ============================================= RMGR - INCREMENTAL backup ============================================= DB connected archive log check succeeded 100.00% |=======================================>| 12800/12800 blks 0.04s Synchronizing... 100.00% |=======================================>| 25600/25600 blks 0.04s Synchronizing... 100.00% |=======================================>| 12800/12800 blks 0.02s Synchronizing... 100.00% |=======================================>| 1280/1280 blks 0.02s Synchronizing... Database incremental backup succeeded DB disconnected RMGR backup ends $ tbsql sys/tibero SQL> set line 200 SQL> col START_TIME for a20 SQL> col FINISH_TIME for a20 SQL> select * from V$BACKUP_SET a; SET_ID START_TIME ---------- ---------------------------------------------------------------- FINISH_TIME START_TSN ---------------------------------------------------------------- ---------- FINISH_TSN RESETLOGS_TSN BASE_SET SIZE(KB) IS_PARTIAL IS_INCREMENTAL ---------- ------------- ---------- ---------- ---------- -------------- WITH_ARCHIVELOG --------------- 1 2016/06/16 2018/06/11 34386 34441 0 0 453588 NO NO YES 2 2016/06/16 2018/06/11 34448 35234 0 1 23730 NO YES YES 2 rows selected. SQL> set line 200 SQL> col MIN_LOG_TIME for a20 SQL> col MAX_LOG_TIME for a20 SQL> col RESETLOG_TIME for a20 SQL> select * from V$BACKUP_ARCHIVED_LOG a; SET_ID MIN_LOG_TSN MAX_LOG_TSN MIN_LOG_TIME MAX_LOG_TIME ---------- ----------- ----------- -------------------- -------------------- 1 34386 34441 2016/06/16 2016/06/16 2 34448 35234 2016/06/16 2016/06/16 MIN_LOG_SEQUENCE MAX_LOG_SEQUENCE RESETLOG_TSN RESETLOG_TIME ---------------- ---------------- ------------ -------------------- 2 2 0 6 6 0 2 row selected.
RMGR은 Online Full Backup을 통해 생성된 Backup Set을 이용하여 복구를 수행할 수 있다. 아래 예제는 Backup Set에 Archive Log Backup이 존재하지 않는 경우로, 이 경우에는 원본 Archive Log File을 가지고 있어야 복구를 진행할 수 있다.
[예 11.19] Online Full Backup을 이용한 복구 시나리오
$ tbsql sys/tibero SQL> set line 200 SQL> col START_TIME for a20 SQL> col FINISH_TIME for a20 SQL> select * from V$BACKUP_SET a; SET_ID START_TIME ---------- ---------------------------------------------------------------- FINISH_TIME START_TSN ---------------------------------------------------------------- ---------- FINISH_TSN RESETLOGS_TSN BASE_SET SIZE(KB) IS_PARTIAL IS_INCREMENTAL ---------- ------------- ---------- ---------- ---------- -------------- WITH_ARCHIVELOG --------------- 1 2016/06/16 2016/06/16 34386 34441 0 0 453588 NO NO NO 1 row selected. SQL> quit Disconnected. $ tbrmgr recover -o /home/tbrdb/work/7/backup/ ================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ================================================================== ============================================= RMGR - recovery ============================================= Tibero instance terminated (ABNORMAL mode). Control file #0 (/home/tbrdb/work/7/database/TB7/c1.ctl) is accessible Listener port = 45648 Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (MOUNT mode). DB Connected RMGR BEGIN RESTORE full backup set_id: 1 last incremental backup set_id: 1 Applying FULL BACKUP (set_id:1, ts_id:0, df_id:0) 100.00% |=======================================>| 12800/12800 blks 0.00s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:1, df_id:1) 100.00% |=======================================>| 25600/25600 blks 0.20s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:3, df_id:2) 100.00% |=======================================>| 12800/12800 blks 0.00s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:4, df_id:3) 100.00% |=======================================>| 1280/1280 blks 0.00s Synchronizing... Database restore succeeded recoverSQL: ALTER DATABASE RECOVER AUTOMATIC Database automatic recovery succeeded DB disconnected Tibero instance terminated (NORMAL mode). Listener port = 45648 Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (NORMAL mode). RMGR recovery ends
RMGR은 Online Full Backup을 통해 생성된 Backup Set을 이용하여 데이터베이스 복구를 수행할 수 있다. 아래 예제는 원본 Archive Log File이 유실된 경우로, with Archive Log(--with-archivelog) 옵션을 통해 Archive Log Backup을 Restore하는 경우에는 정상적으로 복구가 진행되지만, with Archive Log(--with-archivelog) 옵션을 적용하지 않고 복구를 수행하는 경우에는 복구에 실패하는 것을 확인할 수 있다.
[예 11.20] Online Full Backup과 Archive Log Backup을 이용한 복구 시나리오
$ tbsql sys/tibero SQL> set line 200 SQL> col START_TIME for a20 SQL> col FINISH_TIME for a20 SQL> select * from V$BACKUP_SET a; SET_ID START_TIME ---------- ---------------------------------------------------------------- FINISH_TIME START_TSN ---------------------------------------------------------------- ---------- FINISH_TSN RESETLOGS_TSN BASE_SET SIZE(KB) IS_PARTIAL IS_INCREMENTAL ---------- ------------- ---------- ---------- ---------- -------------- WITH_ARCHIVELOG --------------- 1 2016/06/16 2016/06/16 34386 34441 0 0 453588 NO NO YES 1 row selected. SQL> set line 200 SQL> col MIN_LOG_TIME for a20 SQL> col MAX_LOG_TIME for a20 SQL> col RESETLOG_TIME for a20 SQL> select * from V$BACKUP_ARCHIVED_LOG a; SET_ID MIN_LOG_TSN MAX_LOG_TSN MIN_LOG_TIME MAX_LOG_TIME ---------- ----------- ----------- -------------------- -------------------- 1 34386 34441 2016/06/15 2016/06/16 MIN_LOG_SEQUENCE MAX_LOG_SEQUENCE RESETLOG_TSN RESETLOG_TIME ---------------- ---------------- ------------ -------------------- 2 2 0 1 row selected. SQL> quit Disconnected. $ tbrmgr recover -o /home/tbrdb/work/7/backup/ ================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ================================================================== ============================================= RMGR - recovery ============================================= Tibero instance terminated (ABNORMAL mode). Control file #0 (/home/tbrdb/work/7/database/TB7/c1.ctl) is accessible Listener port = 45648 Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (MOUNT mode). DB Connected RMGR BEGIN RESTORE full backup set_id: 1 last incremental backup set_id: 1 Applying FULL BACKUP (set_id:1, ts_id:0, df_id:0) 100.00% |=======================================>| 12800/12800 blks 0.00s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:1, df_id:1) 100.00% |=======================================>| 25600/25600 blks 0.20s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:3, df_id:2) 100.00% |=======================================>| 12800/12800 blks 0.00s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:4, df_id:3) 100.00% |=======================================>| 1280/1280 blks 0.00s Synchronizing... Database restore succeeded recoverSQL: ALTER DATABASE RECOVER AUTOMATIC RMGR Error: recovery failed (automatic recovery failed) SVR Error: Unable to find archive log file for thread 0 from change 34428. $ tbrmgr recover --with-archivelog -o /home/tbrdb/work/7/backup/ ================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ================================================================== ============================================= RMGR - recovery ============================================= Tibero instance terminated (ABNORMAL mode). Control file #0 (/home/tbrdb/work/7/database/TB7/c1.ctl) is accessible Listener port = 45648 Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (MOUNT mode). DB Connected RMGR BEGIN RESTORE full backup set_id: 1 last incremental backup set_id: 1 Applying FULL BACKUP (set_id:1, ts_id:0, df_id:0) 100.00% |=======================================>| 12800/12800 blks 0.00s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:1, df_id:1) 100.00% |=======================================>| 25600/25600 blks 0.20s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:3, df_id:2) 100.00% |=======================================>| 12800/12800 blks 0.00s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:4, df_id:3) 100.00% |=======================================>| 1280/1280 blks 0.00s Synchronizing... Database restore succeeded recoverSQL: ALTER DATABASE RECOVER AUTOMATIC Database automatic recovery succeeded DB disconnected Tibero instance terminated (NORMAL mode). Listener port = 45648 Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (NORMAL mode). RMGR recovery ends
RMGR은 Online Full Backup을 통해 생성된 Backup Set과 Incremental Backup을 통해 생성된 Backup Set을 자동으로 Merge하여 복구를 진행한다.
[예 11.21] Online Full Backup과 Incremental Backup을 이용한 복구 시나리오
$ tbsql sys/tibero SQL> set line 200 SQL> col START_TIME for a20 SQL> col FINISH_TIME for a20 SQL> select * from V$BACKUP_SET a; SET_ID START_TIME ---------- ---------------------------------------------------------------- FINISH_TIME START_TSN ---------------------------------------------------------------- ---------- FINISH_TSN RESETLOGS_TSN BASE_SET SIZE(KB) IS_PARTIAL IS_INCREMENTAL ---------- ------------- ---------- ---------- ---------- -------------- WITH_ARCHIVELOG --------------- 1 2016/06/16 2018/06/11 34386 34441 0 0 453588 NO NO YES 2 2016/06/16 2018/06/11 34448 35234 0 1 23730 NO YES YES 2 rows selected. SQL> set line 200 SQL> col MIN_LOG_TIME for a20 SQL> col MAX_LOG_TIME for a20 SQL> col RESETLOG_TIME for a20 SQL> select * from V$BACKUP_ARCHIVED_LOG a; SET_ID MIN_LOG_TSN MAX_LOG_TSN MIN_LOG_TIME MAX_LOG_TIME ---------- ----------- ----------- -------------------- -------------------- 1 34386 34441 2016/06/16 2016/06/16 2 34448 35234 2016/06/16 2016/06/16 MIN_LOG_SEQUENCE MAX_LOG_SEQUENCE RESETLOG_TSN RESETLOG_TIME ---------------- ---------------- ------------ -------------------- 2 2 0 6 6 0 2 row selected. SQL> quit Disconnected. $ tbrmgr recover --with-archivelog -o /home/tbrdb/work/7/backup ================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ================================================================== ============================================= RMGR - recovery ============================================= Tibero instance terminated (ABNORMAL mode). Control file #0 (/home/tbrdb/work/7/database/TB7/c1.ctl ) is accessible Listener port = 45648 Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (MOUNT mode). DB Connected RMGR BEGIN RESTORE full backup set_id: 1 last incremental backup set_id: 2 Applying FULL BACKUP (set_id:1, ts_id:0, df_id:0) 100.00% |=======================================>| 12800/12800 blks 0.00s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:1, df_id:1) 100.00% |=======================================>| 25600/25600 blks 0.20s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:3, df_id:2) 100.00% |=======================================>| 12800/12800 blks 0.00s Synchronizing... Applying FULL BACKUP (set_id:1, ts_id:4, df_id:3) 100.00% |=======================================>| 1280/1280 blks 0.00s Synchronizing... Applying INCREMENTAL BACKUP (set_id:2, ts_id:0, df_id:0) 100.00% |=======================================>| 12800/12800 blks 0.60s Synchronizing... Applying INCREMENTAL BACKUP (set_id:2, ts_id:1, df_id:1) 100.00% |=======================================>| 25600/25600 blks 1.20s Synchronizing... Applying INCREMENTAL BACKUP (set_id:2, ts_id:3, df_id:2) 100.00% |=======================================>| 12800/12800 blks 0.80s Synchronizing... Applying INCREMENTAL BACKUP (set_id:2, ts_id:4, df_id:3) 100.00% |=======================================>| 1280/1280 blks 0.00s Synchronizing... Database restore succeeded recoverSQL: ALTER DATABASE RECOVER AUTOMATIC Database automatic recovery succeeded DB disconnected Tibero instance terminated (NORMAL mode). Listener port = 45648 Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (NORMAL mode). RMGR recovery ends
RMGR은 사용자가 Tablespace Name으로 지정한(--tablespace 옵션) 특정 테이블 스페이스에 대해서만 복구를 수행할 수 있다. V$BACKUP_SET_TABLESPACE을 조회함으로써 각 Backup Set에 포함된 테이블 스페이스를 확인할 수 있다.
[예 11.22] Tablespace 기반 복구 시나리오
$ tbsql sys/tibero SQL> set line 200 SQL> col NAME for a20 SQL> select * from V$TABLESPACE a; TS# NAME TYPE BIGFILE FLASHBACK_ON ---------- -------------------- ---- ------- ------------ 0 SYSTEM DATA NO NO 1 UNDO UNDO NO NO 2 TEMP TEMP NO NO 3 USR DATA NO NO 4 SYSSUB DATA NO NO 5 rows selected. SQL> select * from V$BACKUP_SET_TABLESPACE; SET_ID TS# ---------- ---------- 1 0 1 1 1 3 1 4 4 rows selected. SQL> quit Disconnected. $ tbrmgr recover --tablespace USR -o /home/tbrdb/work/7/backup/ ================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ================================================================== ============================================= RMGR - recovery ============================================= Tibero instance terminated (ABNORMAL mode). Control file #0 (/home/tbrdb/work/7/database/TB7/c1.ctl) is accessible Listener port = 45648 Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (MOUNT mode). DB Connected RMGR BEGIN RESTORE full backup set_id: 1 last incremental backup set_id: 1 Applying FULL BACKUP (set_id:1, ts_id:3, df_id:2) 100.00% |=======================================>| 12800/12800 blks 0.00s Synchronizing... Database restore succeeded recoverSQL: ALTER DATABASE RECOVER AUTOMATIC Database automatic recovery succeeded DB disconnected Tibero instance terminated (NORMAL mode). Listener port = 45648 Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (NORMAL mode). RMGR recovery ends
본 절에서는 다음의 백업 삭제 시나리오를 통해서 RMGR을 이용한 백업 삭제를 설명한다.
RMGR을 이용하여 Backup Set을 삭제하는 경우, 삭제 대상이 되는 Target Backup Set은 두 가지 방식으로 지정할 수 있다. 첫 번째로 Backup Set ID(--backup_set 옵션)를 명시하여 해당 Backup Set만을 삭제할 수 있으며, 두 번째로 Backup Date(--beforetime 옵션)를 명시하여 명시한 Backup Date 이전에 백업이 이루어진 모든 Backup Set들을 삭제할 수 있다.
RMGR은 컨트롤 파일을 참조하여 삭제 대상으로 지정된 Backup Set의 존재 유무와 백업 경로를 확인한 후 삭제를 진행한다. 따라서 컨트롤 파일에서 참조할 수 없는 Backup Set은 RMGR을 이용하여 삭제할 수 없으며, Backup Set이 존재하는 백업 경로가 백업할 때 컨트롤 파일에 등록된 백업 경로와 다른 경우에는 Backup Dest(-o 옵션)를 직접 명시해주어야 변경된 백업 경로에서 실제 백업된 파일에 대한 삭제를 진행할 수 있다.
컨트롤 파일에 등록되어 있는 Backup Set 정보는 V$BACKUP_SET을 통해 조회할 수 있으며, 각 Backup Set에 속하는 Archive Log 정보는 V$BACKUP_ARCHIVED_LOG를 통해 조회할 수 있다.
컨트롤 파일에 등록된 Backup Set을 사용자가 수동으로 삭제하였거나, 잘못된 백업 경로를 명시하여 백업 경로에서 삭제 대상으로 지정된 Backup Set을 찾을 수 없는 경우에는 컨트롤 파일에 등록된 Backup Set Entry만을 삭제하고 종료한다. 또한 테이프 장비에 저장된 경우 역시 컨트롤 파일에 등록된 Backup Set Entry만을 삭제하고 종료한다.
RMGR은 사용자가 Backup Set ID로 지정한(--backup_set 옵션) 특정 Backup Set만을 선택적으로 삭제할 수 있다.
다음 예제에서는 RMGR을 이용하여 Backup Set ID = 1에 해당하는 Backup Set을 삭제한다.
[예 11.23] Backup Set ID에 기반한 백업 삭제 시나리오
$ tbsql sys/tibero SQL> set line 200 SQL> col START_TIME for a20 SQL> col FINISH_TIME for a20 SQL> select * from V$BACKUP_SET a; SET_ID START_TIME ---------- ---------------------------------------------------------------- FINISH_TIME START_TSN ---------------------------------------------------------------- ---------- FINISH_TSN RESETLOGS_TSN BASE_SET SIZE(KB) IS_PARTIAL IS_INCREMENTAL ---------- ------------- ---------- ---------- ---------- -------------- WITH_ARCHIVELOG --------------- 1 2018/06/11 2018/06/11 37093 37109 0 0 453588 NO NO YES 2 2018/06/11 2018/06/11 37361 37377 0 0 453588 NO NO YES 3 2018/06/11 2018/06/11 37390 37406 0 0 453588 NO NO YES 3 rows selected. SQL> quit Disconnected. $ tbrmgr delete --backup_set 1 -o /home/tbrdb/work/7/backup ================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ================================================================== ============================================= RMGR - delete ============================================= DB connected #1 of #3 backup sets erased RMGR delete ends $ tbsql sys/tibero SQL> set line 200 SQL> col START_TIME for a20 SQL> col FINISH_TIME for a20 SQL> select * from V$BACKUP_SET a; SET_ID START_TIME ---------- ---------------------------------------------------------------- FINISH_TIME START_TSN ---------------------------------------------------------------- ---------- FINISH_TSN RESETLOGS_TSN BASE_SET SIZE(KB) IS_PARTIAL IS_INCREMENTAL ---------- ------------- ---------- ---------- ---------- -------------- WITH_ARCHIVELOG --------------- 2 2018/06/11 2018/06/11 37361 37377 0 0 453588 NO NO YES 3 2018/06/11 2018/06/11 37390 37406 0 0 453588 NO NO YES 2 rows selected.
RMGR은 사용자가 Backup Date로 지정한(--beforetime 옵션) 시간 이전에 생성된 모든 Backup Set을 삭제할 수 있다.
다음 예제에서는 RMGR을 이용하여 "2016년 06월 17일 12시" 이전에 생성된 모든 Backup Set을 삭제한다. Backup Date는 YYYYMMDDHH24MISS 형태로 명시한다.
[예 11.24] Backup Date에 기반한 백업 삭제 시나리오
$ tbsql sys/tibero SQL> set line 200 SQL> col START_TIME for a20 SQL> col FINISH_TIME for a20 SQL> select * from V$BACKUP_SET a; SET_ID START_TIME ---------- ---------------------------------------------------------------- FINISH_TIME START_TSN ---------------------------------------------------------------- ---------- FINISH_TSN RESETLOGS_TSN BASE_SET SIZE(KB) IS_PARTIAL IS_INCREMENTAL ---------- ------------- ---------- ---------- ---------- -------------- WITH_ARCHIVELOG --------------- 2 2018/06/11 2018/06/11 37361 37377 0 0 453588 NO NO YES 3 2018/06/11 2018/06/11 37390 37406 0 0 453588 NO NO YES 2 rows selected. SQL> quit Disconnected. $ tbrmgr delete --beforetime 20180612120000 -o /home/tbrdb/work/7/backup/ ================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ================================================================== ============================================= RMGR - delete ============================================= DB connected #2 of #2 backup sets erased RMGR delete ends $ tbsql sys/tibero SQL> set line 200 SQL> col START_TIME for a20 SQL> col FINISH_TIME for a20 SQL> select * from V$BACKUP_SET a; 0 rows selected.
NetBackup은 엔터프라이즈 백업 및 복구 소프트웨어로서, 다양한 환경에 대한 완벽하고 유연한 데이터 보호 솔루션을 제공한다.
Tibero에서 복구 관리자를 사용해서 Veritas NetBackup으로 백업 파일 저장 및 복원할 수 있다. 아래에서 소개할 Tibero와 NetBackup 연동을 위해서는 NetBackup과 Tibero가 정상적으로 설치되어 있어야 한다.
1. NetBackup 연동을 위해서는 TmaxData 기술지원에 요청하여 NetBackup 연동이 가능한 Tibero를 별도로 제공 받아야 한다.
2. NetBackup 설치 및 관리에 대한 자세한 내용은 "NetBackup Documentation"을 참고한다.
복구 관리자를 사용해서 NetBackup의 백업 파일 저장 및 복원하기 위해서 라이브러리를 연결하고, NetBackup 서버 및 클라이언트의 기본 정보를 설정해야 한다.
초기 상태에는 $TB_HOME/client/lib에 있는 dummy 라이브러리들과 연결되어 있다. dummy 라이브러리들은 사용하지 않으면 삭제하거나 직접 NetBackup 관련 라이브러리를 연결해주어야 한다.
32bit 환경
libnbclientcST32.so
libnbbasecST32.so
libxbsa.so
libvxcPBXST.so
64bit 환경
libnbclientcST.so
libnbbasecST.so
libxbsa64.so
libvxcPBXST.so
NetBackup 서버가 설치된 머신의 /etc/hosts 파일에 해당 머신의 호스트와 IP 주소 및 NetBackup 클라이언트가 설치된 머신들의 호스트와 IP 주소를 추가한다.
NetBackup 서버가 설치된 머신에서 NetBackup이 설치된 경로에 db/altnames 디렉터리를 생성한 후 NetBackup 클라이언트가 설치된 머신들의 호스트를 이름으로 가지는 빈 파일을 생성한다.
NetBackup 클라이언트가 설치된 머신의 /etc/hosts 파일에 NetBackup 서버가 설치된 머신의 호스트와 IP 주소를 추가하고, 해당 머신의 호스트와 IP 주소를 추가한다.
NetBackup 클라이언트가 설치된 머신에서 NetBackup이 설치된 경로에 있는 bp.conf 파일에 다음의 내용을 추가한다.
SERVER=[NetBackup 서버가 설치된 머신의 호스트] CLIENT_NAME=[NetBackup 클라이언트가 설치된 머신의 호스트]
다음은 복구 관리자를 사용하기 위해서 NetBackup 관리자 환경을 설정하는 방법에 대한 설명이다.
NetBackup 관리자 콘솔이 설치된 머신의 /etc/hosts에 NetBackup 마스터가 설치된 머신의 호스트와 IP 주소를 추가한다.
NetBackup 관리자 콘솔 실행한 후 NetBackup 마스터가 설치된 머신의 root와 해당하는 비밀번호로 접속한다.
NetBackup 관리자 콘솔의 [Master Server] 탭에서 'Configure Disk Storage Servers'를 선택하여 NetBackup 마스터에서 사용할 디스크를 'AdvancedDisk'로 선택한다. ReadyStream 이후 실제 백업에 사용할 디렉터리를 선택한다.
NetBackup 관리자 콘솔 [Policies] 탭에서 New Policy를 생성한다. Policy의 이름은 NBU_BACKUP_POLICY_NAME, NBU_ARCHIVE_POLICY_NAME iparam에서 설정한 값으로 생성한다.
[Attributes] 탭의 'Policy type'을 'DataStore'로 생성하고 그외는 임의로 설정한다. [Clients] 탭에서 [New] 버튼을 클릭하고 NetBackup 클라이언트를 설치한 머신을 등록한다.
NetBackup 관리자 콘솔의 [Host Properties] 탭에 있는 [Clients] 탭에 앞서 등록한 NetBackup 클라이언트 머신이 표시되고 실제 정보와 일치하는지 확인한다.
복구 관리자의 옵션 중 -p, --parallel 옵션을 사용할 수 있도록 아래와 같이 설정한다.
Storage unit 설정에서 해당 스토리지에 Maximum concurrent jobs를 parallel로 실행될 thread 개수의 최대값으로 설정한다(Tibero는 최대 16개를 parallel로 사용하고 있다).
Master server 설정에서 [Global Attribute] 탭에 있는 Maximum jobs per client 값을 하나의 클라이언트에서 parallel로 실행될 thread 개수의 최대값으로 설정한다.
Master server 설정에서 [Client Attribute] 탭에 있는 Maximum data streams 값을 하나의 클라이언트에서 parallel로 실행될 thread 개수의 최대값으로 설정한다.
Policy 설정에 있는 [Schedules Tab]의 스케줄마다 설정에서 Media multiplexing 값을 하나의 클라이언트에서 parallel로 실행될 thread 개수의 최대값으로 설정한다.
NetBackup에서는 백업 파일에 대한 권한 관리가 이루어지 때문에 복구 관리자를 위한 파라미터들이 정상적으로 설정되지 않은 상태에서 백업이 수행되면 복구가 불가능해질 수 있다.
다음은 복구 관리자의 환경설정에 사용되는 파라미터에 대한 설명이다. 각 파라미터는 동적 설정이 가능하다.
| 파라미터 | 설명 |
|---|---|
| USE_NBU_FOR_BACKUPSET | 다음은 설정값에 대한 설명이다.
TAC 환경에서는 모든 노드가 동일한 값으로 설정되어 있어야 한다. |
| USE_NBU_FOR_ARCHIVELOG | 설정 값이 Y일 경우 데이터베이스에서 생성되는 아카이브 로그가 NetBackup 서버에 전송되어 생성되며, 복구할 때에도 NetBackup 머신에 존재하는 아카이브 로그를 읽어 복구를 진행한다. (기본값: N) [참고] USE_NBU_FOR_ARCHIVELOG=Y일 경우 with-archivelog, archive-only, restore-archive-only 기능은 지원하지 않는다. |
| NBU_ARCHIVELOG_SEARCH | 설정 값이 Y일 경우 NetBackup에 생성된 아카이브 로그들을 v$archive_dest_files로 조회 가능하고 이를 읽어 복구할 수 있다. (기본값: N) |
| NBU_OBJ_OWNER_NAME | NetBackup을 통해 생성되는 백업 파일의 권한을 해당 파라미터에 설정한 값으로 설정해주며, 복구할 때에는 해당 파라미터의 값이 아닌 클라이언트 머신에서 로그인한 username을 참고한다. (기본값: "") |
| NBU_OBJ_OWNER_GROUP_NAME | NetBackup을 통해 생성되는 백업 파일의 권한을 해당 파라미터에 설정한 값으로 설정해주며, 복구할 때에는 해당 파라미터의 값이 아닌 클라이언트 머신에서 로그인한 group anme을 참고한다. 해당 값을 설정해주지 않으면 NBU_OBJ_OWNER_NAME으로 설정해준 user name에만 권한이 있게된다. (기본값: "") |
| NBU_CLIENT_COUNT | Tibero 인스턴스가 위치하는 독립적인 머신을 숫자로 설정한다. 0에서 10 사이로 설정해주어야 하며, NBU_ARCHIVELOG_SEARCH를 Y로 설정한 경우 NBU_CLIENT_COUNT의 값과 NBU_CLIENT_HOSTNAME_#의 수가 같아야 한다. (기본값: 0) |
| NBU_CLIENT_HOSTNAME_# | SID#N을 인스턴스 ID로 갖는 Tibero 인스턴스가 위치하는 머신의 호스트로 #을 0부터 시작해 설정한다. (기본값: "") |
| NBU_SKIP_HOST_CHECK | 설정값이 Y일 경우 Tibero 인스턴스가 위치하는 머신의 호스트와 NBU_CLIENT_HOSTNAME_0에 설정되어 있는 값이 같은지 비교하지 않는다. (기본값: N) |
| NBU_BACKUP_INST_SID | NBU_CLIENT_HOSTNAME_0에 설정된 머신의 호스트에 해당하는 Tibero 인스턴스의 SID로 설정한다. (기본값: "") |
for-standby 기능은 지원하지 않는다.
연동 절차가 모두 완료된 후 복구 관리자로 백업을 수행했을 때 아래와 같이 NetBackup에 백업한다는 메시지가 찍히고 백업이 정상적으로 진행된다면 연동에 성공한 것이다.
[예 11.25] NetBackup 시나리오
$ tbrmgr backup ============================================================================== = Recovery Manager(RMGR) starts = = = = TmaxData Corporation Copyright (c) 2008-. All rights reserved. = ============================================================================== RMGR '-n' option not used (USE_NBU_FOR_BACKUPSET=Y) :backing up to RMGR_NBU_BACKUP_DEST= /tibero/ ============================================================================== RMGR - Backup (FULL) ============================================================================== Initializing the backup progress, it may take few minutes... BACKUP (set_id: 1, ts_id: 0, df_id: 0) 100.00% |===============================>| 12800/12800 blks 16.01s Synchronizing... BACKUP (set_id: 1, ts_id: 1, df_id: 1) 100.00% |===============================>| 25600/25600 blks 17.02s Synchronizing... BACKUP (set_id: 1, ts_id: 3, df_id: 2) 100.00% |===============================>| 12800/12800 blks 16.01s Synchronizing... BACKUP (set_id: 1, ts_id: 4, df_id: 3) 100.00% |===============================>| 1280/1280 blks 15.04s Synchronizing... Switching an online logfile... Backing up the control file... Control file backup seucceeded Database backup succeeded RMGR backup ends $ tbsql sys/tibero SQL> select * from V$BACKUP_SET; SET_ID STATUS ---------- ------------------------------------- START_TIME FINISH_TIME ELAPSED(SEC) -------------------- -------------------- ------------ START_TSN FINISH_TSN RESETLOGS_TSN SIZE(MB) BASE_SET BACKUP_TYPE ---------- ---------- ------------- ---------- ---------- ------------ BACKUP_OPTION PARTIAL_BACKUP_OPTION ---------------------------------------- -------------------------------------- BACKUP_PATH ------------------------------------------------------------------------------- 1 COMPLETED 2020/12/30 2020/12/30 83 36321 36338 0 445 0 FULL NET_BACKUP NONE /tibero/ 1 row selected.
앞서 기술한 미지원 기능 목록을 제외한 나머지 복구 관리자 기능 역시 수행하여 위와 동일한 메시지를 확인할 수 있다면 NetBackup 연동에 성공한 것으로 볼 수 있다. 복구 관리자에서 실제로 생성된 백업 파일 이름, 갯수와 NetBackup에서 생성되는 파일 이름, 갯수가 다른 사실은 복구에 영향을 주지 않는다.
Tibero는 다양한 백업 및 복구 시나리오를 제공하지만, 백업 파일 용량이 매우 클 때는 백업 파일 복원과 이후 복구까지 굉장히 오랜 시간이 걸릴 수 있다. 특히, 유저의 실수를 만회하고자 데이터베이스를 아주 가까운 과거로 되돌리기 위해서도 백업 파일을 복원해야 한다는 점 때문에 시간 소요가 너무 크다.
이러한 면을 보완하기 위하여 Tibero는 백업 파일 없이도 DB 전체를 과거로 되돌릴 수 있는 플래시백 데이터베이스(Flashback Database) 기능을 제공한다.
플래시백 데이터베이스는 단어 의미 그대로 데이터베이스를 가까운 과거로 빠르게 되돌릴 수 있는 기능이다. SQL 명령어 ALTER DATABASE 구문으로 플래시백 로그 파일 관리 및 플래시백 수행 가능하다.
Tibero 플래시백 데이터베이스 기능의 특징은 다음과 같다.
데이터베이스를 과거로 되돌리기 위한 플래시백 로그 파일을 따로 생성하고 관리한다. 추가적인 로그 파일을 생성하기 때문에 데이터베이스 성능 저하는 불가피하다. 플래시백 로그 파일은 “11.1. Tibero 구성 파일”을 참고한다.
Flashback Marker 시점까지 데이터베이스를 과거로 되돌린 후 사용자가 입력한 시점까지 불완전 복구한다. Flashback Marker는 블록의 변경되는 이미지를 플래시백 로그 파일에 로깅하는 기준이다.
사용자가 SQL 구문을 통해 직접 추가할 수 있으며, 초기화 파라미터 FLASHBACK_MARKER_INTERVAL(단위: 초)를 설정하여 백그라운드 작업으로 주기적으로 남기게 할 수 있다. Flashback Marker는 자주 남길 수록 플래시백 데이터베이스 기능 수행이 빠르지만, 그만큼 플래시백 로그가 많이 생성되기에 데이터베이스 운영 성능이 더 저하된다.
백업 파일들 복원하지 않고 특정 과거 시점으로 데이터베이스를 회귀시킬 수 있다.
백업 파일 복원 후 불완전 복구와 효과는 같지만, 총 작업 시간이 백업 파일 복원 시간만큼 절감된다.
현재의 Resetlogs TSN 이전으로도 회귀시킬 수 있다. 이 특징을 사용하면 사이트의 운영 장비가 아닌 별도의 개발 장비에서 Resetlogs 부팅으로 특정 시나리오 테스트 후 데이터베이스를 재생성하지 않고 빠르게 기존 상태로 원복할 수 있다.
Tibero Standby Cluster 사용 중 switchover/failover를 발생할 때 기존 Primary Database를 재구축하지 않고 빠르게 stanby로 전환시킬 수 있다.
플래시백 데이터베이스는 현재 존재하는 파일을 블록 단위로 과거로 돌리는 작업이기 때문에 다음과 같은 사항들이 고려되어야 한다.
지워지지 않고 실제 존재하는 정상적인 데이터 파일에 대해서만 플래시백 가능하다. 손상된 데이터 파일을 복구하는 것은 불가하다.
플래시백하는 시점 이후로 추가된 파일은 자동으로 데이터베이스에서 삭제된다. 물리적 파일은 삭제하지 않기 때문에 직접 관리해줘야한다.
Drop된 데이터 파일을 Drop되기 전으로 플래시백하려면, 해당 데이터 파일의 백업 파일이 존재해야만 한다. 플래시백 수행 후 백업 파일을 복원하라는 가이드가 화면에 안내된다.
플래시백하는 시점 기준으로 테이블 스페이스는 rename되지만, 데이터 파일은 보존된다.
Offline된 테이블 스페이스 및 데이터 파일은 플래시백 대상에서 제외된다. 추후 drop해야 한다.
크기가 Extend된 데이터 파일은 다시 줄어들지 않는다.
Shrink된 데이터 파일은 플래시백 불가하다. 단, 해당 데이터 파일을 offline시키면 이를 제외한 나머지 데이터베이스에 대해서는 플래시백 가능하다. 이후 해당 파일에 대해서는 직접 백업 파일을 복원하여 불완전 복구해야한다.
컨트롤 파일을 재생성했다면 이전까지 축적한 플래시백 로그 정보는 사라진다. 플래시백 로깅을 다시 활성화해야 하며, Flashback Marker도 처음부터 다시 생성된다. 즉, 컨트롤 파일 재생성 이전으로는 플래시백 데이터베이스 불가하다. 컨트롤 파일 재생성 이전에 생성된 플래시백 로그 파일들은 백업 데이터 파일과 컨트롤 파일이 있지 않는 이상 사용할 수 없다.
백업 데이터 파일과 컨트롤 파일로 Media Recovery 후에도 기존 플래시백 로그 파일을 사용하고자 한다면, 완전 복구를 통해 Resetlogs 부팅은 하지 않아야 하며, Flashback Marker 이후의 플래시백 로그 파일들의 존재가 보장되어야 한다.
일반적으로 백업 데이터 파일과 컨트롤 파일을 사용하여 데이터베이스를 복구할 때 Flashback Marker를 초기화여 플래시백 로깅을 새롭게 시작하는 것이 안전한다. 추가적으로 플래시백 로깅을 활성화한 채로 Media Recovery를 수행할 때 Redo 로그를 기반으로 플래시백 로그도 복구하기 때문에 복구 성능이 매우 저하될 수 있다. 따라서 플래시백 로깅을 비활성화하는 것을 추천하는데, 비활성화 할 경우 플래시백 로그 파일 정보들은 모두 초기화된다.
NOLOGGING 모드는 권장하지 않는다. NOLOGGING 모드로 데이터베이스를 사용하면 플래시백은 가능하지만 NOLOGGING 모드를 사용한 기간 동안의 플래시백 로그가 없기 때문에 해당 내용들은 플래시백이 불가하여 정합성이 깨진 미래의 데이터베이스로 남아있을 뿐이다.
데이터베이스를 정상 종료해야만 MOUNT 모드에서 플래시백 데이터베이스 기능이 실행 가능하다. 정합성이 보장된 상태에서 플래시백해야 하기 때문이다.
본 절에서는 다음의 시나리오들을 통해서 플래시백 데이터베이스를 위한 플래시백 로그 파일 생성, 로깅 활성화, 그리고 실제 플래시백 데이터베이스 수행을 설명한다. 이들은 모두 MOUNT 상태에서만 수행 가능하다.
일반 로그 파일 구조, 구성과 동일하기에 이를 관리하는 원리도 같다. 단, 현재 플래시백 로그 파일 다중화 기능은 지원하지 않기 때문에 플래시백 로그 멤버는 그룹당 하나만 가능하다. 플래시백 로그 파일에 대해서는 일반 로그 파일인 “3.3. 로그 파일”을 참고한다.
플래시백 로그 파일을 추가한 후에는 해당 스레드와 플래시백 로깅을 활성화해야 운영 중 플래시백 로깅이 동작한다. 플래시백 로깅을 활성화시키기 위해서는 초기화 파라미터인 FLASHBACK_LOG_BUFFER가 세팅되어 있어야한다.
FLASHBACK_LOG_BUFFER 값은 일반적으로 LOG_BUFFER 값의 2배가 권장된다. 자세한 값은 실제 사이트의 운영 방식에 맞게 튜닝이 필요하다.
[예 11.26] 플래시백 로그 파일 생성과 로깅 활성화 시나리오
ALTER DATABASE ADD FLASHBACK LOGFILE THREAD 0 GROUP 1 '/usr/tibero/log/fblog001.fb' SIZE 512M; ALTER DATABASE ADD FLASHBACK LOGFILE THREAD 0 GROUP 2 '/usr/tibero/log/fblog002.fb' SIZE 512M; ALTER DATABASE ADD FLASHBACK LOGFILE THREAD 0 GROUP 3 '/usr/tibero/log/fblog003.fb' SIZE 512M; ALTER DATABASE ENABLE PUBLIC FLASHBACK THREAD 0; ALTER DATABASE FLASHBACK LOGGING ON;
현재 TSN 값이 155670인 데이터베이스를 가까운 과거인 150000으로 플래시백하려면 데이터베이스를 정상 종료 후 MOUNT 모드에서 다음을 구문을 수행한 후 완료 여부를 확인한다.
현재 TSN 값이 155670인 데이터베이스를 가까운 과거인 150000으로 플래시백 수행 도중 다음과 같은 에러가 발생할 때 Drop된 파일을 되살려야 한다. 에러와 함께 안내되는 절차대로 수행하면 데이터베이스가 원하던 시점으로 온전히 플래시백된다.
[예 11.28] 플래시백 데이터베이스 실행 중 MISSING 파일 생성 시나리오
SQL> ALTER DATABASE FLASHBACK TO TSN 150000; TBR-24127: Database flashed back to the target TSN %1$u but not completed, because CF-DD correction is required due to the originally existed at the target TSN or newly added datafiles during roll-forward.
1) Find MISSING datafiles from v$datafile. 2) Restore the corresponding backup datafiles. 3) If they were newly added after the TSN %lu, create the physical files with the datafile id each. : SQL> ALTER DATABASE CREATE DATAFILE <file_id>; 4) Rename(OS cmd) the corresponding files at DB_CREATE_FILE_DEST to their original names." 5) Rename(SQL) them with each of the names at step 2 and 4." : SQL> ALTER DATABASE RENAME FILE 'current_file_path' to 'renamed_file_path';" 6) Request flashback database query again as followed. : SQL> ALTER DATABASE FLASHBACK TO TSN 150000 CONTINUE;