0. Redo 로그가 왜 필요한가?
DB는 데이터를 메모리 (버퍼 캐시)에서 바꾸고, 나중에 디스크 (데이터 파일)에 반영한다. 그런데 디스크 반영 전에 장애가 발생하면 메모리 변경분이 날아간다. 이걸 복구하려고, 변경 내용을 Redo 로그에 먼저 기록해둔다.
1. Write ahead Logging (WAL, 선행 로그 기록)
데이터 블록을 디스크에 쓰기 전에, 그 변경에 대한 REDO로 먼저 디스크에 기록하는 원칙
WAL 순서: REDO 로그 먼저 기록 -> 데이터 블록 -> 장애 나도 REDO로 복구
즉, WAL 덕분에 오라클은 REDO만 안전하게 기록됐으면, 데이터 블록은 나중에 천천히 써도 된다!
2. Log Force at Commit (커밋 시 로그 강제 기록)
트랜잭션이 커밋될 때, 그 트랜잭션의 REDO 로그를 반드시 디스크(REDO 로그 파일)에 기록 완료한 뒤에야 커밋 성공을 알려주는 원칙
사용자 커밋 요청
-> LGWR가 해당 REDO를 로그 파일에 기록 (디스크 동기화)
-> 기록 확인 완료
-> 커밋 성공 반환
3. Fast Commit
커밋 시 변경된 데이터 블록 전체를 디스크에 쓰지 않고, 가벼운 REDO 로그만 기록해서 커밋을 빠르게 끝내는 메커니즘
변경된 데이터 블록(dirty block)은 버퍼 캐시에 그대로 두고, 나중에 DBWR가 모아서 디스크에 쓴다.
커밋은 REDO 기록만으로 즉시 끝나니 빠름
4. Delayed Block Cleanout
커밋 시 변경된 모든 블록의 상태 정보(트랜잭션 락 등)를 즉시 정리하지 않고, 나중에 그 블록을 읽을 때 정리하는 메커니즘
트랜잭션이 데이터를 바꾸면, 각 블록에 "이 행은 트랜잭션 T가 락 걸었음" 같은 정보(ITL, 트랜잭션 슬롯)가 기록된다. 커밋하면 원래 이 정보를 "커밋됨"으로 정리 (cleanout) 해야 하는데 많은 블록을 변경했다면! 많은 I/O 발생
-> 나중에 해당 블록을 읽을 때 정리!
