[SQLP] Redo

 

오라클은 데이터파일과 컨트롤 파일에 가해지는 모든 변경사항을 하나의 Redo 로그 엔트리로서 Redo 로그에 기록(데이터파일에 대한 변경은 캐시된 블록 버퍼를 통해 이루어짐)

 

- Online Redo 로그 : Redo 로그 버퍼에 버퍼링된 로그 엔트리를 기록하는 파일이며, 최소 두 개 이상의 파일로 구성됨. 현재 사용 중인 Redo 로그 파일이 꽉 차면 다음 Redo 로그 파일로 로그 스위칭이 발생. 계속 Redo 로그를 써 나가다가 모든 Redo 로그 파일이 꽉 차면 다시 첫 번째 Redo 로그 파일로부터 재사용하는 라운드 로빈 방식 사용 

- Offline Redo(Archived Redo) 로그 : Online Redo 로그가 재사용되기 전에 다른 위치로 백업해 둔 파일

 

Redo 로그의 3가지 목적

① Database Recovery

　- 물리적으로 디스크가 깨지는 등의 Media Fail 발생 시 데이터베이스를 복구하기 위해 사용

　- Archived Redo 로그를 이용

　- Media Recovery 라고도 함

 

② Cache Recovery(Instance Recovery 시 roll forward 단계)

　- Cache Recovery를 위해 사용

　-  Instance Recovery라고도 함

　- 캐시에 저장된 변경사항이 디스크 상의 데이터 블록에 아직 기록되지 않은 상태에서 인스턴스가 비정상적으로 종료됐을 때 트랜잭션 데이터의 유실에 대비하기 위해 Redo 로그 사용

　- Instance Crach 발생 후 시스템 재기동 시 우선 Online Redo 로그에 저장된 기록사항들을 읽어 마지막 체크포인트 이후부터 사고 발생 직전까지 수행됐던 트랜잭션들을 재현(roll forward 단계)

　- Cache Recovery가 완료되면 Transaction Recovery가 진행됨(rollback 단계)

 

③ Fast Commit

　- 로그는 Append 방식으로 기록하므로 상대적으로 매우 빠름

　-  우선 변경사항을 Append 방식으로 빠르게 로그 파일에 기록하고 나중에 배치 방식으로 일괄 수행

　-  사용자의 갱신 내용이 메모리상의 버퍼 블록에만 기록된 채 디스크에 기록되지 않았지만, Redo 로그를 믿고 빠르게 커밋을 완료한다는 의미에서 Fast Commit일고 부름

　-  Redo 레코드를 기록할 때, 먼저 Redo 로그 버퍼에 기록; 데이터 블록 버퍼를 변경하기 전에 항상 Redo 로그 버퍼에 먼저 기록하고, 일정 시점마다 LGWR 프로세스에 의해 Redo 로그 버퍼에 있는 내용을 Redo 로그 파일에 기록

　- 버퍼 캐시에 있는 블록 버퍼를 갱신하기 전, 먼저 Redo 엔트리를 로그 버퍼에 기록 → DBWR가 버퍼 캐시로부터 Dirty 블록들을 디스크에 기록하기 전에 먼저 LGWR가 해당 Redo 엔트리를 모두 Redo 로그 파일에 기록했음이 보장되어야 함 : Write Ahead Logging

　- 순서 : 사용자 커밋 → 서버 프로세스가 커밋 레코드를 Redo 로그 버퍼에 기록 → LGWR이 트랜잭션 로그 엔트리와 함께 Redo 로그 파일에 저장