[Oracle] 복구 시 open / recover database / recover database using backup controlfile until cancel 차이

1. MOUNT 상태에서 ALTER DATABASE OPEN만으로 바로 OPEN 될 때

상황 요약

• 데이터파일과 컨트롤파일의 SCN이 모두 일관성(consistency)을 유지하고 있음
• 또는, 모든 데이터파일의 SCN이 컨트롤파일의 Checkpoint SCN보다 미세하게 큰 경우
• 복구가 필요 없는 경우

내부 메커니즘

1) Oracle이 MOUNT 단계에서 컨트롤파일을 읽고 각 데이터파일 헤더의 SCN을 확인

컨트롤 파일 내부 정보(예시)

CONTROL FILE RECORD SECTION
  # Datafiles
  file# | name                     | checkpoint scn
  ------+--------------------------+----------------
  1     | /u01/oradata/system.dbf  | 1234567
  2     | /u01/oradata/sysaux.dbf  | 1234567
  3     | /u01/oradata/users.dbf   | 1234567

각 데이터파일 헤더 블록 정보(예시)

Datafile header
  Checkpoint SCN : 1234567
  Resetlogs ID   : 123456
  Tablespace#    : 1

→ 모든 데이터파일의 SCN이 컨트롤파일의 Checkpoint SCN과 동일하다면,
이미 모든 변경 사항이 반영되어 있다고 판단

바로 OPEN 됨

2) 단, 인스턴스 크래시 이후라면?

모든 데이터파일의 SCN이 컨트롤파일의 Checkpoint SCN보다 큰 경우가 됨

• 이 경우의 SCN 차이는 메모리에 있던 redo가 디스크로 flush되기 직전의 아주 미세한 차이
• 인스턴스가 비정상 종료되었거나 아직 checkpoint가 완전히 끝나지 않았을 때 발생
• instance recovery가 발생할 수 있음

미세한 차이기 때문에,

이때는 현재 redo log (online redo log) 만 적용하고, archive log는 사용되지 않음

3) Instance Recovery (SMON 자동 수행)

Crash 직후 재기동 시 open 시점에 redo log를 읽고 커밋되지 않은 트랜잭션 rollback
커밋된 트랜잭션의 redo 재적용(replay) 수행

2. RECOVER DATABASE 명령으로 복구될 때(컨트롤파일을 신뢰)

상황 요약

• 컨트롤파일과 데이터파일의 SCN 불일치 (부분적인 복구 필요)
• 컨트롤파일은 정상이며, 데이터파일만 옛날 시점으로 복사된 경우
• 주로 Hot Backup, Cold Backup 복원 이후 발생

내부 메커니즘

1) Oracle이 컨트롤파일의 checkpoint SCN과 각 데이터파일 헤더 SCN을 비교

→ 더 낮은 데이터파일에는 Archive/Redo log를 통해 SCN을 끌어올려야 함

2) RECOVER DATABASE 수행 시

Oracle은 컨트롤파일에 기록된 로그 시퀀스(sequence) 정보를 참고하여

필요한 Archive Log 파일 또는 Redo Log를 순차적으로 적용합니다.

Archive log 적용 → redo log 적용(필요 시)

 

Archive/Redo log 파일이 부족할 경우 아래 에러 메시지로 필요한 로그 알림

ORA-00279: Change xxx generated at ... needed for thread ...

3) 모든 데이터파일의 SCN이 컨트롤파일과 일치할 때까지 로그 적용 후

ALTER DATABASE OPEN 명령으로 open 가능

3. RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL 명령으로 복구될 때(컨트롤파일을 신뢰하지 못함)

상황 요약

• 컨트롤파일 자체가 손상되었거나 백업 컨트롤파일로 대체된 경우
• 백업 컨트롤파일의 로그 시퀀스 정보가 현재 Archive/Redo log 상태와 일치하지 않음
• 백업 컨트롤파일의 SCN이 옛날 시점. 각 데이터파일 헤더에 저장된 SCN이 더 앞서 있음
• 따라서 archive log의 범위를 수동으로 지정해야 함

내부 메커니즘

1) Oracle은 컨트롤파일을 신뢰하지 못함

백업 시점의 SCN과 로그 시퀀스 정보를 사용하므로, 컨트롤파일은 실제 데이터파일보다 뒤떨어진 checkpoint 정보를 가짐

 

컨트롤파일에 저장되는 정보

컨트롤파일에는 데이터베이스의 전체 상태 정보가 들어 있음

특히 Redo/Archive 로그 관련 부분에는 이런 정보들이 저장됨

정보 항목	의미
현재 redo log thread 번호	어떤 인스턴스의 로그를 사용 중인지
현재 redo log sequence 번호	지금 사용 중인 redo log의 시퀀스 번호
아카이브된 로그의 목록 (archive log history)	어떤 redo log 시퀀스가 이미 archive 되었는지
각 데이터파일의 마지막 checkpoint SCN	파일별 마지막 동기화 지점

로그 시퀀스 불일치

시점	Redo/Archive 상태	컨트롤파일 상태
T0 (백업 시점)	Redo Sequence = 100	컨트롤파일에 100까지 기록
T1 (이후 트랜잭션 발생)	Redo Sequence = 101, 102, 103 생성	컨트롤파일은 여전히 100까지만 알고 있음
T2 (장애 발생, 컨트롤파일 손상)	Redo Sequence = 104 사용 중	백업 컨트롤파일 복원 (T0 시점 상태)

이제 복구를 시도하면 이런 상황이 됨

• 데이터파일은 시퀀스 104 근처의 변경사항이 반영된 상태일 수도 있고,
• Archive 로그는 시퀀스 101~104까지 존재하지만,
• 컨트롤파일은 100까지만 알고 있어서 그 이후의 로그 파일 이름이나 경로를 모름

즉, 컨트롤파일 입장에서는

• "내가 알고 있는 마지막 로그는 100번인데… 갑자기 데이터파일 SCN이 더 높네?
• 내가 모르는 로그(101~104)가 어딘가에 있을 텐데…"
• 라는 불일치가 생김

만약 여기서 RECOVER DATABASE 명령을 수행한다면?

• Oracle은 컨트롤파일을 신뢰해서 복구를 수행
• 컨트롤파일에 "archive log sequence 100까지 있음"이 기록되어 있으므로,
• 그 이후의 로그(101~104)는 존재하지 않는 걸로 판단하고 복구 실패
  → ORA-01194, ORA-01152, ORA-01207 등의 오류가 발생

USING BACKUP CONTROLFILE 옵션의 의미

• "컨트롤파일이 오래되었을 수 있으니, 컨트롤파일의 archive log 정보를 신뢰하지 말고"
• "데이터파일의 실제 SCN을 기준으로 필요한 로그를 찾아보라"는 뜻

2) USING BACKUP CONTROLFILE 옵션을 주면 Oracle은

3) 데이터파일 헤더의 SCN을 확인

• "이 파일은 SCN 450000까지 되어있네. 그런데 컨트롤파일은 430000까지만 알고 있네?"

4) 필요한 로그를 직접 요청

ORA-00279: change 430001 generated at ... needed for thread 1

 

→ 즉, “SCN 430001부터 적용해야 하는 로그가 필요하다”고 알림

5) 관리자가 수동으로 archive/redo log를 공급

• 더 이상 적용할 로그가 없을 때 CANCEL을 입력

6) 이후 ALTER DATABASE OPEN RESETLOGS 로 새 로그 체계 시작

• 컨트롤파일 내 redo log sequence 번호를 재초기화(reset)