1. WAL
Write-ahead logging, 말 그대로 log를 선행한다는 의미로 Database의 data 파일을 Databse log record를 사용하여 동기화 및 복구하고, 이때 data 파일은 block화하여 처리한다는 것이다.
이때 Redo, undo 정보 모두 log 파일에 기록되고, 디스크에 누적하여 연속으로 쓴다. 이에 따라 성능이 좋고 그만큼 디스크 용량 및 횟수가 감소한다.
2. Data Buffer
DB와 log record를 기록하는 과정 혹은 data file의 갱신(입력, Write) 과정은 모두 Database buffer를 일관되게 경유한다.
효율적인 데이터 일관성 유지를 위해, DB datafile을 block화하여 이를 buffer pool에 저장하며 여러 트랜잭션이 발생하여도 동일한 pool 및 block을 활용한다.
3. Data Write/update 과정
-
갱신 대상의 data를 포함한 data file에서 block으로 추출하고, 이것이 data buffer pool에 존재하는지 확인한다.
-
없다면 datafile에서 block을 읽고, 이를 buffer pool에 저장한다(=write).
있다면 해당 block을 buffer pool에서 그대로 읽어오고, block을 갱신한다. -
block 갱신 내용이 commit과 함께 log에 기록되고, 그 후 db에 기록된다.
-
갱신되었으나 사용하지 않은 block은 dirty block이 된다.
갱신된 data block은 나중에 정리되어 data file에 저장된다(=db에 수정내용이 반영). -
위 수정된 시점을 체크포인트라 하고, 체크포인트 이전 로그파일과 함께 수정내역이 저장된다.
이 체크포인트 내역들은 재활용이 가능하며, 위 과정을 반복하여 Data Write/update가 진행된다.
4. 복구
DB crash로 인해 복구가 필요할때, 먼저 다음의 3가지 요소가 반드시 필요하다.
- WAL ) 마지막으로 저장된 수정내역이 저장됨(체크포인트)
- DB Buffer ) Crash로 내용이 소실됨
- DB data file(block) ) 가장 최신의 체크포인트 내용까지 반영됨
Crash가 발생하였을 때, DB파일을 log의 체크포인트를 활용하여 Crash 직전 상태로 복구한다(log 파일은 alive).
이를 Roll-forward 상태라 하며, 로그는 백업이 완료된 상태로 대기하고 있기 때문에 DB 및 datafile의 상태를 최신으로 유지할 수 있다.
※ 다만 DB의 논리적, 물리적 파괴에는 대응이 불가능하다.
5. 참고자료
패스트캠퍼스 - 데이터베이스와 SQLD
