10. 백업 및 복구#

디스크 데이터 파일 손상 또는 유실 등과 같은 예기치 않은 상황으로 인해 Altibase에 저장된 데이터가 손실될 경우를 대비하여 Altibase에서 제공하는 기능인 백업 및 복구에 대하여 설명한다.

데이터베이스 백업#

이 절에서는 데이터베이스의 아카이브로그 모드 여부에 따라 메모리 및 디스크 테이블스페이스에 대하여 지원되는 백업 방법과 정책에 대하여 설명한다.

백업 정책#

Altibase가 지원하는 백업을 분류하면 다음과 같다.

논리적 백업#

유틸리티(Utility) 백업

물리적 백업#

오프라인(Offline) 백업
온라인(Online) 백업

논리적 백업은 iLoader등의 유틸리티를 사용해서 데이터베이스 객체의 논리적인 복사본을 생성하여 텍스트 파일로 저장하는 것을 말한다. 논리적 백업을 사용해서는 오류가 발생한 시점까지 복구할 수 없을 수도 있다.

물리적 백업은 데이터베이스를 구성하는 데이터 파일들과 로그앵커 파일을 별도의 디스크나 테이프로 복사하는 것을 말한다. 물리적 백업은 데이터 파일의 스냅샷(snapshot)을 복사하는 동안의 서비스 중단 여부에 따라 온라인 백업과 오프라인 백업으로 구분된다.

오프라인 백업은 데이터베이스 서버를 정상 종료한 후에 모든 테이블스페이스 파일, 로그앵커 파일과 로그 파일들을 복사하는 것을 말한다.

온라인 백업은 서비스 중단 없이 데이터베이스의 데이터 파일들과 로그앵커 파일 등을 복사하는 것을 말한다. 데이터 파일들의 복사 과정에서 커밋(commit)되지 않은 데이터들이 백업될 수도 있다. 따라서 복구 시에 이들 커밋되지 않은 트랜잭션들을 철회(undo) 하기 위해서는 로그 파일들이 필요하다. 따라서, 아카이브 로그 파일들이 생성되는 아카이브 로그 모드로 운영 될 때만 온라인 백업이 가능하다.

온라인 백업 대상 및 방법#

온라인 백업 수행중에도 데이터베이스 서비스는 가능하지만, 서비스가 적은 시간에 백업을 수행하는 편이 좋다. 만약 서비스가 많은 시간에 백업을 수행한다면 과도한 로그가 발생할 수 있다.

온라인 백업으로는 전체 데이터베이스를 백업 하거나, 특정 테이블스페이스 또는 로그앵커를 백업 할 수 있다.

다음의 구문이 각 경우에 사용된다.

전체 데이터베이스 백업#

iSQL> ALTER DATABASE BACKUP DATABASE TO '/backup_dir';

테이블스페이스 단위 백업#

방법 1#

iSQL> ALTER DATABASE BACKUP TABLESPACE SYS_TBS_DISK_DATA TO '/backup_dir';

방법 2#

① BEGIN 백업 수행

iSQL> ALTER TABLESPACE SYS_TBS_DISK_DATA BEGIN BACKUP;

② 데이터 파일을 백업 경로로 복사

$ cp system001.dbf /backup_dir

③ END 백업 수행

iSQL> ALTER TABLESPACE SYS_TBS_DISK_DATA END BACKUP;

시스템 카탈로그 데이터를 포함하는 메모리 테이블스페이스인 SYS_TBS_MEM_DIC는 테이블스페이스 백업 또는 전체 데이터베이스 백업 기능으로 백업이 가능하다.

다음의 표는 Altibase의 다양한 백업 모드를 설명한다.

[표 10‑1] 백업 종류에 따른 방법

백업 종류	백업 방법	백업 대상	복구 방법	온라인 백업 가능 여부
iLoader 유틸리티를 이용한 백업	iLoader 유틸리티의 out 옵션 수행	사용자가 명시한 테이블	iLoader 유틸리티의 in 옵션 이용	O
전체 데이터베이스 온라인 백업	SQL문 수행 ALTER DATABASE BACKUP DATBASE TO 'backup_dir';	- 전체 테이블스페이스의 데이터 파일 - 로그 앵커파일	① 유닉스 명령어 cp 수행 ② ALTER DATABASE RECOVER DATABASE;	O
특정 테이블스페이스의 온라인 백업	방법1: SQL 문 수행 ALTER DATABASE BACKUP TABLESPACE tablespace_name TO 'backup_dir'; 방법2: ① SQL 문 수행: BEGIN 백업 ALTER TABLESPACE tablespace_name BEGIN BACKUP; ② 유닉스 명령어 cp 수행 cp datafiles backup_dir/ ③ SQL 문 수행: END 백업 ALTER TABLESPACE tablespace_name END BACKUP;	테이블스페이스의 모든 데이터 파일	① 유닉스 명령어 cp 수행 ② ALTER DATABASE RECOVER DATABASE;	O
오프라인 백업	① 데이터베이스 종료 ② 유닉스 명령어 cp 수행	전체 데이터베이스	유닉스 명령어 cp 수행	X
백업시간 비교	iLoader < 온라인 백업 < 오프라인 백업

범위에 따른 백업 분류#

데이터베이스 단위 백업 (Database-Level Backup)#

데이터베이스의 모든 데이터 파일을 백업한다.
백업과 관련된 모든 로그 파일의 아카이브를 보장한다.

테이블스페이스 단위 백업 (Tablespace-Level Backup)#

특정 메모리 또는 디스크 테이블스페이스의 모든 데이터 파일을 백업한다.
언두 테이블스페이스의 경우 TRANSACTION_SEGMENT_COUNT 프로퍼티의 설정값이 900을 초과할 경우 세그먼트 헤더 정보 파일(txSegEntry.hdr)도 함께 백업한다.
백업과 관련된 로그 파일의 아카이브를 보장하지 않으므로 이들은 DCL 구문을 사용해서 별도로 아카이브될 필요가 있다.

방식에 따른 백업 분류#

데이터베이스 시스템에 의한 백업 (Database-Driven Backup)#

Altibase 서버에 의해 파일 복사가 수행된다.
한번의 DCL 구문으로 전체 DB 혹은 테이블스페이스 순서대로 백업된다.
데이터베이스 단위 백업, 테이블스페이스 단위 백업 모두 지원된다.

DBA에 의한 Backup (DBA-Driven Backup)#

DBA에 의해 파일 복사가 수행된다.
여러 테이블스페이스에 대한 병렬 백업을 수행할 수 있으므로 3rd-Party 백업 솔루션과의 연동이 가능하다.
테이블스페이스 단위 백업만 지원된다.
언두 테이블스페이스의 경우 TRANSACTION_SEGMENT_COUNT 프로퍼티의 설정값이 900을 초과할 경우 세그먼트 헤더 정보 파일(txSegEntry.hdr)도 함께 백업해야 한다.

