CDB 전체와 PDB 단위 복구

#핵심 요약

CDB 전체는 루트에 접속해 BACKUP DATABASE PLUS ARCHIVELOG로 백업하고, 장애 때 RESTORE DATABASE, RECOVER DATABASE로 복구함

컨트롤 파일과 리두 로그가 살아 있으면 모든 데이터 파일을 잃어도 완전 복구이므로 RESETLOGS가 필요 없음

PDB 하나는 BACKUP PLUGGABLE DATABASE <PDB>로 백업하거나 PDB에 직접 접속해 BACKUP DATABASE로 백업함

PDB 복구는 루트에 접속해 RESTORE PLUGGABLE DATABASE, RECOVER PLUGGABLE DATABASE로 함
여러 PDB를 한 번에 복구할 수도 있음

#개념과 동작 원리

CDB 전체 백업(BACKUP DATABASE)에는 CDB$ROOT, PDB$SEED, 모든 사용자 PDB의 데이터 파일이 한 번에 들어감
PLUS ARCHIVELOG를 붙이면 복구에 필요한 아카이브 로그도 함께 백업되고, 컨트롤 파일 자동 백업이 켜져 있으면 컨트롤 파일과 SPFILE도 따라옴

공용 파일이 손상되면 모든 PDB가 한꺼번에 멈추고, PDB에 접속한 RMAN으로는 복구할 수 없어 루트에서 CDB 단위로 복구함
공용 리두를 잃어 CDB 전체를 과거로 돌리면 아무 잘못 없는 PDB까지 함께 과거로 돌아감

설명: 임시 파일이 함께 지워져도 열 때 자동으로 다시 만들어짐

설명: CDB를 연 뒤 PDB가 MOUNTED로 남아 있으면 SAVE STATE를 하지 않은 것이므로 직접 엶
공식 문서도 CDB를 열 때 PDB가 자동으로 열리지 않으며 ALTER PLUGGABLE DATABASE ALL OPEN으로 연다고 적음(Flashback Database 절)

#필수 명령어 또는 SQL

#CDB 상태와 RMAN 설정 확인

SELECT name, cdb, open_mode, log_mode FROM v$database;
SHOW PDBS
ARCHIVE LOG LIST
SHOW PARAMETER db_recovery_file_dest
SELECT file_type, percent_space_used FROM v$recovery_area_usage;

SHOW ALL;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;

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

#CDB 전체 백업과 복구

REPORT SCHEMA;
BACKUP DATABASE PLUS ARCHIVELOG;
LIST BACKUP SUMMARY;
LIST BACKUP OF PLUGGABLE DATABASE <PDB_NAME>;
REPORT NEED BACKUP;

결과 해석:

실습에서는 루트, 시드, PDB의 데이터 파일을 모두 지우고 컨트롤 파일과 리두 로그는 남긴 뒤 STARTUP으로 장애를 확인했음

RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN;

SHOW PDBS

결과 해석:

실습 기록: 복구 뒤 PDB$SEED는 READ ONLY, PDB1은 READ WRITE였음

#PDB만 백업

SHOW PDBS
SELECT file#, name FROM v$datafile WHERE con_id = <CON_ID>;

BACKUP PLUGGABLE DATABASE <PDB_NAME> PLUS ARCHIVELOG;
LIST BACKUP OF PLUGGABLE DATABASE <PDB_NAME>;

rman target sys@<PDB_SERVICE>

BACKUP DATABASE;
BACKUP ARCHIVELOG ALL;

결과 해석:

아카이브 로그, 컨트롤 파일, SPFILE은 CDB 전체가 함께 쓰는 자원이라 PDB에 접속한 RMAN으로는 백업할 수 없다고 수업 자료는 설명함
그래서 운영에서는 루트에서 백업하고, PDB 접속 백업은 그 PDB 담당자가 자기 PDB만 다룰 때 씀
PDB 일반 데이터 파일 장애와 PDB SYSTEM 파일 장애는 모두 완전 복구라 RESETLOGS가 필요 없고, 루트와 다른 PDB는 계속 서비스됨

#PDB의 일반 데이터 파일 복구 (PDB 접속)

ALTER DATABASE DATAFILE <FILE_NO> OFFLINE;
RESTORE DATAFILE <FILE_NO>;
RECOVER DATAFILE <FILE_NO>;
ALTER DATABASE DATAFILE <FILE_NO> ONLINE;

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

#PDB의 SYSTEM 파일 복구 (루트 접속)

ALTER PLUGGABLE DATABASE <PDB_NAME> CLOSE ABORT;

결과 해석:

실습에서는 PDB를 CLOSE ABORT로 닫고 SYSTEM 데이터 파일을 지운 뒤 PDB 열기가 실패하는 것을 확인했음

RESTORE PLUGGABLE DATABASE <PDB_NAME>;
RECOVER PLUGGABLE DATABASE <PDB_NAME>;
ALTER PLUGGABLE DATABASE <PDB_NAME> OPEN;

결과 해석:

