데이터베이스 연구실.log

Recovery Catalog 유지와 복구

Recovery Catalog 재동기화와 데이터 파일, 컨트롤 파일, 리두 로그, SPFILE 손실 복구 실습

Cold BackupDUPLICATE FROM ACTIVE DATABASETNS-01201RESYNC CATALOGCONTROL_FILE_RECORD_KEEP_TIMELIST FAILUREADVISE FAILUREREPAIR FAILURERESTORE CONTROLFILE FROM AUTOBACKUPSET UNTIL SEQUENCERESTORE SPFILERC_ 뷰

#핵심 요약

카탈로그는 대상 컨트롤 파일에서 메타데이터를 가져옴
RMAN이 대상과 카탈로그에 함께 접속해 명령을 실행하면 자동으로 재동기화되며, 필요하면 RESYNC CATALOG로 수동 재동기화함

컨트롤 파일 기록이 CONTROL_FILE_RECORD_KEEP_TIME보다 오래되어 덮어쓰이기 전에 카탈로그로 옮겨야 함
이 값을 0으로 두면 안 됨

실습에서는 카탈로그에 접속한 상태에서 데이터 파일만, 컨트롤 파일까지, 리두 로그까지, SPFILE까지 사라진 경우를 차례로 복구했음

#개념과 동작 원리

부분 재동기화는 새 백업, 새 아카이브 로그 같은 바뀐 메타데이터를 대상 컨트롤 파일에서 읽음
물리 구조 정보는 갱신하지 않음

전체 재동기화는 데이터베이스 구조 정보까지 모두 갱신함
파일 추가와 삭제, 새 incarnation, RMAN 설정 변경 뒤에 수행됨
이때 임시 백업 컨트롤 파일인 스냅샷 컨트롤 파일을 만듦

로그 스위치나 아카이브만으로는 카탈로그가 갱신되지 않음
백업을 드물게 받고 로그 스위치가 많은 ARCHIVELOG DB는 주기적으로 수동 재동기화함

카탈로그를 쓸 수 없던 동안 명령을 실행했다면, 나중에 카탈로그 DB를 열고 RESYNC CATALOG를 실행함

#필수 명령어 또는 SQL

#수동 재동기화

RMAN (대상 + 카탈로그)객체 또는 설정을 변경함
RESYNC CATALOG;

결과 해석: 개별 실행 출력은 기재 없음

#1. 데이터 파일만 사라진 경우: 장애 진단과 자동 수리

SQL*Plus (SYSDBA)조회만 함
SELECT r.file#, d.name FROM v$recover_file r, v$datafile d WHERE r.file# = d.file#;
RMAN (대상 + 카탈로그)객체 또는 설정을 변경함
LIST FAILURE;
ADVISE FAILURE;
REPAIR FAILURE;

결과 해석:

실습 기록: ADVISE FAILURE가 "Restore and recover database", "complete media recovery with no data loss" 전략과 수리 스크립트 경로를 보여 줬음
REPAIR FAILURE는 그 스크립트를 실행함
실습에서는 RAC 환경에서는 쓸 수 없다고 적었음

#2. 컨트롤 파일까지 사라진 경우

카탈로그 소유자로 카탈로그 뷰를 조회해 남은 정보를 확인함

SQL*Plus (카탈로그 소유자)조회만 함
SELECT * FROM rc_database;
SELECT * FROM rc_datafile;
SELECT * FROM rc_archived_log;
SELECT * FROM rc_backup_set WHERE controlfile_included = 'BACKUP';
RMAN (대상 + 카탈로그, NOMOUNT)객체 또는 설정을 변경함
LIST BACKUP OF CONTROLFILE;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
RMAN객체 또는 설정을 변경함
BACKUP DATABASE;

결과 해석:

설명: 컨트롤 파일을 복원하면 RESETLOGS로 열어야 하므로 불완전 복구가 되고, 끝나면 전체 백업을 다시 받음
자동 수리(REPAIR FAILURE)도 가능하지만 컨트롤 파일까지 없으면 두 번 해야 했다고 적었음

#3. 리두 로그까지 사라진 경우: 시퀀스 기준 불완전 복구

