다운타임을 최소화하고 데이터베이스 가용성을 높이는 것은 모든 비즈니스가 추구하는 핵심 목표입니다. 데이터베이스 관리자(DBA)는 데이터 파일 또는 전체 데이터베이스 손상 장애가 발생했을 때 더 빠르게 복구할 수 있는 솔루션을 늘 찾고 있습니다. Oracle® 10g 버전부터 Recovery Manager(RMAN)에서 제공되는 증분 병합 백업(Incremental Merge Backups, IMB) 기능은 특히 대용량 데이터베이스(VLDB) 환경에서 복구 시간을 획기적으로 단축할 수 있는 강력한 해결책입니다.
개요
IMB 기능은 적절한 옵션으로 구성만 하면 데이터베이스 복구 시간을 크게 줄일 수 있습니다. 널리 알려져 있지는 않지만, 이 기능은 VLDB에 가장 이상적인 백업 방식 중 하나입니다. 먼저 데이터 파일의 이미지 사본(image copy)을 생성한 뒤, 매 백업 작업 시마다 증분 백업을 적용하여 이미지 사본을 롤포워드(roll forward)하는 방식으로 동작합니다.
이 글에서는 IMB 사용 시 고려해야 할 사항을 살펴보고, 전체 과정을 보여주는 샘플 코드와 함께 다양한 복구 시나리오를 소개합니다.
사전 고려 사항
이미지 사본 기반의 백업 전략을 도입하기 전에 다음 사항을 반드시 확인해야 합니다.
- 데이터베이스에서 블록 변경 추적(Block Change Tracking, BCT)이 활성화되어 있어야 합니다.
- 데이터베이스 데이터 파일이 실제 사용 중인 용량과 동일한 디스크 공간을 이미지 사본 저장용으로 확보해야 합니다.
- 특정 시점 복구(Point-in-Time Recovery, PITR)를 수행하려면 최소 한 번의 전체 백업이 필요하며, 복구가 완료될 때까지 아카이브 로그도 보관해야 합니다.
- 데이터베이스 사본으로 전환(switch)하는 과정에서 성능 저하가 발생하지 않도록, 이미지 사본은 원본과 입출력(I/O) 특성이 동일한 유형의 스토리지에 보관하는 것이 좋습니다.
다음 그림은 증분 업데이트 방식의 백업 구조를 보여줍니다.
샘플 코드
아래 코드를 실행하면 매일 이미지 사본을 생성하고 증분 방식으로 갱신할 수 있습니다.
run
{
allocate channel c1 device type disk format '/home/oracle/backup/%U';
recover copy of database with tag 'IMG_COPY';
backup incremental level 1 for recover of copy with tag 'IMG_COPY' database;
release channel c1;
}
첫 번째 실행 시: recover copy of database 명령은 아무 작업도 수행하지 않습니다. backup incremental 명령은 해당 태그로 생성되는 첫 번째 백업이므로, IMG_COPY 태그가 지정된 새로운 증분 level 0 백업을 생성합니다.
두 번째 실행 시: recover copy of database 명령은 INC 1 백업을 찾을 때까지 아무 작업도 하지 않습니다. backup incremental 명령은 INC 1 백업을 생성합니다.
세 번째 실행부터: recover 명령은 마지막으로 사용 가능한 INC 1 백업을 기존 이미지 사본에 적용하고, backup 명령은 다음 INC 1 백업을 생성합니다.
복구 시나리오
다음 사용 사례들은 증분 병합 백업이 다양한 복구 상황에서 어떻게 활용되는지 보여줍니다.
사례 1: 데이터 파일 손상, 삭제 또는 덮어쓰기
먼저 아래 코드와 같이 테스트용 테이블을 생성하고, 앞서 소개한 스크립트로 이미지 사본을 만들어 둡니다.
SQL> create table ImgCpyTab tablespace tbs2 as select * from dba_objects;
Table created.
FILE_NAME FILE_ID TABLESPACE_NAME
————————- ——————— ———————————————
/home/oracle/Sw/oradata/test/tbs02.dbf 5 TBS2
SQL> select count(1) from ImgCpyTab;
COUNT(1)
———-
72476
이 시나리오를 테스트하기 위해 물리적 데이터 파일을 의도적으로 이동시키면, select 명령 실행 시 예상대로 오류가 발생합니다.
mv /home/oracle/Sw/oradata/test/tbs02.dbf /home/oracle/Sw/oradata/test/tbs02.dbf_BKP
select count(1) from scott.IMGCPYTAB
*
ERROR at line 1:
ORA-01116: error in opening database file 5
ORA-01110: data file 5: '/home/oracle/Sw/oradata/test/tbs02.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3
이 경우 물리적 파일을 복원할 필요가 없습니다. 대신 백업 사본으로 전환(switch)한 후 복구하면 됩니다. 데이터 파일이나 데이터베이스 크기가 테라바이트급이라 해도 매우 빠르게 처리됩니다.
먼저 아래 코드로 해당 데이터 파일을 오프라인 모드로 전환합니다.
SQL> alter database datafile 5 offline;
Database altered.
다음으로 데이터 파일을 사본으로 전환하고 복구를 진행합니다.
[oracle@localhost backup]$ rman target /
Recovery Manager: Release 11.2.0.2.0 – Production on Thu Jun 5 18:17:15 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: TEST (DBID=2122535405)
RMAN> switch datafile 5 to copy;
using target database control file instead of recovery catalog
datafile 5 switched to datafile copy "/home/oracle/backup/data_D-TEST_I-2122535405_TS-TBS2_FNO-5_6ppa3ev1"
RMAN> recover datafile 5;
Starting recover at 05-JUN-14
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=149 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 05-JUN-14
RMAN> sql 'alter database datafile 5 online';
sql statement: alter database datafile 5 online
RMAN> exit
아래 결과에서 확인할 수 있듯이, 데이터 파일이 정상 복구되었으며 테이블에도 문제없이 접근할 수 있습니다.
FILE_NAME FILE_ID TABLESPACE_NAME
————————- ——————— ———————————————
TBS2 /home/oracle/backup/data_D-TEST_I-2122535405_TS-TBS2_FNO-5_6ppa3ev1 AVAILABLE
SQL> select count(1) from scott.IMGCPYTAB;
COUNT(1)
———-
72476
참고: file_name 열을 확인하면 데이터베이스가 현재 이미지 사본 파일을 사용 중임을 알 수 있습니다.
사례 2: 전체 데이터베이스 손상 또는 디스크 장애
데이터베이스 전체가 손상되었거나 디스크 장애가 발생한 경우에는 다음 단계에 따라 데이터베이스를 사본으로 전환할 수 있습니다.
- 데이터베이스를 종료합니다.
- 컨트롤 파일이 손실된 경우 이를 복원합니다.
- 이미지 사본을 카탈로그에 등록(catalog)합니다.
- 데이터베이스를 사본으로 전환합니다.
- 사용 가능한 아카이브 로그 지점까지 복구한 후 데이터베이스를 오픈합니다.
결론
이 글에서는 RMAN의 이미지 사본 백업 및 복구 기능을 활용하는 방법을 살펴보았습니다. 아울러 물리적 손상이 발생했을 때 데이터 파일과 데이터베이스를 신속하게 복구할 수 있는 실전 사용 사례도 함께 소개했습니다. 증분 병합 백업(IMB) 기능은 데이터베이스 백업 절차를 단순화할 뿐만 아니라, 빠르고 유연한 데이터 복구를 보장합니다.
의견이나 궁금한 점이 있다면 피드백 탭을 통해 남겨 주세요.