데이터베이스 모드#

데이터에 대한 모든 변경이 기록된 온라인 로그 파일들이 관리되는 방법에 따라 데이터베이스는 아카이브 로그(archivelog) 모드 또는 노-아카이브 로그(noarchivelog) 모드로 운영된다.

아카이브 로그 모드에서는 한 로그 파일이 다 차서 새 로그 파일로 교체되면 이전 로그 파일은 아카이브 디렉터리로 복사된다. 아카이브 로그 디렉터리는 $ALTIBASE_HOME/conf/altibase.properties 파일에 ARCHIVE_DIR 프러퍼티로 지정된다.

노-아카이브 로그 모드에서는 이 로그 파일들이 체크포인트 시에 지워진다.

각 데이터베이스 모드의 장단점을 비교하면 [표 10-2]와 같다.

[표 10‑2] 데이터베이스 모드에 따른 장단점

데이터베이스 모드	장점	단점
아카이브 로그(archivelog mode)	- 매체 복구가 가능하다. - 데이터 파일의 유실이나 손실시에도 데이터베이스는 현재 시점까지 복구가 가능하다.	- 아카이브 로그 파일을 저장하기 위한 디스크 공간이 필요하다. - DBA가 아카이브 로그를 다른 저장 장치로 받아내거나, 로그 파일 정리 등을 해야 함으로 관리의 부담이 크다. - 아카이브 로그를 위한 디스크 공간이 부족하면 장애가 발생한다.
노아카이브 로그(no-archivelog mode)	- DBA가 아카이브 로그 파일을 관리할 필요가 없다.	- 데이터 파일이 손상되어도, DBA는 오프라인 백업을 이용한 복구만 할 수 있다. - 백업 받은 시점과 데이터 파일의 손상이 발생한 시점 사이의 데이터 변경은 복구되지 않는다.

데이터베이스 모드 설정 및 변경#

데이터베이스 모드는 CREATE DATABASE 구문을 사용해서 데이터베이스가 생성될 때 결정되며, control 구동 단계에서 변경될 수 있다.

다음 예는 아카이브 로그 모드로 데이터베이스를 생성하는 예이다.

CREATE DATABASE mydb INITSIZE=100M ARCHIVELOG;

다음 예는 control 구동 단계에서 데이터베이스 모드를 아카이브 로그 모드로 변경하는 예이다.

$ isql -silent -u sys -p manager -sysdba
iSQL(sysdba)> STARTUP CONTROL;
iSQL(sysdba)> ALTER DATABASE ARCHIVELOG;

데이터베이스 모드에 따른 온라인 백업 및 매체 복구#

[표 10‑3] 데이터베이스 모드에 따른 백업 및 복구 방법

데이터베이스 모드	백업 방법	매체 복구 방법
노아카이브 로그	오프라인 백업	전체 데이터베이스 복구
아카이브 로그	온라인 백업 오프라인 백업	완전 복구 - 전체 데이터베이스 복구 불완전 복구 - Cancel 기반 복구 - Time 기반 복구
상관없음	iLoader 유틸리티를 이용한 백업	iLoader 유틸리티를 이용한 복구

테이블스페이스 상태에 따른 온라인 백업 및 매체 복구#

[표 10‑4] 테이블스페이스 상태에 따른 온라인 백업과 매체 복구

테이블스페이스 상태	온라인 백업	매체 복구
온라인(ONLINE)	가능	가능
오프라인(OFFLINE)	가능	가능
디스카드(DISCARDED)	불가능	불가능
삭제(DROPPED)	불가능	불가능
백업(BACKUP)	불가능	의미 없음

백업 시 주의사항#

온라인 백업과 체크포인트는 동시에 수행될 수 없다.

체크포인트 중에 메모리 상의 데이터베이스 내용이 디스크에 반영되고, 온라인 백업은 백업하는 바로 그 시점까지의 데이터만 백업을 보장한다. 따라서 체크포인트와 온라인 백업은 서로 배타적으로 수행되고, 동시에 수행될 수 없다.

체크포인트를 수행 중에 온라인 백업 요구가 발생하면 체크포인트가 완료된 후에 온라인 백업이 시작된다. 마찬가지로 온라인 백업 진행 중에 체크포인트 요구가 들어와도 온라인 백업이 완료된 후 체크포인트가 시작된다.

Altibase는 하이브리드 데이터베이스 특성상 데이터베이스 백업 시에 메모리 테이블스페이스, 디스크 테이블스페이스 순으로 백업을 진행한다. 메모리 테이블스페이스 백업 중에는 체크포인트가 수행될 수 없지만, 메모리 테이블스페이스의 백업이 완료되고 디스크 테이블스페이스 백업 중에는, 메모리 테이블스페이스에 대한 체크 포인트는 수행되고 디스크 테이블스페이스에 대한 체크 포인트는 수행되지 않는다.

데이터베이스 복구#

데이터베이스 시스템에서는 언제든지 시스템 또는 하드웨어 장애가 발생할 가능성이 있다. 데이터베이스에 영향을 미치는 장애가 발생하면 데이터베이스 복원을 위해서 복구가 수행되어야 한다. 이런 장애 후의 목표는 모든 커밋된 트랜잭션의 결과들을 복구된 데이터베이스에 유지시키고 가능한 빨리 데이터베이스의 정상 운영이 가능하도록 하는데 있다.

복구 정책#

Altibase는 다음의 복구 유형을 지원한다.

논리적 백업본을 이용한 복구
재시작시 자동 복구 (Restart Recovery)
매체 복구 (Media Recovery)

논리적 백업본을 이용한 복구는 iLoader 유틸리티를 통하여 백업된 텍스트 파일을 iLoader 유틸리티를 통해 복구하는 방식이다.

재시작시 자동 복구는 Altibase 프로세스가 시스템 crash 또는 소프트웨어 오류로 비정상 종료된 경우, 재시작시 구동 단계에서 자동으로 수행되는 복구이다.

매체 복구는 특정 데이터 파일이 유실되거나 손상된 경우에, 과거에 백업한 데이터 파일, 로그 앵커 파일, 아카이브 로그 파일을 이용하여 현재 시점의 데이터 파일 또는 과거 특정 시점의 데이터 파일로 복구하는 방식이다. 매체 오류 상황과 복구 절차에 따라 완전 복구와 불완전 복구를 선택할 수 있다.

데이터 파일의 매체 복구가 필요한가에 대한 판단은 로그앵커 파일상의 해당 데이터 파일의 버전과 현재 데이터 파일의 버전이 일치하는지 여부에 따라 결정된다.

Altibase에서는 매체 복구를 control 구동 단계에서만 할 수 있다. 즉 Altibase는 오프라인 매체 복구만 지원한다.

