Recovery Catalog 유지와 복구
Recovery Catalog 재동기화와 데이터 파일, 컨트롤 파일, 리두 로그, SPFILE 손실 복구 실습
#핵심 요약
카탈로그는 대상 컨트롤 파일에서 메타데이터를 가져옴
RMAN이 대상과 카탈로그에 함께 접속해 명령을 실행하면 자동으로 재동기화되며, 필요하면 RESYNC CATALOG로 수동 재동기화함
컨트롤 파일 기록이 CONTROL_FILE_RECORD_KEEP_TIME보다 오래되어 덮어쓰이기 전에 카탈로그로 옮겨야 함
이 값을 0으로 두면 안 됨
실습에서는 카탈로그에 접속한 상태에서 데이터 파일만, 컨트롤 파일까지, 리두 로그까지, SPFILE까지 사라진 경우를 차례로 복구했음
#개념과 동작 원리
부분 재동기화는 새 백업, 새 아카이브 로그 같은 바뀐 메타데이터를 대상 컨트롤 파일에서 읽음
물리 구조 정보는 갱신하지 않음
전체 재동기화는 데이터베이스 구조 정보까지 모두 갱신함
파일 추가와 삭제, 새 incarnation, RMAN 설정 변경 뒤에 수행됨
이때 임시 백업 컨트롤 파일인 스냅샷 컨트롤 파일을 만듦
로그 스위치나 아카이브만으로는 카탈로그가 갱신되지 않음
백업을 드물게 받고 로그 스위치가 많은 ARCHIVELOG DB는 주기적으로 수동 재동기화함
카탈로그를 쓸 수 없던 동안 명령을 실행했다면, 나중에 카탈로그 DB를 열고 RESYNC CATALOG를 실행함
#필수 명령어 또는 SQL
#수동 재동기화
RESYNC CATALOG;결과 해석: 개별 실행 출력은 기재 없음
#1. 데이터 파일만 사라진 경우: 장애 진단과 자동 수리
SELECT r.file#, d.name FROM v$recover_file r, v$datafile d WHERE r.file# = d.file#;LIST FAILURE;
ADVISE FAILURE;
REPAIR FAILURE;결과 해석:
실습 기록: ADVISE FAILURE가 "Restore and recover database", "complete media recovery with no data loss" 전략과 수리 스크립트 경로를 보여 줬음REPAIR FAILURE는 그 스크립트를 실행함
실습에서는 RAC 환경에서는 쓸 수 없다고 적었음
#2. 컨트롤 파일까지 사라진 경우
카탈로그 소유자로 카탈로그 뷰를 조회해 남은 정보를 확인함
SELECT * FROM rc_database;
SELECT * FROM rc_datafile;
SELECT * FROM rc_archived_log;
SELECT * FROM rc_backup_set WHERE controlfile_included = 'BACKUP';LIST BACKUP OF CONTROLFILE;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;BACKUP DATABASE;결과 해석:
설명: 컨트롤 파일을 복원하면 RESETLOGS로 열어야 하므로 불완전 복구가 되고, 끝나면 전체 백업을 다시 받음
자동 수리(REPAIR FAILURE)도 가능하지만 컨트롤 파일까지 없으면 두 번 해야 했다고 적었음
#3. 리두 로그까지 사라진 경우: 시퀀스 기준 불완전 복구
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
LIST INCARNATION OF DATABASE;
CATALOG START WITH '<FRA_DIR>/archivelog' NOPROMPT;
LIST ARCHIVELOG ALL;SELECT group#, members, status, sequence# FROM v$log;결과 해석:
설명: 복원한 컨트롤 파일의 V$LOG 시퀀스(실습에서는 1)는 불완전 복구 기준으로 쓰면 안 됨
장애 전 현재 리두 그룹의 시퀀스를 확인해야 함
실습에서는 CATALOG START WITH로 아카이브 로그를 다시 등록하고 LIST ARCHIVELOG ALL로 정상 파일이 시퀀스 5까지임을 확인했음
RUN {
SET UNTIL SEQUENCE 6 THREAD 1;
RESTORE DATABASE;
RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;결과 해석:
설명: UNTIL SEQUENCE 6은 시퀀스 6 직전, 즉 5까지 복구함
#4. SPFILE까지 사라진 경우
SET DBID <DBID>;
STARTUP FORCE NOMOUNT;
LIST BACKUP OF SPFILE;
RESTORE SPFILE;SHUTDOWN IMMEDIATE;
STARTUP;SHOW PARAMETER spfile
SELECT instance_name, status FROM v$instance;결과 해석:
설명: 파라미터 파일이 없으면 RMAN이 임시 파라미터로 NOMOUNT 기동을 시도함
카탈로그에서 백업 정보를 찾으므로 FROM AUTOBACKUP을 붙일 필요가 없음
SPFILE만 복원했다면 RECOVER DATABASE나 OPEN RESETLOGS가 필요 없음
텍스트 PFILE 자체는 RMAN 백업 대상이 아니며, SPFILE 백업에서 RESTORE SPFILE TO PFILE '<경로>'로 만들 수 있음
#카탈로그 DB 자체의 Cold Backup
카탈로그 DB는 여러 대상 DB의 백업 이력, thread별 아카이브 로그 정보, 저장 스크립트를 가지므로, 잃으면 컨트롤 파일 보존 기간이 지난 장기 이력을 확인하기 어려움
SELECT db_key, dbid, name FROM rc_database;
SELECT db_name, COUNT(*) FROM rc_backup_set_details GROUP BY db_name;
SELECT thread#, COUNT(*), MAX(sequence#) FROM rc_archived_log GROUP BY thread#;SELECT name FROM v$datafile;
SELECT name FROM v$controlfile;
SELECT member FROM v$logfile;
SHOW PARAMETER spfile# SQL*Plus에서 SHUTDOWN IMMEDIATE 뒤
ps -ef | grep -E 'ora_(dbw|lgwr|ckpt)' | grep -v grep
mkdir -p /home/oracle/coldbackup
cp <DATAFILE_DIR>/* /home/oracle/coldbackup/
cp $ORACLE_HOME/dbs/spfile<SID>.ora $ORACLE_HOME/dbs/orapw<SID> /home/oracle/coldbackup/RESYNC CATALOG;
LIST BACKUP SUMMARY;결과 해석:
OPEN 상태에서는 DBWR, LGWR, CKPT가 데이터 파일, 리두, 컨트롤 파일을 계속 바꾸므로 SHUTDOWN IMMEDIATE로 체크포인트 뒤 정상 종료하고 복사함
종료 뒤 ps에 세 프로세스가 보이지 않아야 파일 변경이 멈춘 것임
SHUTDOWN ABORT 직후 복사한 파일은 일관된 Cold Backup으로 쓸 수 없음
카탈로그 테이블스페이스 파일 하나만 복사하면 복원할 수 없고, 같은 시점의 데이터 파일, 컨트롤 파일, 리두, SPFILE, 패스워드 파일을 함께 보관함
카탈로그 DB를 다시 연 뒤 대상 DB에서 RESYNC CATALOG로 내려가 있던 동안의 기록을 반영함
실습 카탈로그 DB는 NOARCHIVELOG라 온라인 백업이 안 됨
RMAN으로 받을 때도 rman target / nocatalog로 접속해 SHUTDOWN IMMEDIATE, STARTUP MOUNT, BACKUP DATABASE, ALTER DATABASE OPEN 순으로 하며 그 기록은 자기 컨트롤 파일에 남음
운영 DB는 서비스 중단 없이 받을 수 있는 ARCHIVELOG + RMAN 온라인 백업이 일반적으로 맞음
연습 문제: 카탈로그 테이블스페이스 파일을 지워 카탈로그 DB가 열리지 않을 때 Cold Backup으로 다시 열고 대상 DB의 최근 백업 이력을 되살림, SHUTDOWN ABORT 뒤 바로 복사하는 야간 스크립트의 문제를 설명하고 고침
#카탈로그 DB를 다른 노드에 복제 (Active Duplicate)
db_name=<CLONE_DB_NAME>
sga_target=500M
pga_aggregate_target=100MSID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = <CLONE_DB_NAME>)
(ORACLE_HOME = <DB_HOME>)
(SID_NAME = <CLONE_DB_NAME>)))-- rman target sys@<SOURCE_ALIAS> auxiliary sys@<CLONE_ALIAS>
DUPLICATE TARGET DATABASE TO <CLONE_DB_NAME>
FROM ACTIVE DATABASE
SPFILE
SET db_unique_name = '<CLONE_DB_NAME>'
SET control_files = '<CLONE_DIR>/control01.ctl', '<CLONE_DIR>/control02.ctl'
SET audit_file_dest = '<ADUMP_DIR>'
SET db_file_name_convert = '/<CATALOG_DB_NAME>/', '/<CLONE_DB_NAME>/'
SET log_file_name_convert = '/<CATALOG_DB_NAME>/', '/<CLONE_DB_NAME>/'
SET db_recovery_file_dest = '<FRA_DIR>'
SET local_listener = '(ADDRESS=(PROTOCOL=TCP)(HOST=<CLONE_HOST>)(PORT=1521))'
SET sga_target = '500M'
SET pga_aggregate_target = '100M';결과 해석:
- 소스(실습의 non-CDB 카탈로그 DB)는 OPEN 상태로 복제하려면 ARCHIVELOG여야 해,
srvctl stop database,srvctl start database -o mount뒤ALTER DATABASE ARCHIVELOG, FRA 지정을 먼저 함 - 소스 패스워드 파일을 복제 노드의
orapwclonedb로 복사해 두 DB의 SYS 비밀번호를 같게 함 - 복제 노드에 데이터, 감사, FRA 디렉터리를 만들고 최소 PFILE로
STARTUP NOMOUNT함(V$INSTANCE.STATUS가 STARTED,V$DATABASE조회는ORA-01507) - NOMOUNT 인스턴스는 동적 등록만으로 BLOCKED가 될 수 있어 그리드 홈 리스너에 정적 등록하고
lsnrctl reload함ORACLE_HOME에 그리드 홈을 적으면TNS-01201: Listener cannot find executable이 남 - 양쪽 노드 tnsnames.ora에 복제 노드 주소(SCAN이 아님)로 별칭을 두고,
tnsping이 아니라 실제sqlplus sys@<CLONE_ALIAS> as sysdba로 원격 접속을 확인한 뒤 소스 노드에서 DUPLICATE를 실행함 Finished Duplicate Db가 나오면, 복제 노드에서/etc/oratab에 등록하고V$DATABASE의 DBID가 소스와 다른지, 데이터 파일과 리두가/<CLONE_DB_NAME>/경로인지, 카탈로그 테이블rc_database까지 복제됐는지 확인함
db_file_name_convert, log_file_name_convert, 별도 control_files를 빠뜨리면 소스 파일과 충돌하거나 덮어쓸 위험이 있음
소스 SPFILE의 메모리 값과 local_listener가 그대로 따라오므로 DUPLICATE 안에서 다시 지정함
복제본은 Clusterware 등록 대상이 아니라 srvctl 대신 SQL*Plus로 기동, 종료함
삭제는 STARTUP MOUNT RESTRICT 뒤 DROP DATABASE, 파라미터 파일과 oratab 줄, 리스너 정적 등록 제거
활용 예: 개발, 테스트용 운영 데이터 복제본, 업그레이드, 대규모 DDL, 패치 리허설, 운영에서 하기 어려운 SQL 튜닝 시험, 백업으로 실제 복구할 수 있는지 보는 복구 훈련, 이기종 이행 전 정합성 시험
#사용 조건과 주의사항
불완전 복구는 지정한 시점 이후의 변경을 잃음
시점 복구 일반은 시점 복구와 Flashback 중분류에서 다룸