RMAN을 이용한 restore 및 recovery

장애 발생 시 올바른 RMAN 복구를 단계별로 진행합니다. 19개 시나리오: datafile, SYSTEM/UNDO, tempfile, 손상 블록, online redo log, controlfile, spfile 손실; 전체 restore, 다른 디렉터리/ASM 및 다른 서버로 restore; 시점 복구(CDB 또는 PDB PITR), Flashback Database, tablespace PITR, 단일 테이블 복구(RECOVER TABLE), 삭제된 PDB; Data Guard를 통한 네트워크 restore(FROM SERVICE), 아카이브 로그만 restore, 이동된 백업 등록(CATALOG), 데이터를 쓰지 않는 모의 실행(PREVIEW/VALIDATE). 모든 시나리오는 진단 → 안전장치 → 적용 → 검증 → 새 백업 순서로 진행되며, 단일 인스턴스, Oracle Restart, RAC(CLUSTER_DATABASE=FALSE로 단일 인스턴스에서 복구)별로 단계를 따로 제공합니다. 백업 수행이 아니라 복구를 다룹니다. 백업 계획은 "Oracle 백업 전략" 가이드를 참고하십시오.

구성: 서버 1대(단일 인스턴스 또는 Oracle Restart) 또는 RAC. 새 호스트 시나리오에서는 소스 + 대상

시나리오