예제#

다음은 매체 복구의 예제이다. TEST 테이블스페이스의 데이터 파일 'user1.dbf' 파일이 유실되었다. 이 예제는 이틀 전에 온라인 백업받은 'user1.dbf'을 이용하여 유실된 데이터 파일을 현재 시점으로 복원한다.

백업 파일을 데이터 파일 경로로 복사

cp /backup_dir/user1.dbf  $ALTIBASE_HOME/dbs

컨트롤 단계로 구동

iSQL(sysdba)> STARTUP CONTROL;

매체 복구를 수행

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE;

TEST 테이블스페이스의 데이터 파일 'user1.dbf'가 매체 복구되었다.

서비스 단계로 구동

iSQL(sysdba)> STARTUP SERVICE;

매체 복구가 완료되었기 때문에 서비스 단계로 전이한다.

완전 복구와 불완전 복구#

Altibase 매체 복구 정책은 완전 복구와 불완전 복구를 모두 지원한다.

완전 복구(Complete recovery)는 온라인 로그와 아카이브 로그의 유실이 없는 경우에 현재 시점까지 데이터 파일을 복원하는 것을 의미한다.

불완전 복구(Incomplete recovery)는 아카이브 로그 파일 또는 온라인 로그 파일이 유실된 경우에 로그 파일이 유실되기 바로 직전의 시점으로 데이터베이스를 복구하거나, 데이터베이스를 특정 시각으로 복원하기 위하여 특정 과거 시점으로 전체 데이터베이스를 되돌리는 경우를 말한다.

완전 복구의 예는 다음과 같다.

ALTER DATABASE RECOVER DATABASE;

불완전 복구는 다음 두 가지 경우로 나눌 수 있다.

과거의 특정 시점으로 전체 데이터베이스를 되돌리는 경우:#

2007년 9월 10일에 생성된 전체 데이터베이스 백업 파일을 복사한 후 이를 이용하여 복구를 수행한다.

ALTER DATABASE RECOVER DATABASE UNTIL TIME '2007-09-10:17:55:00';

특정 온라인 로그 파일이 손상되어 현재 시점까지 데이터베이스를 복원할 수 없는 경우:#

다음의 구문을 이용하여 온라인 로그 파일이 손상되기 바로 직전 시점으로 데이터베이스를 복원한다.

ALTER DATABASE RECOVER DATABASE UNTIL CANCEL;

control 구동 단계에서 불완전 복구를 수행한 경우에 meta 구동 단계로 넘어가기 위해서 반드시 다음 구문을 사용해야 한다.

ALTER DATABASE db_name META RESETLOGS;

위 구문을 수행하는 이유는 데이터베이스가 특정 과거 시점으로 복원되어, 재 시작 시 자동 복구(Restart Recover)가 수행되지 않도록 할 필요가 있기 때문이다. 이를 위하여 RESETLOGS 옵션으로 온라인 로그를 초기화(resetlogs)하는 것이다. 데이터베이스가 resetlogs를 하면서 meta 구동 단계로 전이 되었다면, 오프라인이나 온라인 백업으로 전체 데이터베이스 백업을 반드시 해야 한다.

그 이유는 다음과 같다: resetlogs를 하면서 meta 구동 단계로 전이하고 나서 이틀 후에 매체에 또 다시 에러가 발생한다면, 로그를 리셋하기 이전까지만 데이터 복구가 가능하기 때문이다. 즉, 로그를 리셋한 이후부터 이틀간의 데이터는 유실될 것이다.

매체 복구 주의사항#

매체 복구 알고리즘 때문에 가능하면 현재 로그 앵커 파일들을 이용하여 매체 복구를 하여야 한다.#

복구 수행시, 백업된 데이터 파일들만 복사하여 복원해야 한다. 특별한 경우가 아니라면 로그앵커 파일들은 백업 본을 사용하여 복구하면 안 된다.

만약 사용자가 실수로 DROP TABLESPACE 구문을 이용하여 테이블스페이스를 삭제한 경우에는, 현재의 로그앵커 파일에는 삭제된 테이블스페이스 정보가 없기 때문에 백업된 로그앵커를 사용할 수 밖에 없다.

메모리 테이블스페이스의 데이터 파일 복구 시 안정적인(stable) 메모리 데이터 파일을 이용해야 한다.#

Altibase는 메모리 테이블스페이스에 대하여 핑퐁 체크포인트 (ping-pong checkpoint) 기법을 사용하기 때문에, 디스크 상에서 각 메모리 테이블스페이스에 대하여 2개의 데이터 파일을 유지한다. 동일한 이미지를 기록한 1묶음(pair)의 데이터 파일은 MEM_DB_DIR 프로퍼티에 설정한 위치에 저장된다. 2개의 데이터 파일이 모두 존재해야만 Altibase가 정상적으로 운용된다. 어느 한 시점에서는 메모리 테이블스페이스는 이 묶음 중 1개의 데이터 파일만 사용한다.

백업 수행 시간을 줄이려면 메모리 테이블스페이스의 가장 최근 체크포인터가 수행된 1개의 데이터 파일만 백업한다.

백업받은 메모리 테이블스페이스의 데이터 파일이 다음과 같다면:

SYS_TBS_MEM_DIC-1-0 
SYS_TBS_MEM_DIC-1-1 
SYS_TBS_MEM_DIC-1-2

메모리 테이블스페이스를 위한 데이터 파일의 복사는 다음과 같이 되어야 한다.

$ cp SYS_TBS_MEM_DIC-1-0  $ALTIBASE_HOME/dbs;
$ cp SYS_TBS_MEM_DIC-1-1  $ALTIBASE_HOME/dbs;
$ cp SYS_TBS_MEM_DIC-1-2  $ALTIBASE_HOME/dbs;

복구 완료 시점에 자동으로 안정적인(stable) 메모리 데이터 파일을 복사해서 불안정한(unstable) 메모리 데이터 파일을 생성한다.

테이블스페이스의 추가, 삭제 또는 이름 변경 등이 이루어지면, 딕셔너리 테이블스페이스(SYS_TBS_MEM_DIC)의 백업이나 전체 데이터베이스 백업이 필요하다.#

ALTER DATABASE BACKUP TABLESPACE SYS_TBS_MEM_DIC TO '/backup_dir';

로그앵커 파일은 데이터베이스 내 테이블스페이스 정보를 포함하고 있으므로, 이는 테이블스페이스 구조가 변경될 때마다 딕셔너리 테이블스페이스와 함께 백업되어야 한다.#

iSQL(sysdba)> ALTER DATABASE BACKUP LOGANCHOR TO 'anchor_path';

이중화를 진행하던 Altibase의 백업된 데이터베이스로 복구할 경우 아래의 문제가 발생할 수 있다.#

