1. Redo
- 오라클은 'Data Files'과 'Control File'에 가해지는 모든 변경사항을 하나의 Redo Log에 기록함.
- Redo Log는 'Online Redo Log'와 'Offline Redo Log(Archived)'로 구성된다.
- 'Online Redo Log'
- Redo Log Buffer에 버퍼링된 로그 엔트리를 기록하는 파일로, 최소 두 개 이상의 파일로 구성
- 현재 사용장인 Redo Log File이 꽉 차면 다음 Redo Log File로 Log Switching을 하고
모든 Redo Log File이 꽉 차면 다시 첫 번째 Redo Log File부터 재사용되는 'Round-Roin' 방식 사용
- 'Offline Redo Log(Archived)'
- 'Online Redo Log'가 재사용되기 전에 다른 위치로 백업해 둔 파일
2. Redo Log 사용 목적
- Database Recovery
- 물리적으로 디스크가 깨질 때 데이터베이스 복구를 위해 사용되며 이 때 'Offline Redo Log(Archived)' 사용
- Cache Recovery(Instance Recovery시 roll forward 단계)
- 인스턴스가 비정상적으로 종료될 경우 버퍼캐시에 올라가 있지만 아직 COMMIT되지 않는 상태를 원복하기 위해 Redo Log를 사용
- 비정상 종료 후 시스템이 재가동되면 'Online Redo Log'에 저장된 기록들을 읽고 마지막 체크포인트 이후부터 사고발생
직전까지 수행되었던 트랜잭션들을 재현함. 이로 인해 버퍼 캐시에만 수정하고 데이터파일에 반영되지 않았던 사항들이
복구되며, 이 때 무조건 비정상 종료 이전으로 되돌린다. - 이후 'Undo Log'를 이용하여 변경되지 이전 상태로 되돌리는 Rollback 단계를 진행하여 동기화를 한다.
- Fast Commit
- 'Redo Log'는 'Fast Commit'을 위해 사용
- 변경된 버퍼 블록을 디스크에 저장할때는 Random Access 방식으로 이루어지기 때문에 느리지만,
'Log'는 Append 방식으로 저장하므로 매우 빠름
그러므로 건건이 디스크에 저장하는 것이 아니라 'Redo Log'에 한동한 저장한 뒤 후에 배치 방식으로 일괄 수행하는데
이 방식을 'Fast Commit'이라 부른다. - 'Fast Commit'을 구현할 때는 'Delayed Block Cleanout' 기법을 사용하는데 COMMIT 이후 Lock을 해제하려면 해당 레코드에
있는 모든 블록들을 일일이 찾아야 하므로 빠른 수행을 할 수 없다. 이를 해결하기 위해 Commit 시점에는 Undo Segment Header의
트랜잭션 테이블만 Commit 정보를 기록하고 'Block Cleanout(갱신된 블록에 커밋 정보를 기록하고 Lock을 해제하는 작업)'은 나중에 수행
- LGWR가 Redo Log Buffer를 Redo Log files에 기록하는 시점
- 3초마다 DBWR 프로세스로부터 신호를 받을 때
(DBWR는 Dirty Buffer를 Data Files에 기록하기 전에 Log Buffer 내용을 Redo Log Files에 기록하도록 LGWR에게 신호를 보냄) - 로그 버퍼의 1/3이 차거나 기록된 Redo 레코드량이 1MB를 넘을 때
- 사용자가 커밋 또는 롤백 명령을 날릴 때(Fast Commit)
① 사용자가 Commit을 날림
② LGWR는 Commit Record를 Redo Log Buffer에 기록
③ 이 기록들을 바로 Redo Log Files에 저장
④ Commit을 수행한 Transaction에 'success code'를 리턴
⑤ 이후 일괄로 'Data files'에 저장
⑥ 'Online Redo Log' 내용은 재사용되기 전에 'Offline Redo Log(Archived)'로 백업
- 'log file sync' 대기이벤트는 LGWR 프로세스가 로그 버퍼 내용을 Redo 로그 파일에 기록할 때까지 서버 프로세스가 대기하는 현상
문서에 대하여