데이터파일과 블록 복구

#핵심 요약

블록 매체 복구는 데이터 파일 전체가 아니라 손상된 블록만 복원, 복구함
ARCHIVELOG 모드이고 현재 컨트롤 파일로 열려 있거나 MOUNT 상태여야 함

블록 복구에는 전체 또는 레벨 0 백업과 아카이브 로그만 씀
레벨 1 증분 백업은 쓰지 않고, 아카이브 로그가 하나라도 빠지면 실패함

19c 공식 문서의 명령은 RECOVER DATAFILE n BLOCK m임
실습에서는 예전 구문 BLOCKRECOVER를 썼음

데이터 파일 백업이 전혀 없어도 ARCHIVELOG 모드이고 파일 생성 이후의 아카이브 로그가 모두 있으면, ALTER DATABASE CREATE DATAFILE로 빈 파일을 만들고 RECOVER로 복구할 수 있음

#개념과 동작 원리

복구가 끝난 블록은 V$DATABASE_BLOCK_CORRUPTION에서 사라짐

RECOVER CORRUPTION LIST는 그 뷰에 기록된 손상 블록을 모두 복구함

백업본 없이 데이터 파일을 다시 만드는 방법: 장애 파일을 확인해 오프라인으로 바꾸고, CREATE DATAFILE ... AS...로 빈 파일을 만든 뒤 RECOVER DATAFILE로 아카이브 로그를 적용하고 온라인으로 올림

#필수 명령어 또는 SQL

#손상 블록 찾기

SELECT file_id, block_id, blocks FROM dba_extents WHERE segment_name = '<TABLE_NAME>';
SELECT * FROM v$database_block_corruption;

ALTER SYSTEM FLUSH SHARED_POOL;
ALTER SYSTEM FLUSH BUFFER_CACHE;

결과 해석:

실습에서는 다음 조회가 디스크에서 블록을 읽도록 메모리를 비웠음(선택)
운영 중인 DB에서 버퍼 캐시를 비우면 성능에 영향이 있음

dbv file=<DATAFILE_DIR>/<FILE_NAME>.dbf blocksize=8192

결과 해석:

dbv(DBVERIFY)는 데이터 파일의 블록을 검사해 손상 블록 번호를 보여 줌
실습에서는 복구 전후에 같은 명령으로 확인했음

#블록 복구

RECOVER DATAFILE <FILE_NO> BLOCK 128, 129, 130, 131;

결과 해석:

실습 명령:

BLOCKRECOVER DATAFILE <FILE_NO> BLOCK 128,129,130,131;

RECOVER CORRUPTION LIST;

결과 해석:

첫 블록은 현재 권장 구문임
Oracle Database 19c는 BLOCKRECOVER를 11.1.0부터 deprecated된 구문으로 분류하면서 하위 호환을 위해 계속 지원한다고 명시함
실습의 예전 구문이 지원되지 않는다는 뜻은 아니며 새 절차는 RECOVER ... BLOCK으로 구분함
실습에서는 손상 전에 BACKUP TABLESPACE로 그 테이블스페이스를 백업해 두었음

#백업본 없이 데이터 파일 다시 만들기

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

ALTER DATABASE CREATE DATAFILE '<DATAFILE_DIR>/<FILE_NAME>.dbf'
  AS '<DATAFILE_DIR>/<NEW_FILE_NAME>.dbf';

RECOVER DATAFILE <FILE_NO>;

결과 해석:

수업 이론의 순서: 테이블스페이스와 테이블을 만들고 데이터를 넣음, 로그 스위치로 아카이브 로그 생성, 운영체제에서 데이터 파일 삭제, STARTUP FORCE로 장애 확인, 장애 파일 확인 후 오프라인, CREATE DATAFILE ... AS, RECOVER DATAFILE, 온라인 후 데이터 검증
실습 블록에는 오프라인과 온라인 단계가 빠져 있음

#RMAN 없이 블록 손상 복구 (사용자 관리 방식)

블록 손상은 현장에서 자주 나는 장애 유형이며, 원인 파악보다 신속한 복구가 우선이라고 실습 자료는 적었음
원인으로는 운영체제 I/O 처리 중 블록 오염, Oracle 엔진 버그로 인한 블록 헤더 손상, 대량 DML 중 비정상 종료가 꼽힘

RMAN 블록 복구는 손상 블록만 고치지만, 사용자 관리 방식은 그 데이터 파일 전체를 핫 백업본으로 바꾼 뒤 아카이브 로그를 적용함
RMAN 이미지 카피도 같은 cp와 RECOVER 방식으로 복구할 수 있음

ALTER TABLESPACE <TABLESPACE_NAME> BEGIN BACKUP;
SELECT * FROM v$backup;          -- 대상 파일이 ACTIVE
HOST cp <DATAFILE_DIR>/<FILE_NAME>.dbf <BACKUP_DIR>/<FILE_NAME>.dbf_backup
ALTER TABLESPACE <TABLESPACE_NAME> END BACKUP;
SELECT * FROM v$backup;          -- NOT ACTIVE로 돌아옴

ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM CHECKPOINT;

결과 해석:

실습에서는 이 뒤에 테이블을 만들고 교육용 스크립트로 블록을 손상시킨 다음, ALTER SYSTEM FLUSH BUFFER_CACHE로 캐시를 비워 실제 손상 블록을 읽게 했음
조회에서 ORA-01578과 alert log 기록을, dbv에서 손상 블록 번호를 확인했음

ALTER TABLESPACE <TABLESPACE_NAME> OFFLINE;

cp <BACKUP_DIR>/<FILE_NAME>.dbf_backup <DATAFILE_DIR>/<FILE_NAME>.dbf

RECOVER DATAFILE <FILE_NO>;
ALTER TABLESPACE <TABLESPACE_NAME> ONLINE;

결과 해석: 온라인으로 올린 뒤 같은 테이블을 다시 조회해 오류 없이 나오면 복구된 것임
오프라인 동안 그 테이블스페이스의 데이터는 쓸 수 없음

#백업이 없는 인덱스 테이블스페이스 복구

인덱스 전용 테이블스페이스를 백업하지 않은 채 데이터 파일이 손상되거나 지워졌을 때 씀
인덱스는 다시 만들 수 있는 객체이므로, 테이블스페이스를 새로 만든 뒤 미리 저장해 둔 인덱스 생성 DDL로 다시 만듦
그래서 인덱스 DDL 스크립트를 평소에 받아 두는 것이 사실상의 백업임

ALTER DATABASE DATAFILE <FILE_NO> OFFLINE;
DROP TABLESPACE <INDEX_TABLESPACE> INCLUDING CONTENTS AND DATAFILES;
CREATE TABLESPACE <INDEX_TABLESPACE>
  DATAFILE '<DATAFILE_DIR>/<FILE_NAME>.dbf' SIZE <SIZE>;

결과 해석:

그 다음 저장해 둔 인덱스 생성 스크립트를 실행함
빨리 만들려고 DDL에 PARALLEL 8처럼 병렬도를 붙였다면, 다 만든 뒤 ALTER INDEX <INDEX_NAME> PARALLEL 1로 되돌림

이 방법은 인덱스만 든 테이블스페이스에만 씀
테이블이 섞여 있으면 DROP TABLESPACE ... INCLUDING CONTENTS가 테이블 데이터까지 지움

백업이 있으면 일반 데이터 파일처럼 RESTORE DATAFILE, RECOVER DATAFILE로 복구함

#사용 조건과 주의사항

백업 없이 다시 만드는 방법은 파일이 만들어진 뒤의 아카이브 로그가 모두 있어야 함
하나라도 없으면 쓸 수 없음