RMAN (대상 + 카탈로그)객체 또는 설정을 변경함
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
LIST INCARNATION OF DATABASE;
CATALOG START WITH '<FRA_DIR>/archivelog' NOPROMPT;
LIST ARCHIVELOG ALL;
SQL*Plus (SYSDBA, MOUNT)조회만 함
SELECT group#, members, status, sequence# FROM v$log;

결과 해석:

설명: 복원한 컨트롤 파일의 V$LOG 시퀀스(실습에서는 1)는 불완전 복구 기준으로 쓰면 안 됨
장애 전 현재 리두 그룹의 시퀀스를 확인해야 함
실습에서는 CATALOG START WITH로 아카이브 로그를 다시 등록하고 LIST ARCHIVELOG ALL로 정상 파일이 시퀀스 5까지임을 확인했음

RMAN (대상 + 카탈로그)객체 또는 설정을 변경함
RUN {
  SET UNTIL SEQUENCE 6 THREAD 1;
  RESTORE DATABASE;
  RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;

결과 해석:

설명: UNTIL SEQUENCE 6은 시퀀스 6 직전, 즉 5까지 복구함

#4. SPFILE까지 사라진 경우

RMAN (대상 + 카탈로그)인스턴스 또는 서비스 중단이 필요함
SET DBID <DBID>;
STARTUP FORCE NOMOUNT;
LIST BACKUP OF SPFILE;
RESTORE SPFILE;
RMAN인스턴스 또는 서비스 중단이 필요함
SHUTDOWN IMMEDIATE;
STARTUP;
SQL*Plus (SYSDBA)조회만 함
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별 아카이브 로그 정보, 저장 스크립트를 가지므로, 잃으면 컨트롤 파일 보존 기간이 지난 장기 이력을 확인하기 어려움

SQL*Plus (카탈로그 소유자)조회만 함
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#;
SQL*Plus (카탈로그 DB SYSDBA)조회만 함
SELECT name FROM v$datafile;
SELECT name FROM v$controlfile;
SELECT member FROM v$logfile;
SHOW PARAMETER spfile
OS 셸 (oracle 사용자, 카탈로그 DB 서버)인스턴스 또는 서비스 중단이 필요함
# 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/
RMAN (대상 DB 노드)조회만 함
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)

파일 (복제 노드 $ORACLE_HOME/dbs/initclonedb.ora)객체 또는 설정을 변경함
db_name=<CLONE_DB_NAME>
sga_target=500M
pga_aggregate_target=100M
파일 (복제 노드 그리드 홈 listener.ora에 추가)객체 또는 설정을 변경함
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = <CLONE_DB_NAME>)
      (ORACLE_HOME = <DB_HOME>)
      (SID_NAME = <CLONE_DB_NAME>)))
RMAN (소스 노드)객체 또는 설정을 변경함
-- 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';

결과 해석:

  1. 소스(실습의 non-CDB 카탈로그 DB)는 OPEN 상태로 복제하려면 ARCHIVELOG여야 해, srvctl stop database, srvctl start database -o mount 뒤 ALTER DATABASE ARCHIVELOG, FRA 지정을 먼저 함
  2. 소스 패스워드 파일을 복제 노드의 orapwclonedb로 복사해 두 DB의 SYS 비밀번호를 같게 함
  3. 복제 노드에 데이터, 감사, FRA 디렉터리를 만들고 최소 PFILE로 STARTUP NOMOUNT함(V$INSTANCE.STATUS가 STARTED, V$DATABASE 조회는 ORA-01507)
  4. NOMOUNT 인스턴스는 동적 등록만으로 BLOCKED가 될 수 있어 그리드 홈 리스너에 정적 등록하고 lsnrctl reload함
    ORACLE_HOME에 그리드 홈을 적으면 TNS-01201: Listener cannot find executable이 남
  5. 양쪽 노드 tnsnames.ora에 복제 노드 주소(SCAN이 아님)로 별칭을 두고, tnsping이 아니라 실제 sqlplus sys@<CLONE_ALIAS> as sysdba로 원격 접속을 확인한 뒤 소스 노드에서 DUPLICATE를 실행함
  6. 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 중분류에서 다룸

SEO_HKabsumveritas@gmail.comBuilt with Claude Code & Codex

마지막 갱신 개인 학습 기록이며 운영 환경 적용 전 공식 문서 확인 필요

두 글자 이상 입력, 위아래 화살표로 이동하고 Enter로 열기