백업된 데이터베이스가 동일하지 않은 시스템에서 복구되는 경우 네트워크 주소가 다르기 때문에 Altibase 복구 후 이중화 사용에 문제가 발생할 수 있다.

동일한 시스템으로 복구된 경우라도 백업 시점의 메타 정보를 기준으로 이중화를 재전송할 수 있으며, 이 경우 일부 데이터가 백업 시점의 데이터로 변경될 수 있다.

따라서 이중화가 자동으로 시작되지 않도록 (1) REPLICATION_SENDER_AUTO_START 프로퍼티의 값을 0으로 변경 후 복구를 진행해야 하며, (2) 복구가 완료되면 이중화 객체를 재생성하거나 이중화를 RESET한다.

백업 및 복구 사례들#

iLoader 유틸리티를 이용한 테이블 백업 및 복구#

임의의 테이블에만 문제가 발생할 것을 대비하거나, 특정 이유로 해당 테이블만 백업을 받으려고 하는 경우 iLoader 유틸리티를 사용할 수 있다.

백업 전#

백업하기 전에 반드시 백업하고자 하는 테이블의 스키마에 관한 정보 파일(FORM file)을 생성해야 한다. FORM 파일은 테이블에 관한 기본 정보(칼럼 이름, 데이터 타입)를 가지고 있다.

예제: 테이블 t1의 form 파일 생성

iLoader> formout –T t1 –f t1.fmt

t1.fmt라는 파일 이름으로 생성됨

백업#

iLoader 유틸리티의 옵션 중 out을 사용한다. 사용자가 명시한 이름으로 테이블에 대한 백업 파일이 생성된다.

예제: 테이블 t1의 백업

iLoader> out –d t1.dat –f t1.fmt

이용할 form 파일은 t1.fmt 생성할 백업 파일은 t1.dat

복원(restore)#

iLoader 유틸리티의 옵션 중 in을 사용한다. 복구 시 테이블에 레코드가 존재하는 경우 그 레코드들을 유지하거나 덮어쓰게 할 수 있으며, 사용자가 명시하지 않는 경우 존재하는 레코드들의 내용은 유지된다.

예제: 테이블 t1의 복원

iLoader> in –d t1.dat –f t1.fmt

오프라인 백업 및 복구#

오프라인 백업 및 복구는 주로 노아카이브 로그 모드로 데이터베이스를 운영하는 경우에 사용하는 방법이다.

오프라인 백업 주의사항#

백업 전 Altibase와 관련된 모든 서비스를 중지한다.

데이터베이스 운영 중에 오프라인 백업이 수행되면 백업 중에 로그 파일의 내용이 변경될 수 있어 백업이 정확하게 수행되지 않을 수 있다. 그러므로 반드시 Altibase 서버를 중지한 후에 오프라인 백업을 수행하여야 한다.

백업 방법#

모든 테이블스페이스의 데이터 파일들, 로그 파일, 및 로그 앵커 파일 모두를 운영체제의 복사 명령어 (UNIX의 경우 cp)를 이용하여 백업한다. Altibase에서는 메모리 데이터 파일 뿐만 아니라 디스크 관련 테이블스페이스의 데이터 파일들과 로그 앵커파일이 백업되어야 한다.

메모리 테이블스페이스 데이터 파일 저장 위치는 Altibase 프로퍼티 파일인 $ALTIBASE_HOME/conf/altibase.properties 파일 내에 MEM_DB_DIR으로 설정된다. 메모리 테이블스페이스의 데이터 파일을 백업하려면 MEM_DB_DIR 디렉터리를 모두 복사해야 한다.

로그 앵커 파일의 위치는 $ALTIBASE_HOME/conf/altibase.properties 파일 내에 LOGANCHOR_DIR 프로퍼티로 설정된다. 로그 앵커 파일을 백업하려면 LOGANCHOR_DIR 디렉터리의 파일들을 복사해야 한다. 그리고 데이터 딕셔너리를 참조하여 디스크 테이블스페이스의 데이터 파일들을 복사해야 한다.

예제#

$ vi $ALTIBASE_HOME/conf/altibase.properties 
MEM_DB_DIR      = $ALTIBASE_HOME/dbs0
MEM_DB_DIR      = $ALTIBASE_HOME/dbs1
LOGANCHOR_DIR   = $ALTIBASE_HOME/logs

백업해야 하는 디스크 테이블스페이스에는 시스템 테이블스페이스,언두 테이블스페이스와 임시 테이블스페이스만 있다.

백업 파일이 저장될 위치가 /home/backup라면 아래와 같이 복사한다.

$ cp $ALTIBASE_HOME/dbs0    /home/backup 
$ cp $ALTIBASE_HOME/dbs1    /home/backup
$ cp $ALTIBASE_HOME/logs    /home/backup
$ cp $ALTIBASE_HOME/dbs/system*.dbf /home/backup
$ cp $ALTIBASE_HOME/dbs/undo.dbf    /home/backup
$ cp $ALTIBASE_HOME/dbs/temp.dbf    /home/backup

복구 방법#

Altibase 프로퍼티 설정 파일은 백업 수행 당시에 사용되었던 프로퍼티 파일을 그대로 이용해야 한다. 백업 시 받았던 파일들을 복사 명령어 cp를 이용하여 복원하라. 이들 파일에 접근하려면 충분한 권한이 있어야 한다.

예제#

아래의 예제에서는 위에서 백업된 데이터베이스가 복원된다.

$ cp /home/backup/dbs0  ALTIBASE_HOME/dbs0
$ cp /home/backup/dbs1  $ALTIBASE_HOME/dbs1
$ cp /home/backup/logs  $ALTIBASE_HOME/logs
$ cp /home/backup/system*.dbf   $ALTIBASE_HOME/dbs
$ cp /home/backup/undo.dbf  $ALTIBASE_HOME/dbs
$ cp /home/backup/temp.dbf  $ALTIBASE_HOME/dbs

데이터베이스 시스템에 의한 온라인 백업#

데이터베이스 단위 온라인 백업#

전체 데이터베이스가 /backup_dir 디렉터리에 온라인 백업된다.

데이터베이스 단위 온라인 백업

ALTER DATABASE BACKUP DATABASE TO '/backup_dir';

백업된 파일들

$ ls /backup_dir
SYS_TBS_MEM_DIC-0-0   
SYS_TBS_MEM_DATA-0-0
system001.dbf 
system002.dbf 
undo001.dbf
loganchor0 
loganchor2 
loganchor1

테이블스페이스 단위 온라인 백업#

SYS_TBS_MEM_DIC 데이터 파일 중에서 안정(stable)된 버전이 /backup_dir 디렉터리에 온라인 백업된다.

테이블스페이스 단위 온라인 백업

ALTER DATABASE BACKUP TABLESPACE SYS_TBS_MEM_DIC TO '/backup_dir';

백업된 파일

