로그파일 스위치 체크포인트, incremental 체크포인트, BWR (block written records) 사용.
로그파일 스위치 체크포인트 (media recovery checkpoint) 시, 모든 데이터파일 헤더의 SCN을 체크포인트 시작지점의 SCN으로 변경. (새로운 로그파일의 첫 번째 SCN ) {note} _defer_log_boundary_ckpt , _defer_log_count : 추가적인 몇 번의 로그스위치 발생할 때 까지 로그파일 스위치 체크포인트 발생을 지연시킨다. {note}
데이터파일 헤더, 로그파일 헤더의 lowest SCN 기록 -> 복구를 위한 로그파일을 즉시 확인.
컨트롤파일 내의 마지막 incremental SCN, RBA 저장 -> 복구 시작할 로그파일 내 정확한 위치 확인 가능.
2단계로 리두 적용한다.
last change SCN 저장하는 BWR(block written records)를 검색하여 각 블록의 highest change SCN을 확인한다.
highest change SCN 보다 작은 SCN을 갖는 체인지 벡터는 복구 대상에서 제외.
복구 시 작업 최소화를 위해 세 개의 매커니즘이 함께 동작
로그파일 스위치 체크포인트 / incremental 체크포인트 / BWR
복구 시에 체인지 벡터를 적용하기 위한 별도의 코드가 필요하지 않다.
(일반적인 작업)
리두벡터 생성
로그 버퍼에 저장
데이터 블록에 적용
(복구 시 작업)
파일 로 부터 리두벡터를 읽어들이고
데이터 블록에 적용.
미디어 복구
인스턴스 복구 와 미디어 복구 의 차이점 ?
데이터파일 백업 / 온라인 리두로그 파일 모두 보관하고 있다면 사실상 차이가 없다.
완벽한 복구는 데이터파일 백업 시점 이후의 모든 아카이브 로그 파일이 필요함.
버전에 따라 백업 이후에 추가된 데이터파일 처리 방식이 다르나, 원칙과 매커니즘은 동일하다.
아카이브 프로세스는 로그 스위치 발생 시 I/O 발생하므로 부하에 주의.
아카이빙 공간이 없으면 -> 온라인 리두로그 복사할 수 없음 -> lgwr은 아카이빙 되지 않은 온라인 리두로그파일을 재사용할 수 없음.
결과적으로 아카이브 프로세스는 중단되어 DB가 일시적으로 중단될 수 있으니 주의.
Flashback 데이터베이스
리두는 "forward"를 위해 필요, Flashback 데이터베이스는 "backward" 를 위해 필요.
플래시백 활성화 시 플래시백 로그가 생성되기 시작 한다.
플래시백 로그는 전체 블록을 보유.
데이터블록 변경 전, 현재 플래시백 로그파일 내 해당 블록의 변경내용이 있는지 확인.
없으면 변경작업 수행 전 해당 블록을 블래시백 로그파일에 복사 (플래시백 로그버퍼 사용).
플래시백 로그는 완벽한 변경이력 저장하지 않으므로, 과거시점으로 이동하기 위해 아카이브리두를 이용한 복구가 필요하다.
플래시백 로깅의 예
10개 버전 블록이 있으나, 플래시백 로그는 몇 개의 버전만 복사되어 있음.
각 플래시백 로그는 첫번째로 기록된 블록의 SCN을 관리한다.
SCN 132867 시점으로 플래시백하며, 해당 SCN은 블록 버전 3에 해당된다고 가정.
플래시백하려는 가장 가까운 "이전" 시점의 블록을 선택.
192번 로그 내 저장된 블록을 SCN역순-최신순 으로 읽으면서 목표 SCN보다 작은 last change SCN을 가진 첫번 째 블록을 찾는다.
