리두 로그 장애 처리

#핵심 요약

온라인 리두 로그는 백업 대상이 아니라 다중화로 보호함

멤버 하나만 사라졌으면 같은 그룹의 정상 멤버를 복사해 되살림

INACTIVE 그룹의 멤버가 모두 사라졌으면 MOUNT 상태에서 그 그룹을 삭제하고 다시 만듦
그룹 삭제는 INACTIVE 그룹만 되고, 인스턴스에는 그룹이 최소 두 개 있어야 함

CURRENT 그룹을 잃으면 그 안의 커밋된 변경을 되살릴 수 없어 백업으로 불완전 복구한 뒤 RESETLOGS로 엶

#개념과 동작 원리

리두 로그 그룹을 삭제하려면 ALTER DATABASE 시스템 권한이 필요함

인스턴스에는 멤버 수와 관계없이 그룹이 최소 두 개 있어야 함

그룹은 INACTIVE일 때만 삭제할 수 있음
CURRENT 그룹을 지워야 하면 먼저 로그 스위치를 일으킴
아카이브가 켜져 있으면 삭제 전에 그 그룹이 아카이브됐는지 확인함

OMF가 아니면 그룹이나 멤버를 삭제해도 운영체제 파일은 지워지지 않고 컨트롤 파일에서만 빠짐

ALTER DATABASE CLEAR LOGFILE은 그룹이 두 개뿐이거나 손상된 로그가 CURRENT 그룹에 속해 삭제할 수 없는 경우를 해결함
아카이브되지 않은 로그면 UNARCHIVED를 붙임
백업 복구에 필요한 로그를 지우면 그 백업으로는 더 이상 복구할 수 없음

리두 로그 파일은 따로 백업하지 않음
ARCHIVELOG 모드면 아카이브 프로세스가 리두 로그를 아카이브 로그로 자동 보관하기 때문이고, DBA는 그룹마다 멤버를 여러 개 두어 다중화해 둠

상태는 UNUSED, CURRENT, ACTIVE, INACTIVE 순서로 바뀜

#필수 명령어 또는 SQL

#그룹과 멤버 확인

SELECT group#, status, sequence#, members FROM v$log;
SELECT group#, member FROM v$logfile ORDER BY group#;

ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM CHECKPOINT;

결과 해석:

실습 기록 예: 그룹 3개, 그룹마다 멤버 2개, 그룹 1, 2는 INACTIVE, 그룹 3은 CURRENT였음
실습 대상 그룹을 INACTIVE로 만들려고 로그 스위치와 체크포인트를 했음

#INACTIVE 그룹의 멤버 하나가 사라졌을 때

cp <REDO_DIR>/redo01a.log <REDO_DIR>/redo01b.log

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

#INACTIVE 그룹의 멤버가 모두 사라졌을 때

실습 기록: 멤버 두 개를 지운 뒤 STARTUP하자 경고 로그에 ORA-00313, ORA-00312가 남았음
경고 로그 문구는 log group 1인데 함께 나온 멤버는 그룹 3의 파일이었음

STARTUP MOUNT;
ALTER DATABASE DROP LOGFILE GROUP 3;
ALTER DATABASE OPEN;

ALTER DATABASE ADD LOGFILE GROUP 3
  ('<REDO_DIR>/redo03a.log', '<REDO_DIR>/redo03b.log') SIZE 50M;

ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM CHECKPOINT;

결과 해석:

그룹의 멤버 구성을 바꿀 때도 INACTIVE 그룹을 지우고 멤버를 지정해 다시 만듦(CURRENT 그룹은 지울 수 없음)

SELECT group#, members, status, sequence# FROM v$log;
COL member FOR A45
SELECT group#, member FROM v$logfile;

ALTER DATABASE DROP LOGFILE GROUP <GROUP_NO>;
ALTER DATABASE ADD LOGFILE GROUP <GROUP_NO>
  ('<REDO_DIR>/redo<GROUP_NO>a.log', '<REDO_DIR>/redo<GROUP_NO>b.log') SIZE 100M;

결과 해석:

ASM 환경 실습에서는 ALTER DATABASE ADD LOGFILE GROUP 1;처럼 경로 없이 다시 만들었음
OMF 위치에 자동으로 만들어지는 것으로 보이나 설명은 기재 없음

#CURRENT 그룹이 사라졌을 때

BACKUP DATABASE;

결과 해석:

실습에서는 장애 재현 전에 전체 백업을 먼저 받았음

RUN {
  SET UNTIL SEQUENCE <CURRENT_SEQ> THREAD 1;
  RESTORE DATABASE;
  RECOVER DATABASE;
}

ALTER DATABASE OPEN RESETLOGS;

BACKUP DATABASE;

결과 해석:

실습에서는 CURRENT 그룹의 시퀀스가 3일 때 SET UNTIL SEQUENCE 3을 써서 시퀀스 2까지 복구했음
실습 제목은 "cancel base 불완전 복구"지만 실제 명령은 시퀀스 기준임
이 복구로 CURRENT 로그에만 있던 커밋은 잃음

#사용 조건과 주의사항

수업 자료에는 지울 때 INACTIVE였던 그룹이 MOUNT 때 CURRENT로 바뀐 경우, 숨은 파라미터 _allow_resetlogs_corruption을 켜고 RECOVER DATABASE UNTIL CANCEL 뒤 강제로 OPEN RESETLOGS하는 절차가 있음
공식 문서에 없는 숨은 파라미터이고 데이터 일관성을 보장하지 않는 강제 열기라 이 글에는 명령으로 싣지 않음

손상된 로그를 지울 수 없는 경우의 공식 대안은 CLEAR LOGFILE임
수업 자료에는 이 명령의 실습이 없음