실습의 CDB 복구 실습 끝에는 RESTORE DATABASE pdb1; 뒤 RECOVER PLUGGABLE DATABASE pdb1;이 적혀 있음
복원 명령에 PLUGGABLE이 빠진 것으로 보여 위 블록은 공식 문서 형식으로 적었음

#컨트롤 파일을 모두 잃었을 때 (CDB)

컨트롤 파일은 루트와 모든 PDB가 함께 쓰는 공용 파일이라, PDB 파일을 하나도 지우지 않아도 컨트롤 파일이 없으면 PDB도 멈춤
이때 PDB 서비스로는 접속도, RMAN 접속도 되지 않으며 복구는 루트에서만 할 수 있음

SELECT name FROM v$controlfile;

COL member FOR A40
SELECT l.group#, l.sequence#, l.status, f.member
  FROM v$log l, v$logfile f
 WHERE l.group# = f.group#
 ORDER BY 1;

SHOW CONTROLFILE AUTOBACKUP;      -- ON인지 확인
BACKUP DATABASE PLUS ARCHIVELOG;

결과 해석:

장애 전에 SELECT dbid, name FROM v$database;로 DBID를 적어 둠
실습에서는 SHUTDOWN IMMEDIATE 뒤 컨트롤 파일 두 개를 운영체제에서 지우고 STARTUP으로 장애를 확인했음

RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
BACKUP DATABASE PLUS ARCHIVELOG;   -- RESETLOGS 뒤 새 전체 백업

결과 해석: 백업 컨트롤 파일로 열었으므로 RESETLOGS가 필요함
열린 뒤 SHOW PDBS로 PDB 상태를 확인하고, 로그 순서가 새로 시작되므로 바로 전체 백업을 받음

#CURRENT 리두 그룹을 잃었을 때 (CDB 전체 불완전 복구)

리두 로그도 공용 파일이라 CURRENT 그룹을 잃으면 PDB 하나만 되돌릴 수 없고 CDB 전체를 같은 시점으로 되돌림

ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM CHECKPOINT;
SELECT group#, sequence#, status, archived FROM v$log;   -- CURRENT 그룹 번호와 시퀀스를 적어 둠

결과 해석:

실습에서는 시퀀스를 적은 뒤 루트와 PDB에 행을 하나씩 더 넣어 CURRENT 리두에만 기록되게 하고, SHUTDOWN ABORT 뒤 CURRENT 그룹의 멤버를 모두 지웠음
STARTUP은 MOUNT까지 가서 ORA-00313(그룹 멤버 열기 실패)으로 멈췄음

