복구

• 복구 시 적용되는 리두 양을 최소화 하기위해
  • 로그파일 스위치 체크포인트, incremental 체크포인트, BWR (block written records) 사용.
• 로그파일 스위치 체크포인트 (media recovery checkpoint) 시, 모든 데이터파일 헤더의 SCN을 체크포인트 시작지점의 SCN으로 변경.
  (새로운 로그파일의 첫 번째 SCN )
  
  Note _defer_log_boundary_ckpt , _defer_log_count : 추가적인 몇 번의 로그스위치 발생할 때 까지 로그파일 스위치 체크포인트 발생을 지연시킨다.

• 데이터파일 헤더, 로그파일 헤더의 lowest SCN 기록 -> 복구를 위한 로그파일을 즉시 확인.
• 컨트롤파일 내의 마지막 incremental SCN, RBA 저장 -> 복구 시작할 로그파일 내 정확한 위치 확인 가능.

• 2단계로 리두 적용한다.
  1. last change SCN 저장하는 BWR(block written records)를 검색하여 각 블록의 highest change SCN을 확인한다.
  2. highest change SCN 보다 작은 SCN을 갖는 체인지 벡터는 복구 대상에서 제외.

• 복구 시 작업 최소화를 위해 세 개의 매커니즘이 함께 동작
  • 로그파일 스위치 체크포인트 / incremental 체크포인트 / BWR
• 복구 시에 체인지 벡터를 적용하기 위한 별도의 코드가 필요하지 않다.
• (일반적인 작업)
  1. 리두벡터 생성
  2. 로그 버퍼에 저장
  3. 데이터 블록에 적용
• (복구 시 작업)
  1. 파일 로 부터 리두벡터를 읽어들이고
  2. 데이터 블록에 적용.

미디어 복구

• 인스턴스 복구 와 미디어 복구 의 차이점 ?
  • 데이터파일 백업 / 온라인 리두로그 파일 모두 보관하고 있다면 사실상 차이가 없다.
  • 완벽한 복구는 데이터파일 백업 시점 이후의 모든 아카이브 로그 파일이 필요함.
  • 버전에 따라 백업 이후에 추가된 데이터파일 처리 방식이 다르나, 원칙과 매커니즘은 동일하다.
  • 아카이브 프로세스는 로그 스위치 발생 시 I/O 발생하므로 부하에 주의.
  • 아카이빙 공간이 없으면 -> 온라인 리두로그 복사할 수 없음 -> lgwr은 아카이빙 되지 않은 온라인 리두로그파일을 재사용할 수 없음.
  • 결과적으로 아카이브 프로세스는 중단되어 DB가 일시적으로 중단될 수 있으니 주의.

Flashback 데이터베이스

• 리두는 "forward"를 위해 필요, Flashback 데이터베이스는 "backward" 를 위해 필요.
• 플래시백 활성화 시 플래시백 로그가 생성되기 시작 한다.
• 플래시백 로그는 전체 블록을 보유.
• 데이터블록 변경 전, 현재 플래시백 로그파일 내 해당 블록의 변경내용이 있는지 확인.
• 없으면 변경작업 수행 전 해당 블록을 블래시백 로그파일에 복사 (플래시백 로그버퍼 사용).
• 플래시백 로그는 완벽한 변경이력 저장하지 않으므로, 과거시점으로 이동하기 위해 아카이브리두를 이용한 복구가 필요하다.
  
• 플래시백 로깅의 예
  • 10개 버전 블록이 있으나, 플래시백 로그는 몇 개의 버전만 복사되어 있음.
  • 각 플래시백 로그는 첫번째로 기록된 블록의 SCN을 관리한다.
  • SCN 132867 시점으로 플래시백하며, 해당 SCN은 블록 버전 3에 해당된다고 가정.
    1. 플래시백하려는 가장 가까운 "이전" 시점의 블록을 선택.
    2. 192번 로그 내 저장된 블록을 SCN역순-최신순 으로 읽으면서 목표 SCN보다 작은 last change SCN을 가진 첫번 째 블록을 찾는다.
    3. SCN 132564 를 가진 아키이브 리두로그 ~ 목표 SCN까지 적용하여 복구.
    4. 커밋되지 않은 트랜잭션은 롤백한다.

부작용

• 플래시백 로깅을 활성화 할 경우
• 로깅 I/O 부하.
• 언두 테이블스페이스 처리 방식의 변경으로 인한 I/O 부하.
  • 비활성화 시 언두 재사용 시 이전내용 확인이 필요없어서 할당받은 버퍼 포맷하고 재사용
  • 활성화 시 블록 이전버전을 디스크로 읽어들여 플래시백 로그에 기록해아 하기 때문.
  • 테이블 생성, 인덱스 리빌드가 느림. (블록 재사용 전, 블록의 이전버전을 플래시백 로그에 기록)
• Dataguard 환경에서 physical standby 서버에 플래시백 로깅 활성화는 사용자 실수로 인한 복구시 유용하게 사용될 수 있다.

요약

1. write-ahead logging 전략 사용.
   • 로그버퍼를 로그파일에 먼저 기록, 데이터 블록을 디스크로 기록
2. 매 커밋마다 lgwr을 호출하여 로그버퍼의 내용을 디스크로 기록하여 트랜잭션 내구성 보장 (nowait옵션 제외)
3. 데이터베이스 블록은 변경 시 가장 오래된 변경블록을 디스크에 저장 / 혹은 LRU/TCH 알고리즘으로 캐시로부터 밀려나갈 때가 된 더티 블록을 디스크에 기록
4. Aging알고리즘은 분리된 링크드리스트(체크포인트 큐) 사용. 최초로 더티상태가 되었을 때 리스트 끝에 연결됨.
5. dbwr 과 세션간 경합감소를 위해 각 working data set마다 두개의 링크드 리스트 사용.
6. LRU/TCH 전략은 LRU 체인을 위해 두 쌍의 링크드리스트를 필요로 한다.
   • REPL_MAIN, REPL_AUX (교체리스트:replacement list), WRITE_MAIN, WRITE_AUX (기록리스트: write list or LRU-W)
   • 프리버퍼 검색 시 REPL_MAIN 리스트 검색 -> 더티버퍼를 WRITE_MAIN 리스트로 이동 -> DBWR깨어난 후
     WRITE_MAIN리스트에 연결된 버퍼를 WRITE_AUX로 이동 -> 디스크로 기록한 후 해당 버퍼들을 REPL_AUX 리스트로 이동.
7. 데이터베이스 파일, 로그파일 동기화를 위해 media recovery checkpoint를 수행.
   • 로그파일이 가득 찬 뒤 로그파일 스위치 될 때 해당 이벤트가 발생한다.
8. write-ahead logging전략 장점은 커밋된 트랜잭션은 항상 복구가 가능하다는 점 , 단점은 DB가 갑자기 정지할 수 있다는점 (아카이빙 공간 부족으로 로그스위치 불가할 경우) 이다.
9. incremental 체크포인트로 인해 최신 데이터를 효율적으로 유지, 복구시간을 단축한다.