지연 갱신(deferred update) 복구 기법에서는 트랜잭션이 커밋(commit)될 때까지 디스크에 대한 실제 데이터베이스 수정 작업이 미뤄집니다. 실행 중에는 갱신 내용이 로그와 캐시 버퍼에만 기록됩니다. 따라서 트랜잭션이 커밋 전에 실패하더라도 디스크상의 데이터베이스는 전혀 영향을 받지 않으므로 UNDO가 필요 없습니다(NO-UNDO). 다만 커밋은 되었지만 아직 디스크에 반영되지 않은 변경 사항에 대해서는 REDO(재실행)만 수행하면 됩니다.
지연 갱신 프로토콜(Deferred Update Protocol)
- 트랜잭션은 커밋 시점(commit point)에 도달하기 전까지 디스크의 데이터베이스를 수정할 수 없습니다.
- 모든 REDO 로그 항목은 커밋 전에 디스크에 강제로 기록되어야 합니다(선기록 방식, Write-Ahead Logging).
- REDO 로그 항목(새로운 값/AFIM)만 필요하며 UNDO 항목은 전혀 요구되지 않습니다.
복구 절차(RDU_M)
엄격한 2단계 잠금(strict two-phase locking)을 적용하는 다중 사용자 시스템에서 복구 알고리즘은 두 개의 목록을 관리합니다.
- 커밋 목록: 마지막 체크포인트 이후 커밋된 트랜잭션들의 집합
- 활성 목록: 장애 발생 시점까지 활성 상태(커밋되지 않음)였던 트랜잭션들의 집합
REDO는 커밋된 트랜잭션의 WRITE 연산에 대해 로그 순서대로 적용됩니다. 활성 상태(미커밋)였던 트랜잭션은 사실상 취소되므로 재제출(resubmit)해야 합니다.
예시 타임라인
- 체크포인트(t1) → 장애 발생(t2)
- T1 → 커밋 완료
- T2 → REDO
- T3 → REDO
- T4 → 무시(커밋 없음)
- T5 → 무시(커밋 없음)
T1은 체크포인트 이전에 커밋되었으므로 REDO가 필요 없습니다. T2와 T3는 체크포인트 이후에 커밋되었기 때문에 REDO를 수행해야 합니다. T4와 T5는 끝내 커밋되지 않았으므로 그대로 무시합니다. 지연 갱신 방식에서는 커밋 전 변경 사항이 디스크에 기록되지 않기 때문입니다.
REDO 최적화
커밋된 트랜잭션들이 항목 X를 여러 번 갱신했다면 마지막 갱신만 REDO하면 됩니다.
- 로그를 역순으로 순회합니다.
- 이미 REDO 처리된 항목의 목록을 유지합니다.
- 목록에 이미 있는 항목은 건너뜁니다(마지막 값이 이미 복구된 상태).
- 목록에 없는 항목만 REDO한 뒤 해당 목록에 추가합니다.
장점과 한계
| 장점 | 한계 |
|---|---|
| 장애 발생 시 롤백이 필요 없습니다(NO-UNDO) | 쓰기 잠금 항목은 커밋 시점까지 잠금 상태가 유지됩니다 |
| 연쇄적 롤백(cascading rollback)이 발생하지 않습니다(항목이 커밋까지 잠김) | 커밋 시점까지 모든 갱신 내용을 담을 버퍼 공간이 필요합니다 |
| 중단된 트랜잭션은 단순히 재제출하면 됩니다 | 변경이 많지 않은 짧은 트랜잭션에만 실용적입니다 |
결론
NO-UNDO/REDO 지연 갱신 기법은 디스크 쓰기를 커밋 시점까지 미루어 복구 과정에서 UNDO 연산을 완전히 제거합니다. 마지막 체크포인트 이후 커밋된 트랜잭션만 REDO하면 되므로 복구 절차가 크게 단순해집니다. 다만 동시성(concurrency)이 제한되고, 커밋되지 않은 모든 변경 사항을 보관할 충분한 버퍼 공간이 필요하다는 점은 고려해야 합니다.