$ ls /backup_dir
SYS_TBS_MEM_DIC-0-0

로그앵커 온라인 백업#

모든 로그앵커 파일이 /backup_dir 디렉터리에 온라인 백업된다.

로그앵커 온라인 백업

ALTER DATABASE BACKUP LOGANCHOR TO '/backup_dir';

백업된 파일들

$ ls /backup_dir
loganchor0 loganchor1 loganchor2

DBA에 의한 온라인 백업#

테이블스페이스 단위 온라인 백업#

/backup_dir에 메모리 테이블스페이스 USER_MEMORY_TBS와 디스크 테이블스페이스 USER_DISK_TBS의 데이터 파일들을 온라인 백업 한다.

메모리 테이블스페이스의 데이터 파일은 안정적인(stable) 데이터 파일을 확인 후 온라인 백업한다.

메모리 테이블스페이스 USER_MEMORY_TBS에 BEGIN 백업 수행#

iSQL(sysdba)> ALTER TABLESPACE user_memory_tbs BEGIN BACKUP;

안정적인 데이터 파일 확인#

iSQL(sysdba)> SELECT * FROM V$STABLE_MEM_DATAFILES;
MEM_DATA_FILE
------------------------------
/altibase_home/dbs/USER_MEM_TBS-0-0

안정적인 데이터 파일 백업#

$ cp $ALTIBASE_HOME/dbs/USER_MEMORY_TBS-0-0  /backup_dir/

메모리 테이블스페이스 USER_MEMORY_TBS에 END 백업 수행#

iSQL(sysdba)> ALTER TABLESPACE user_memory_tbs END BACKUP;

디스크 테이블스페이스 USER_DISK_TBS에 BEGIN 백업 수행#

iSQL(sysdba)> ALTER TABLESPACE user_memory_tbs BEGIN BACKUP;

디스크 테이블스페이스의 데이터 파일 백업#

$ cp $ALTIBASE_HOME/dbs/USER_DISK_TBS.dbf /backup_dir/

디스크 테이블스페이스 USER_DISK_TBS에 END 백업 수행#

iSQL(sysdba)> ALTER TABLESPACE user_memory_tbs END BACKUP;

백업된 파일 확인#

$ ls /backup_dir
USER_MEMORY_TBS-0-0 USER_DISK_TBS.dbf

SNAPSHOT 백업#

스냅샷(SNAPHOT) 백업은 데이터베이스의 특정 시점을 SCN으로 스냅샷을 지정한 후, iLoader 유틸리티를 사용하여 데이터를 백업할 수 있다.스냅샷 백업은 일반적으로 외래 키 또는 트리거가 있는 테이블, 서비스가 일어나는 시점에 iLoader 유틸리티를 사용하여 데이터를 백업할 경우에 유용하다. 스냅샷 백업은 데이터의 일관성을 유지할 수 있기 때문이다.

스냅샷 지정 및 해제는 SYSDBA 권한을 가진 DBA만 가능하다.

스냅샷 설정#

iSQL(sysdba)> ALTER DATABASE BEGIN SNAPSHOT;

스냅샷을 설정하면, V$SNAPSHOT 성능 뷰에서 설정된 SCN의 값을 확인할 수 있다.

스냅샷 해제#

iSQL(sysdba)> ALTER DATABASE END SNAPSHOT;

주의사항#

SNAPSHOT SCN을 지정하면, 해당 SCN 이후의 데이터는 삭제되지 않기 때문에 DML이 빈번하지 않은 경우에 사용해야 한다.
스냅샷 이후 데이터 증가로 메모리 또는 디스크 언두 테이블스페이스의 공간이 부족할 수 있다. 프로퍼티 SNAPSHOT_MEM_THRESHOLD, SNAPSHOT_DISK_UNDO_THRESHOLD에 설정된 임계치를 초과하면 스냅샷은 중단된다.
대량의 테이블 업데이트 또는 이중화를 진행중에 수신자(receiver)에서 데이터를 수신중에는 스냅샷의 기준 시점이 상이할 수 있다.
iLoader 유틸리티로 데이터를 export 중에는 SNAPSHOT을 지정할 수 없다.

온라인 백업 마무리#

DBA에 의한 직접 온라인 백업을 수행하였다면 마지막 절차는 백업과 관련된 로그 파일을 강제로 아카이브(archive) 하는 명령을 수행해야 하는 것이다. 이 명령은 현재 로그 파일을 다 쓰지 않았어도 닫고 다음 로그 파일에 로깅을 계속하도록 명령한다.

iSQL(sysdba)> ALTER SYSTEM SWITCH LOGFILE;

온라인 백업 완료 메시지가 altibase_sm.log에 남겨진다. 이 수동 백업의 예제에서는, logfile15341 로그파일이 아카이브 되었다는 메지지가 백업이 완료됨을 표시한다.

[2007/09/18 14:42:38] [Thread-6] [Level-9] 
Waiting logfile15341 to archive 


[2007/09/18 14:42:43] [Thread-6] [Level-9] 
Database-Level Backup Completed [SUCCESS]

매체 복구 사례 1: 백업하지 않은 디스크 테이블스페이스의 데이터 파일 유실#

아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 백업되지 않은 데이터 파일 $ALTIBASE_HOME/dbs/abc.dbf가 유실되었다.

메모리 테이블스페이스의 데이터 파일은 이와 같은 방법으로 복구될 수 없다.

복구 절차#

완전 복구에 필요한 아카이브 로그 파일 확인#

완전 복구에 필요한 첫 번째 아카이브 로그 파일을 확인한다.

iSQL(sysdba)> SELECT NAME, CREATE_LSN_LFGID, CREATE_LSN_FILENO FROM V$DATAFILES;
---------------------------------------------------------
…
/altibase_home/dbs/abc.dbf  0            18320

가장 최근 삭제된 로그 파일을 확인하기 위해서는 유틸리티 'dumpla'를 이용하여 loganchor의 내용을 확인한다.

$ dumpla loganchor0
[LOGANCHOR HEADER]
Binary DB Version                    [ 7.3.0 ]
Archivelog Mode                      [ Archivelog ]
Transaction Segment Entry Count      [ 256 ]
Begin Checkpoint LSN                 [ 20345, 469859 ]
End Checkpoint LSN                   [ 20345, 470300 ]
Disk Redo LSN                        [ 20345, 469859 ]
LSN for Recovery from Replication    [ NULL ]
Server Status                        [ SERVER SHUTDOWN ]
End LSN                              [ 20345,470341 ]
Media Recovery LSN                   [ 0, 469859 ]
ResetLog LSN                         [ 4294967295, 4294967295 ]
Last Created Logfile Num             [ 20350 ]
Delete Logfile(s) Range              [ 20333 ~ 20344 ]    # 가장 최근에 삭제된 로그 파일 정보
Update And Flush Count               [ 316 ]
New Tablespace ID                    [ 8 ]