RUN {
  SET UNTIL SEQUENCE <SEQ> THREAD 1;
  RESTORE DATABASE;
  RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;
BACKUP DATABASE PLUS ARCHIVELOG;

바꿀 입력값: <SEQ>는 적어 둔 CURRENT 시퀀스 번호, 그 직전까지 복구함

결과 해석: 실습 기록에서 루트와 PDB 모두 CURRENT 리두에만 있던 행이 사라졌고, ARCHIVE LOG LIST의 시퀀스가 1로 돌아갔음(CDB 전체 RESETLOGS)

#PDB UNDO와 루트 UNDO 복구

19c 로컬 UNDO 모드에서는 PDB마다 자기 UNDO 테이블스페이스를 가짐
LOCAL_UNDO_ENABLED가 FALSE이면 공유 UNDO 모드라 PDB에 UNDO 파일이 없음

SELECT property_value
  FROM database_properties
 WHERE property_name = 'LOCAL_UNDO_ENABLED';

COL name FOR A55
SELECT con_id, file#, name FROM v$datafile
 WHERE name LIKE '%undo%' ORDER BY con_id;

결과 해석:

PDB UNDO 손상: 실습에서는 ALTER PLUGGABLE DATABASE <PDB_NAME> CLOSE ABORT로 정리되지 않은 트랜잭션이 남은 상태를 만들고 그 PDB의 UNDO 파일을 지웠음
PDB 열기는 ORA-01157, ORA-01110으로 실패했지만 루트는 READ WRITE로 계속 서비스했음

RESTORE DATAFILE <PDB_UNDO_FILE_NO>;
RECOVER DATAFILE <PDB_UNDO_FILE_NO>;
ALTER PLUGGABLE DATABASE <PDB_NAME> OPEN;

결과 해석:

루트 UNDO 손상: 루트 UNDO는 CDB가 열리는 데 반드시 필요해서 오프라인으로 내려 두고 먼저 여는 방법을 쓸 수 없음
STARTUP은 MOUNT까지만 가고 ORA-01157로 멈추며 PDB도 열 수 없음

SELECT * FROM v$recover_file WHERE error = 'FILE NOT FOUND';

RESTORE DATAFILE <ROOT_UNDO_FILE_NO>;
RECOVER DATAFILE <ROOT_UNDO_FILE_NO>;
ALTER DATABASE OPEN;

결과 해석: 두 경우 모두 완전 복구라 RESETLOGS가 필요 없음
non-CDB였다면 UNDO 파일 하나로 DB 전체가 멈췄을 장애가, 로컬 UNDO 모드에서는 그 PDB만 멈추고 끝남

#PDB$SEED 손상 복구

PDB$SEED는 READ ONLY라 파일이 손상돼도 SHOW PDBS에 그대로 READ ONLY로 보이고 다른 PDB도 정상임
새 PDB를 만들 때 비로소 실패해서 모니터링에서 놓치기 쉬움
시드는 BACKUP DATABASE에 포함되므로 CDB 전체 백업이 곧 시드 백업임

SELECT file#, name FROM v$datafile WHERE con_id = 2;

LIST BACKUP OF PLUGGABLE DATABASE "PDB$SEED";

결과 해석:

실습에서는 시드의 SYSTEM 파일을 지운 뒤 CREATE PLUGGABLE DATABASE ... FILE_NAME_CONVERT가 실패하는 것을 확인하고, 반쯤 만들어진 새 PDB 디렉터리를 지웠음

SHUTDOWN IMMEDIATE
STARTUP MOUNT

RESTORE PLUGGABLE DATABASE "PDB$SEED";
RECOVER PLUGGABLE DATABASE "PDB$SEED";
ALTER DATABASE OPEN;

"PDB$SEED"는 큰따옴표로 감쌈

시드 파일이 없어 SHUTDOWN IMMEDIATE가 오류로 멈추면 SHUTDOWN ABORT 뒤 STARTUP MOUNT로 진행함
이 경우 열 때 인스턴스 복구가 자동으로 됨

파일 하나만 잃었으면 RESTORE DATAFILE <FILE_NO>, RECOVER DATAFILE <FILE_NO>로 해도 됨

결과 해석: 복구 뒤 새 PDB 생성이 성공하면 시드가 정상으로 돌아온 것임

#RAC에서 PDB 하나만 복원

BACKUP PLUGGABLE DATABASE <PDB_NAME> PLUS ARCHIVELOG;
LIST BACKUP OF PLUGGABLE DATABASE <PDB_NAME> SUMMARY;
REPORT SCHEMA;

ALTER PLUGGABLE DATABASE <PDB_NAME> CLOSE IMMEDIATE INSTANCES = ALL;
SELECT inst_id, name, open_mode FROM gv$pdbs WHERE name = '<PDB_NAME>';

SELECT r.file#, r.error, d.con_id, d.name
  FROM v$recover_file r, v$datafile d
 WHERE r.file# = d.file#;

RESTORE PLUGGABLE DATABASE <PDB_NAME>;
RECOVER PLUGGABLE DATABASE <PDB_NAME>;
ALTER PLUGGABLE DATABASE <PDB_NAME> OPEN INSTANCES = ALL;

결과 해석:

BACKUP PLUGGABLE DATABASE는 그 PDB 소속 데이터 파일만 담고(CDB$ROOT, PDB$SEED 제외), PLUS ARCHIVELOG는 모든 thread의 아카이브를 함께 백업함
FILE_ID는 PDB 안이 아니라 CDB 전체에서 유일한 번호임

데이터 파일은 모든 인스턴스가 공유하므로 한 노드에서만 닫으면 다른 노드가 계속 쓰고, 한 노드라도 열려 있으면 복원이 거부됨
CLOSE ... INSTANCES = ALL로 모든 노드에서 MOUNTED로 만든 뒤 복원함

실습 기록: PDB의 OMF 데이터 파일(+DATA/<DB_NAME>/<PDB_GUID>/DATAFILE/...)을 asmcmd로 지운 뒤 OPEN INSTANCES = ALL은 ORA-01157, ORA-01110으로 실패했고, V$RECOVER_FILE에 FILE NOT FOUND와 CON_ID 3이 나왔음
복원, 복구 뒤 두 노드 모두에서 테스트 테이블 1,000건이 보였고, CDB 루트와 다른 PDB는 내내 열려 있었음

연습 문제: 2번 노드에서만 작업해 다른 PDB를 멈추지 않고, 백업 뒤 양쪽 노드에서 넣은 주문까지 잃지 않게 PDB 하나를 복구함(두 thread의 아카이브를 모두 적용하면 백업 500건 + 양쪽 2건 = 502건)

#연습 문제

1. PDB에 UNDO 테이블스페이스를 100M로 만들고 그 PDB의 기본 UNDO 테이블스페이스로 지정함
   RMAN으로 그 PDB를 백업하고 UNDO 데이터 파일을 운영체제에서 지운 뒤, 루트는 내리지 않고 그 PDB만 복구해 엶
2. CDB 전체 백업을 받고 PDB$SEED의 SYSAUX 데이터 파일 번호와 경로를 확인함
   그 파일을 지운 뒤 아무 증상이 없는 것과 새 PDB 생성이 실패하는 것을 확인하고, 시드를 데이터 파일 단위로 복구한 뒤 새 PDB가 만들어지는지 확인함

#사용 조건과 주의사항

PDB 복구 동안 다른 PDB와 CDB는 계속 열어 둘 수 있음

실습에서는 PDB 접속 RMAN 문자열에 비밀번호를 적었음
위 블록은 비밀번호를 프롬프트로 받음

PDB 시점 복구와 테이블스페이스 시점 복구는 PDB 시점 복구와 TSPITR에 있음