• 모의 실행: RESTORE … PREVIEW / VALIDATE (아무것도 변경하지 않음) — 손상된 것은 없으며, 데이터를 쓰지 않고 백업이 실제 복구에 충분한지 확인하려는 경우입니다(데이터베이스는 열린 상태 유지). 월간 restore 훈련이나 어떤 시나리오를 골라야 할지 확신이 없을 때의 첫 단계이기도 합니다.
• 백업이 다른 디렉터리로 이동됨 / RMAN이 백업을 찾지 못함 (CATALOG) — 백업 piece는 있지만 RMAN이 알지 못합니다(이동됨, NFS 변경, 다른 서버에서 복사됨). RMAN-06023/06025가 발생합니다. 데이터베이스는 열린 상태를 유지합니다.
• 아카이브 로그만 restore (RESTORE ARCHIVELOG) — LogMiner, standby gap 또는 수동 recovery를 위해 특정 sequence 범위의 아카이브 로그가 디스크에 필요합니다. 데이터베이스는 열린 상태를 유지하며 어떤 파일도 덮어쓰지 않습니다.
• 단일 datafile 또는 tablespace 손실/손상 (데이터베이스는 열린 상태 유지) — 데이터베이스는 열려 있고 datafile 또는 tablespace 하나만 읽을 수 없습니다(ORA-01157/01110/01116). 나머지는 모두 정상입니다. 파일이 SYSTEM/UNDO에 속하면 "SYSTEM 또는 UNDO" 카드를, tempfile이면 "Tempfile" 카드를, 파일은 열리지만 일부 블록이 손상되었으면(ORA-01578) "손상 블록" 카드를 선택하십시오.
• 손상 블록 (ORA-01578, block media recovery) — 쿼리에서 ORA-01578/ORA-26040이 발생하거나, 백업이 ORA-19566으로 중단되거나, VALIDATE가 손상 블록을 발견했습니다. 파일의 나머지 부분은 정상입니다. 데이터베이스는 열린 상태를 유지하고 손상된 블록만 복구합니다(Enterprise Edition. SE2에서는 파일을 restore합니다). 파일 전체를 열 수 없으면(ORA-01157) "단일 datafile" 카드를 사용하십시오.
• SYSTEM 또는 UNDO datafile 손실 (데이터베이스가 열리지 않음) — 손실되거나 손상된 파일이 SYSTEM 또는 UNDO tablespace에 속합니다. offline으로 전환할 수 없으므로 데이터베이스(PDB 파일이면 해당 PDB만)를 종료하고 MOUNT 상태에서 restore합니다. 데이터 손실은 없습니다. 다른 tablespace의 파일이면 "단일 datafile" 카드로 데이터베이스를 종료하지 않고 해결합니다.
• Tempfile 손실 또는 손상 (TEMP tablespace) — 정렬/해시 작업에서 ORA-01157/ORA-01187/ORA-25153이 발생하고 해당 파일이 tempfile입니다(오류 메시지의 번호가 db_files 값보다 큼, 예: data file 201). restore는 필요 없으며 새 tempfile을 추가합니다. 데이터베이스는 열린 상태를 유지합니다.
• Online redo log 손실 또는 손상 — Alert log에 ORA-00313/00312(열 수 없음) 또는 ORA-00327/00366/00367(손상)이 기록됩니다. 멤버 하나만 손실되었거나 그룹이 INACTIVE이면 데이터베이스는 열린 상태를 유지합니다. CURRENT 그룹이 손실되면 restore + RESETLOGS가 필요하며 마지막 트랜잭션은 손실됩니다. 진단 단계에서 그룹 상태를 확인하고 그에 따라 선택하십시오.
• 모든 controlfile 사본 손실 — 인스턴스가 MOUNT 단계에서 controlfile을 찾거나 읽지 못합니다(ORA-00205/00202/00210). datafile과 redo는 정상입니다. 사본 중 하나가 정상이면 restore가 필요 없습니다(진단 단계에서 확인). 모두 손실되었으면 autobackup에서 restore하고 RESETLOGS로 엽니다. online redo가 정상이므로 데이터 손실은 없습니다.
• spfile 손실 — spfile이 삭제되었거나 손상되었습니다. 인스턴스가 시작되지 않거나(ORA-01078/LRM-00109) 실행 중이지만 파일이 없습니다. datafile은 건드리지 않으며 데이터 손실이 없습니다. 인스턴스가 아직 실행 중이면 서비스 중단도 없습니다.
• 전체 restore, 동일 서버 (datafile 손실, controlfile 및 redo 정상) — datafile 전부 또는 대부분이 사라졌고 controlfile과 online redo log는 정상입니다. 데이터베이스를 종료하며 데이터 손실은 없습니다. 파일이 있던 기존 디스크/디렉터리를 더 이상 쓸 수 없으면 "다른 디렉터리" 카드를, controlfile도 손실되었으면 먼저 "controlfile" 카드를, 서버 전체가 사라졌으면 "다른 서버로 restore" 카드를 선택하십시오.
• 디스크 손실: 데이터베이스를 다른 디렉터리 / ASM으로 restore (SET NEWNAME) — datafile이 있는 디스크 또는 디스크 그룹을 사용할 수 없습니다. controlfile과 redo는 정상입니다. 파일을 새 디렉터리나 ASM 디스크 그룹으로 restore하며, 데이터베이스는 종료되고 데이터 손실은 없습니다.
• 시점 / SCN 복구 (PITR, RESETLOGS) — 잘못된 DELETE/UPDATE/TRUNCATE 또는 결함 있는 애플리케이션 릴리스: 데이터베이스(또는 PDB만)를 과거 시점으로 되돌립니다. 그 시점 이후의 모든 변경 사항은 손실됩니다(RESETLOGS). 먼저 범위가 더 좁은 방법을 검토하십시오. 단일 테이블 → "단일 테이블 복구", 단일 tablespace → TSPITR, flashback이 활성화되어 있으면 → "Flashback Database"(restore 없음, 훨씬 빠름).
• Flashback Database로 되감기 (restore point / SCN / 시간) — Flashback이 활성화되어 있거나 guaranteed restore point가 있고 손실된 파일이 없습니다. restore 없이 몇 분 안에 되감습니다(Enterprise Edition). RESETLOGS가 필요합니다. 활성화 여부: SELECT flashback_on FROM v$database; → YES, 또는 v$restore_point에 GUARANTEE_FLASHBACK_DATABASE = YES인 행.
• tablespace를 과거 시점으로 되돌리기 (TSPITR) — 잘못된 작업이 tablespace 하나의 객체에만 영향을 주었고, 데이터베이스의 나머지는 현재 상태를 유지해야 합니다(Enterprise Edition). 작업 동안 tablespace는 offline이 되며 그 안의 모든 객체가 대상 시점으로 돌아갑니다. 테이블 한두 개만 영향을 받았다면 "단일 테이블 복구"가 되돌리는 범위가 더 작습니다.
• 단일 테이블 복구 (RECOVER TABLE, 12c+ Enterprise Edition) — 테이블 하나가 실수로 삭제되었거나 손상되었고, 데이터베이스의 나머지는 그대로 유지되어야 합니다(12c+ Enterprise Edition). DROP되었고 PURGE하지 않았다면 먼저 recyclebin을 확인하십시오. FLASHBACK TABLE … TO BEFORE DROP은 몇 초면 됩니다(진단 단계에서 확인).
• 삭제된 PDB 되살리기 (DROP PLUGGABLE DATABASE) — PDB가 DROP PLUGGABLE DATABASE로 삭제되었습니다. 파일이 남아 있으면 XML로 다시 plug in하고, 삭제되었으면 백업에서 되살립니다(21c+는 단일 명령, 19c는 임시 CDB를 통해). CDB는 열린 상태를 유지합니다.
• 다른 서버로 restore (새 호스트, controlfile autobackup에서) — 서버가 완전히 사라졌거나 사본/테스트 환경을 구축하려는 경우입니다. 백업을 다른 서버로 restore합니다(단일 인스턴스, 파일 시스템만 해당). 백업된 마지막 아카이브 로그까지 복구되며 그 이후는 손실됩니다. 사본은 RESETLOGS로 엽니다.
• Data Guard: standby/primary에서 네트워크로 파일 가져오기 (FROM SERVICE) — Data Guard 환경입니다. primary의 손실된 datafile은 standby에서, 뒤처진 standby나 손실된 standby controlfile은 primary에서 백업 piece 없이 가져옵니다(12c+).