완전 복구에 필요한 아카이브 로그 파일이 있는지 확인#

ARCHIVE_DIR 프로퍼티에 정의된 디렉터리에 logfile18320부터 logfile20344까지 존재하는지 확인한다. 만약 존재하지 않는다면, 아카이브 로그파일을 백업 저장 장치로부터 ARCHIVE_DIR 프로퍼티에 지정된 디렉터리로 복사한다.

logfile20345 이후의 로그 파일은 모두 LOG_DIR 프로퍼티에 지정된 디렉터리에 존재하는 온라인 로그 파일이다. 즉, logfile18320부터 logfile20345까지의 로그 파일들은 유실된 abc.dbf 를 완전 복구하기 위해 반드시 필요하다.

ARCHIVE_DIR과 LOG_DIR프로퍼티에 지정된 디렉터리에 존재하는 로그 파일의 중복으로 인해 발생되는 디스크 공간 낭비를 제거하기 위해서, Altibase가 직접 ARCHIVE_DIR프로퍼티에 지정된 디렉터리의 로그 파일을 읽는다.

컨트롤 단계로 구동#

iSQL(sysdba)> STARTUP CONTROL;

유실된 데이터 파일 생성#

CONTROL 구동 단계에서 다음 구문으로 유실된 abc.dbf 파일을 생성한다.

iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'abc.dbf';

완전 복구 수행#

CONTROL 구동 단계에서 다음 구문으로 완전 복구를 수행한다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE;

매체 복구 사례 2: 백업한 디스크 테이블스페이스의 데이터 파일 유실#

아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 3일 전에 디스크 테이블스페이스 USER_DISK_TBS의 데이터 파일들을 백업하였다.

오늘 오전에 USER_DISK_TBS 테이블스페이스의 데이터 파일을 모두 잃어 버렸다.

백업 절차#

3일 전에 다음과 같이 백업을 수행했다.

iSQL(sysdba)> ALTER DATABASE BACKUP TABLESPACE user_disk_tbs TO '/backup1';
iSQL(sysdba)> ALTER SYSTEM SWITCH LOGFILE;

백업 파일들

$ ls /backup1
USER_DISK_TBS01.dbf USER_DISK_TBS02.dbf USER_DISK_TBS03.dbf

복구 절차#

완전 복구에 필요한 아카이브 로그 파일을 확인 확인한 후, 아카이브 디렉터리로 해당 파일들을 복사한다.

완전 복구에 필요한 아카이브 로그 파일 확인#

필요한 아카이브 로그 파일을 확인하는 방법은 복구될 데이터 파일의 헤더에 있는 정보를 참조하는 것이다. 헤더 정보는 dumpddf 유틸리티를 이용하여 다음과 같이 확인해 볼 수 있다.

$ dumpddf -m -f USER_DISK_TBS01.dbf
[BEGIN DATABASE FILE HEADER]

Binary DB Version [ 5.4.1 ]
Redo LSN          [ 4, 2257550 ]      # 완전 복구에 필요한 아카이브 로그 파일은 logfile4
Create LSN        [ 0, 657403 ]

[END DATABASE FILE HEADER]

위 결과는 백업된 데이터 파일을 이용하여 데이터베이스를 복원하려면 아카이브 로그 파일 logfile4 이후 파일들을 필요로 함을 나타낸다.

아카이브 로그 파일 경로에 logfile4 이후 파일들이 있는지 확인한다.

데이터 파일의 백업본을 원래 위치로 복사#

backup_dir 디렉터리에 있는 USER_DISK_TBS 테이블스페이스의 데이터 파일들을 원래 경로 $ALTIBASE_HOME/dbs/ 디렉터리에 복사한다.

$ cp /backup_dir/*.dbf  $ALTIBASE_HOME/dbs;

컨트롤 단계로 구동#

iSQL(sysdba)> STARTUP CONTROL;

완전 복구 수행#

CONTROL 구동 단계에서 다음 구문으로 완전 복구를 수행한다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE;

매체 복구 사례 3: 디스크 테이블스페이스의 데이터 파일의 경로를 변경하여 복구#

아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 7일 전에 디스크 테이블스페이스 USER_DISK_TBS의 데이터 파일들을 백업하였다.

오늘 오후에 USER_DISK_TBS 테이블스페이스의 데이터 파일이 있는 /disk1 파일시스템이 깨졌으나, /disk2 파일시스템은 정상이다.

이 경우 /disk1 파티션이 깨졌으므로 정상 상태의 /disk2 파티션에 백업된 데이터 파일을 옮겨 매체 복구를 수행한다.

백업 절차#

7일 전에 같이 백업을 수행했다.

iSQL(sysdba)> ALTER DATABASE BACKUP TABLESPACE user_disk_tbs TO '/backup_dir';
iSQL(sysdba)> ALTER SYSTEM SWITCH LOGFILE;

백업 파일들

$ ls /backup_dir
USER_DISK_TBS01.dbf USER_DISK_TBS02.dbf

복구 절차#

완전 복구에 필요한 아카이브 로그 파일 확인#

완전 복구에 필요한 아카이브 로그 파일을 확인하고, 아카이브 디렉터리로 해당 파일들을 복사한다.

데이터 파일의 백업본을 다른 파일시스템으로 복사#

backup_dir 디렉터리에 있는 USER_DISK_TBS 테이블스페이스의 데이터 파일들을 /disk2 파일시스템으로 복사한다.

$ cp /backup_dir/*.dbf /disk2/dbs;

컨트롤 단계로 구동#

컨트롤 단계로 구동한다.

iSQL(sysdba)> STARTUP CONTROL;

데이터 파일 경로 변경#

CONTROL 구동 단계에서 USER_DISK_TBS 테이블스페이스의 데이터 파일 경로를 변경한다.

iSQL(sysdba)> ALTER DATABASE RENAME DATAFILE '/disk1/dbs/USER_DISK_TBS01.dbf' TO '/disk2/dbs/USER_DISK_TBS01.dbf';
iSQL(sysdba)> ALTER DATABASE RENAME DATAFILE '/disk1/dbs/USER_DISK_TBS02.dbf' TO '/disk2/dbs/USER_DISK_TBS02.dbf';

이 작업 수행을 위해서 ALTER TABLESPACE 구문을 사용할 수도 있다.

iSQL(sysdba)> ALTER TABLESPACE user_disk_tbs RENAME DATAFILE '/disk1/dbs/USER_DISK_TBS02.dbf' TO '/disk2/dbs/USER_DISK_TBS02.dbf';

데이터 파일 경로 변경 확인#

데이터 파일 경로가 정확히 변경되었는지 V$DATAFILES 성능 뷰를 확인한다.

iSQL(sysdba)> SELECT * FROM V$DATAFILES;

완전 복구 수행#

CONTROL 구동 단계에서 다음 구문으로 완전 복구를 수행한다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE;

매체 복구 사례 4: 테이블 삭제 후 불완전 복구 사례#

아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 사용자 실수로 summary 테이블을 DROP 하였다.

가장 최근의 전체 온라인 백업 완료 시각: 2007년 9월 18일 12시 00분
테이블이 DROP된 시각: 2007년 9월 18일 15시 00분
현재 시각: 2007년 9월 18일 18시 00분

summary 테이블을 복구하기 위해서는 현재 시각에서 3시간 30분 전인 2007년 9월 18일 14시 30분 정각으로 데이터베이스를 불완전 복구해야 한다.

백업 절차#

지난번 백업 시 다음과 같이 전체 데이터베이스 백업을 하였다.

iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO '/backup_dir';
iSQL(sysdba)> alter SYSTEM SWITCH LOGFILE;

복구 절차#

백업 데이터 파일을 원래 위치로 복사#

백업 받은 데이터 파일들을 원래 위치로 복사 한다.

$ cp /backup_dir/*.dbf $ALTIBASE_HOME/dbs;

메모리 체크포인트 이미지 파일의 백업본을 원래 위치로 복사#

메모리 테이블스페이스에 대해 핑퐁(ping pong) 체크 포인트 기법을 사용하고 있기 때문에, 백업 시에는 메모리 테이블스페이스의 안전한(stable)한 데이터 파일만 복사되었다.

예) 백업받은 메모리 테이블스페이스의 데이터 파일이 다음과 같다.

SYS_TBS_MEM_DIC-1-0
SYS_TBS_MEM_DIC-1-1
SYS_TBS_MEM_DIC-1-2
SYS_TBS_MEM_DATA-0-0
SYS_TBS_MEM_DATA-0-1
SYS_TBS_MEM_DATA-0-2

백업된 메모리 테이블스페이스는 안정한(stable) 데이터 파일이기 때문에 안정한 버전의 확인 절차 없이 복사하면 된다.

$ cp SYS_TBS_MEM_DIC-1-0  $ALTIBASE_HOME/dbs
$ cp SYS_TBS_MEM_DIC-1-1  $ALTIBASE_HOME/dbs
$ cp SYS_TBS_MEM_DIC-1-2  $ALTIBASE_HOME/dbs
$ cp SYS_TBS_MEM_DATA-0-0  $ALTIBASE_HOME/dbs 
$ cp SYS_TBS_MEM_DATA-0-1  $ALTIBASE_HOME/dbs
$ cp SYS_TBS_MEM_DATA-0-2  $ALTIBASE_HOME/dbs

로그 앵커 파일의 백업본을 원래 위치로 복사#

불완전 복구는 백업된 로그앵커 파일을 사용한다. 백업 된 저장 장치로부터 로그앵커를 복사한다.

$ cp /backup_dir/loganchor* $ALTIBASE_HOME/logs

불완전 복구에 필요한 아카이브 로그 파일 확인#

불완전 복구에 필요한 아카이브 로그 파일을 아래와 같이 확인한다.

iSQL(sysdba)> SELECT LAST_DELETED_LOGFILE FROM V$LFG;
LAST_DELETED_LOGFILE
-----------------------------------------------------
15021

$ALTIBASE_HOME$/logs 에 있는 파일을 확인한다.

$ ls
logfile15361  logfile15362  logfile15363  logfile15364  logfile15365

위 결과에 의해 logfile15021 다음 파일인 logfile15022부터 logs에 없는 logfile15360번 까지 모두 ARCHIVE_DIR 프로퍼티에 지정된 디렉터리 (혹은 백업 장치)로부터 LOG_DIR 프로퍼티에 지정된 디렉터리에 복사한다. 불완전 복구는 완전 복구와 달리 로그 파일 중복이 불가피하게 허용된다.

시스템 임시 테이블스페이스의 데이터 파일 생성#

SYS_TBS_DISK_TEMP는 백업되지 않기 때문에 해당 파일을 만들어 준다.

iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'temp001.dbf'

불완전 복구 수행#

불완전 복구를 수행한다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL TIME '2007-09-18:14:30:00';

RESETLOGS 옵션을 사용한 메타 단계 구동#

불완전 복구를 수행하였기 때문에 meta 구동 단계로 가면서 resetlogs옵션을 사용하여야 한다.

iSQL(sysdba)> ALTER DATABASE mydb META RESETLOGS;

전체 데이터베이스 백업 수행#

resetlogs를 수행하였기 때문에 전체 데이터베이스 백업을 받는다.

iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO 'backup_dir';

매체 복구 사례 5: 온라인 로그파일 유실 후 불완전 복구 사례#

아카이브 로그 모드로 데이터베이스를 운영중이며, 온라인 로그파일이 499번부터 600번까지 있고, 중간 로그파일인 570번 로그 파일이 유실되었다.

복구 절차#

데이터 파일과 로그앵커 파일의 백업본을 원래 위치로 복사#

불완전 복구에 필요한 데이터 파일과 로그앵커 파일을 백업 본으로부터 복사한다.

불완전 복구에 필요한 아카이브 로그 파일 확인#

불완전 복구에 필요한 아카이브 로그 파일을 확인한다.

불완적 복구 수행#

Logfile499부터 569까지의 리두 로그만 데이터베이스에 반영하고, logfile570번 이후의 로그 파일의 리두 로그는 반영하지 않는다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL CANCEL;

RESETLOGS 옵션을 사용한 메타 단계 구동#

불완전 복구를 수행하였기 때문에 meta 구동 단계로 가면서 resetlogs옵션을 사용하여야 한다.

iSQL(sysdba)> ALTER DATABASE mydb META RESETLOGS;

전체 데이터베이스 백업 수행#

resetlogs를 수행하였기 때문에 전체 데이터베이스 백업을 받는다.

iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO '/backup_dir';

매체 복구 사례 6: 임시 테이블스페이스의 데이터 파일 유실#

노아카이브 로그 모드로 운영 중인 데이터베이스이지만 매체 복구를 수행할 수 있는 경우가 있다. 바로 임시(temporary) 테이블스페이스의 데이터 파일이 유실되는 경우이다. 임시 테이블스페이스에 대해서는 변경의 재수행이 필요 없기 때문이다.

복구 절차#

컨트롤 단계로 구동#

iSQL(sysdba)> STARTUP CONTROL;

시스템 임시 테이블스페이스의 데이터 파일 생성#

CONTROL 구동 단계에서 SYS_TBS_DISK_TEMP 테이블스페이스의 유실된 데이터 파일 대신에 새로운 temp001.dbf를 생성한다.

iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'temp001.dbf'

서비스 단계로 구동#

서버를 구동한다.

iSQL(sysdba)> ALTER DATABASE mydb SERVICE;

매체 복구 사례 7: 메모리 체크포인트 이미지 파일 유실#

아카이브 로그 모드로 데이터베이스를 운영중이며, SYS_TBS_MEM_DIC 딕셔너리 테이블스페이스의 데이터 파일이 유실되었다.

백업 절차#

마지막 백업 시 다음과 같이 전체 데이터베이스 백업을 한다.

iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO '/backup_dir';

복구 절차#

완전 복구에 필요한 아카이브 로그 파일 복사#

완전 복구에 필요한 아카이브 로그 파일을 확인한 후, 아카이브 디렉터리로 해당 파일들을 복사한다. 필요한 아카이브 로그 파일을 확인하는 방법은 복구될 데이터 파일의 헤더에 있는 정보를 참조하는 것이다. 헤더 정보는 dumpdb 유틸리티를 이용하여 다음과 같이 확인할 수 있다

$ dumpdb -j 0 -f SYS_TBS_MEM_DIC-0-0
[BEGIN CHECKPOINT IMAGE HEADER]
Binary DB Version             [ 7.3.0 ]
Redo LSN       [ 4, 2257550 ]
Create LSN     [ 0, 657403 ]
[END CHECKPOINT IMAGE HEADER]

위 결과는 백업된 데이터 파일을 사용하여 데이터베이스를 복원하기 위해서는 logfile4 아카이브 로그 파일 이후의 파일들이 필요함을 나타낸다.

메모리 체크포인트 이미지 파일의 백업본을 원래 위치로 복사#

백업받은 안정한(stable) 데이터 파일은 원위치에 복사해야 한다. 백업된 파일이 SYS_TBS_MEM_DIC-0-0이라면 아래와 같이 데이터 파일을 복사하도록 한다.

$ cp /backup_dir/SYS_TBS_MEM_DIC-0-0 $ALTIBASE_HOME/dbs;

메모리 체크포인트 이미지의 백업 파일을 안정된 체크포인트 이미지 파일 번호로 복사#

$ALTIBASE_HOME/bin/dumpla loganchor0 결과 중 테이블스페이스 이름이 SYS_TBS_MEM_DIC인 테이블스페이스 속성들 중 Stable Checkpoint Image Num이란 항목을 참고한다.

$ dumpla loganchor0
[ TABLESPACE ATTRIBUTE ]
Tablespace ID                 [ 0 ]
Tablespace Name               [ SYS_TBS_MEM_DIC ]
New Database File ID          [ 0 ]
Tablespace Status             [ ONLINE ]
TableSpace Type               [ 0 ]
Checkpoint Path Count         [ 0 ]
Autoextend Mode               [ Autoextend ]
Shared Memory Key             [ 0 ]
Stable Checkpoint Image Num.  [ 1 ]
Init Size                     [ 4 MBytes ( 129 Pages ) ]
Next Size                     [ 4 MBytes ( 128 Pages ) ]
Maximum Size                  [ 134217727 MBytes ( 4294967295 Pages ) ]
Split File Size               [ 1024 MBytes ( 32768 Pages ) ]


[ MEMORY CHECKPOINT PATH ATTRIBUTE ]
Tablespace ID                 [ 0 ]
Checkpoint Path               [ /home/altibase_home/dbs ]
[ MEMORY CHECKPOINT IMAGE ATTRIBUTE ]
Tablespace ID                 [ 0 ]
File Number                   [ 0 ]
Create LSN                    [ 0, 2028 ]
Create On Disk (PingPong 0)   [ Created ]
Create On Disk (PingPong 1)   [ Created ]

백업 데이터 파일의 번호는 [0]이고 현재 안정한 데이터 파일의 번호는 [1]이므로, 다음과 같이 복사한다.

$ cd $ALTIBASE_HOME/dbs
$ cp SYS_TBS_MEM_DIC-0-0  SYS_TBS_MEM_DIC-1-0

컨트롤 단계로 구동#

iSQL(sysdba)> STARTUP CONTROL;

매체 복구 수행#

CONTROL 구동 단계에서 매체 복구를 수행한다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE;

서비스 단계로 구동#

매체 복구가 완료되었으므로 재시작시 자동 복구를 수행한다.

iSQL(sysdba)> ALTER DATABASE mydb SERVICE;

매체 복구 사례 8: 디스크 테이블스페이스 삭제 후 불완전 복구 사례#

아카이브 로그 모드로 데이터베이스를 운영하고 있으며, 사용자 실수로 테이블스페이스 USER_DISK_TBS가 삭제되었다. 삭제 시점은 2007년 4월 6일 22시 30분이었다. 테이블스페이스가 존재했던 10분 전의 상태로 데이터베이스를 복구하려고 한다.

백업 절차#

마지막 백업 시 다음과 같이 전체 데이터베이스 백업을 하였다.

iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO '/backup_dir';
iSQL(sysdba)> ALTER SYSTEM SWITCH LOGFILE;

복구 절차#

데이터 파일의 백업본 복사을 원래 위치로 복사#

불완전 복구에 필요한 데이터 파일과 로그앵커 파일을 백업 본으로부터 복사한다. 백업 받은 데이터베이스의 모든 디스크 테이블스페이스의 데이터 파일들을 데이터 파일들의 원래 위치로 복사한다.

$ cp /backup_dir/*.dbf $ALTIBASE_HOME/dbs
$ cp /backup_dir/SYS_TBS_* $ALTIBASE_HOME/dbs

아카이브 로그 파일 확인#

불완전 복구에 필요한 아카이브 로그 파일을 확인한다.

로그 앵커 파일의 백업본을 원래 위치로 복사#

불완전 복구는 백업된 로그앵커 파일을 사용한다. 백업 저장 장치로부터 로그앵커 파일을 복사한다.

$ cp /backup_dir/loganchor* $ALTIBASE_HOME/logs

시스템 임시 테이블스페이스의 데이터 파일 생성#

SYS_TBS_DISK_TEMP 테이블스페이스는 백업되지 않기 때문에 해당 파일을 새로 만들어 준다.

iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'temp001.dbf'

불완전 복구 수행#

불완전 복구를 수행한다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL TIME '2007-04-06:22:20:00';

RESETLOGS 옵션을 사용한 메타 단계 구동#

불완전 복구를 수행하였기 때문에 meta 구동 단계로 가면서 resetlogs 옵션을 사용하여야 한다.

iSQL(sysdba)> ALTER DATABASE mydb META RESETLOGS;

서비스 단계로 구동#

서버를 구동한다.

iSQL(sysdba)> ALTER DATABASE mydb SERVICE;

전체 데이터베이스 백업 수행#

로그가 리셋되었기 때문에 전체 데이터베이스 백업을 수행하는 것이 좋다.

iSQL(sysdba)> ALTER DATABASE BACKUP DATABASE TO 'backup_dir';