시작하기 전에

• 사건을 기록하고 애플리케이션 팀에 알렸습니다: 언제, 무슨 일이, 어떤 오류 메시지로. 복구를 시작하기 전에 현재 상태의 사본을 만들 수 있으면 만들었습니다(서버/디스크 snapshot 또는 최소한 남은 datafile, controlfile, online redo log의 사본). 잘못된 단계는 상황을 더 악화시킬 수 있습니다.
• 백업에 접근할 수 있습니다(마운트되어 읽기 가능): …… 및 아카이브 로그용 FRA ……. 백업이 테이프/MML에 있으면 SBT 채널과 소프트웨어 에이전트가 동작 중입니다.
• DBID를 알고 있습니다(…). 모르면: 이전 RMAN 로그의 connected to target database: … (DBID=…) 행… 또는 autobackup 파일 이름(…_cf_c-<DBID>-<YYYYMMDD>-<nn>)….
• Auxiliary 디렉터리 …가 있고 SYSTEM + SYSAUX + UNDO + 테이블의 tablespace만큼 여유 공간이 있습니다. 서버에는 임시 인스턴스용 여유 RAM이 약 2 GB 있습니다.
• …RECOVER TABLE("Recovering tables and table partitions from RMAN backups")은 Enterprise Edition 기능입니다.…Standard Edition 2에는 RECOVER TABLE이 없습니다. 아래 단계 대신 백업을 다른 서버로 restore하고("다른 서버로 restore" + PITR) Data Pump로 테이블을 추출하십시오.…
• 대상 서버에 동일한 Oracle 버전과 동일한 RU 수준이 소프트웨어만 설치되어 있고(opatch lspatches 결과가 양쪽 동일), oracle 사용자/그룹과 디렉터리 구조가 소스와 같으며 디스크가 충분합니다. 대상에 같은 이름으로 실행 중인 데이터베이스가 없습니다.
• 유지보수/중단 작업 시간이 승인되었습니다… (이 시나리오에서는 데이터베이스가 열린 상태를 유지하며 관련 객체만 영향을 받음)…. 백업 스케줄러(cron/systemd/scheduler)를 복구가 끝날 때까지 중지했습니다. 그렇지 않으면 작업 도중에 백업이나 DELETE OBSOLETE가 실행될 수 있습니다.
• Clusterware 등록 정보를 확인했습니다: spfile과 비밀번호 파일의 위치, …인스턴스와 노드…데이터베이스 상태…(srvctl config database -db …). 복구 전에 이 출력을 보관하십시오.
• …Block media recovery…Tablespace point-in-time recovery…Flashback Database…는 Enterprise Edition 기능이며 Standard Edition 2에서는 명령이 동작하지 않습니다. 이 시나리오의 SE2 경로는 단계에서 따로 안내합니다.
• 임시(auxiliary) 인스턴스를 위해 …………… 디렉터리에 SYSTEM + SYSAUX + UNDO… + …… + PDB…만큼의 여유 공간이 있고, 서버에는 최소한 대상의 sga_target만큼 여유 메모리가 있습니다(RMAN은 기본적으로 임시 인스턴스에 같은 SGA를 할당).
• Data Guard 준비 완료: 양쪽의 비밀번호 파일이 같고(SYS 또는 SYSBACKUP 비밀번호 동일), 이 서버의 tnsnames.ora에 … 및 … 항목이 있으며, COMPATIBLE ≥ 12.0입니다. FROM SERVICE는 운영체제 인증(rman target /)으로는 동작하지 않으며, RMAN은 비밀번호로 접속합니다.
• Flashback Database를 위해 FRA가 정의되어 있고, flashback logging이 활성화되어 있거나(FLASHBACK_ON = YES) 대상 시점이 guaranteed restore point입니다. 손실/손상된 datafile이 없고(flashback은 손실된 파일을 되살리지 않음), 대상 시점 이후에 datafile을 축소(shrink)하거나 controlfile을 재생성하지 않았습니다.

가이드 단계

• 상태 확인 — 상태 확인 · 상태 확인 · Recyclebin 확인 (DROP이었다면 백업이 필요 없을 수 있음) · 대상 시점 결정
• 필요한 백업이 있습니까? — 인스턴스를 MOUNT 모드로 시작 · 인스턴스를 MOUNT 모드로 시작 (srvctl) · 백업 목록 확인 · Autobackup 파일 찾기 · 복구 미리 보기 (PREVIEW) · 백업 piece 읽기 및 검증 (VALIDATE) …
• Datafile / tablespace 복구 (online) — … offline 전환 · … restore 및 recover · … online 전환
• 전체 restore (동일 서버) — 데이터베이스 restore, recover 및 open · …클러스터 모드로 복귀하고 Clusterware로 데이터베이스 시작…Clusterware(Oracle Restart)로 데이터베이스 재시작…
• 시점 / SCN 복구 (PITR) — 복구 전에 현재 상태 백업 · 데이터베이스를 단일 인스턴스 MOUNT로 전환 (srvctl) · …PDB…데이터베이스…를 대상 시점으로 되돌리기 · …클러스터 모드로 복귀하고 Clusterware로 데이터베이스 시작…Clusterware(Oracle Restart)로 데이터베이스 재시작…
• 단일 테이블 복구 (RECOVER TABLE) — Auxiliary 디렉터리 준비 · 대상 시점에서 테이블 복구 · 복구된 데이터 비교
• Controlfile 복구 — 남아 있는 controlfile 사본 확인 · 남아 있는 controlfile 사본 확인 (ASM) · 인스턴스를 NOMOUNT로 시작 (srvctl) · autobackup에서 controlfile restore 후 open · …클러스터 모드로 복귀하고 Clusterware로 데이터베이스 시작…Clusterware(Oracle Restart)로 데이터베이스 재시작…
• spfile 복구 — 메모리의 파라미터로 spfile 다시 쓰기 · 메모리의 파라미터로 spfile을 ASM에 쓰기 · autobackup에서 spfile restore · autobackup에서 spfile을 ASM으로 restore · 인스턴스가 spfile로 시작되었는지 확인
• 소스 서버: 정보 수집 및 백업 전송 — 최신 백업 수행 · DBID, autobackup 및 디렉터리 목록 기록 · 백업과 비밀번호 파일을 대상으로 복사
• 대상 서버: restore 및 recovery — 디렉터리 생성 · oratab 항목 추가 · spfile과 controlfile restore 후 MOUNT · 백업 piece 등록 (CATALOG) · restore, 마지막 아카이브 로그까지 recover 후 open · 사본을 소스와 분리 (선택 사항)
• 진단: RMAN이 백업을 찾지 못하는 이유 — 백업 piece의 새 위치 확인 · RMAN이 알고 있는 백업과 누락된 백업 나열
• 안전장치 — controlfile의 현재 상태 복사
• 백업을 RMAN에 등록 — 새 디렉터리의 piece 등록 (CATALOG START WITH) · 이전 위치의 기록 정리
• 검증: 이제 백업을 찾을 수 있습니까? — 복구 다시 미리 보기 · 백업 스크립트를 새 위치에 맞게 수정
• 진단: 어떤 아카이브 로그가 필요하며 백업에 있습니까? — 아카이브 로그가 디스크에 있는지 확인 · 아카이브 로그 백업 찾기 및 미리 보기
• 안전장치: 대상 디렉터리와 공간 — Restore 디렉터리 준비
• 아카이브 로그 restore — 아카이브 로그 restore (RESTORE ARCHIVELOG)
• 검증 및 정리 — restore된 아카이브 로그 나열 · 작업이 끝나면 restore된 아카이브 로그 삭제
• 진단: 손상 블록입니까? — 파일 검사 (VALIDATE) · 손상 블록과 해당 객체 나열
• 안전장치: 정상 사본과 아카이브 체인이 있습니까? — 파일의 백업과 복구 체인 미리 보기
• 손상 블록 복구 — 백업에서 손상 블록 복구 (RECOVER CORRUPTION LIST) · Standard Edition 2: datafile restore · NOLOGGING 블록 수정 (있는 경우)
• 검증: 블록이 정상입니까? — 파일 다시 검사 · 근본 원인 조사: 디스크 및 스토리지 오류
• 진단: 파일이 SYSTEM 또는 UNDO입니까? — 인스턴스를 MOUNT 모드로 시작 · 인스턴스를 MOUNT 모드로 시작 (srvctl) · 파일이 SYSTEM 또는 UNDO인지 확인 · 필요한 백업 미리 보기 및 검증
• 안전장치 — controlfile의 현재 상태 복사
• SYSTEM / UNDO datafile restore — PDB 닫기 · Datafile restore, recover 및 open · …클러스터 모드로 복귀하고 Clusterware로 데이터베이스 시작…Clusterware(Oracle Restart)로 데이터베이스 재시작…
• 진단: 손실된 파일이 tempfile입니까? — Tempfile과 상태 확인 · 파일과 alert log 확인
• 안전장치: 공간 확인 — 새 tempfile을 위한 공간 확인
• 새 tempfile 추가, 손실된 파일 제거 — 새 tempfile 추가 및 손실된 파일 제거
• 검증 — Temp tablespace 검증
• 진단: 어떤 그룹이 어떤 상태입니까? — Redo log 그룹 상태 확인