[CS][데이터베이스 시스템 3판] Chapter18. Cash Recovery

 

 

 

Motivation

• Atomicity : Transaction이 abort 할 수 있다. (rollback)
• Durability → 만약 DBMS가 실행을 중단하면?
• 시스템 재시작 후 원하는 동작
  • T1, T2, T3가 durable 해야 한다. (이미 commit 되어 durability를 책임져야 한다.) → 변경 상태가 DB에 남아 있어야 한다. (안 남아 있다면 ReDo 필요)
  • T4, T5는 abort(스스로X, 시스템이) 되어야 한다. (atomicity를 책임져야 한다.) → action이 없던 것처럼 recover 되어야 한다. (recovery는 abort 까지만, 다시 수행시키지는 않는다.)
    • Read : 상태변화 X → 상관 X, 영향 X
    • Write : 상태변화 했을 수도 → 상관 O, 모든 경우에 대해 abort 할 수 있어야 한다. UNDO가 필요할 수도

 

 

 

Recovery Strategy

• 문제의 발단은 늘 Write..

1. Deffered Update (지연 업데이트)
   • transaction이 commit 될 때까지는 update를 하지 않는다.
   • commit 중에는 update를 log에 지속적으로 기록하고 DB에 기록한다.
   • UNDO나 REDO를 안한다.
   • T4, T5를 abort 할 때 쉬움
   • 변경 사항이 시스템에 반영되지 않아야 하니까
2. Immediate Update
   • 빨리빨리 업데이트
   • commit 전에 write operation 직후에 update

 

 

 

Handlig the Buffer Pool (정책)

• transaction이 commite 할 때 upgrade를 force 한다.
  • 강압적으로 명령한다.
  • file이 forcing 된다.
  • file이 flushing 된다.
  • 실제 DB에 있는 것까지 변경해라
  • 하위 파일까지 변경 사항을 적용한다.
  • 가능하면 안 쓰는 것이 좋다. (I/O가 과도해져서)
  • 응답 시간이 부족하다.
  • durability 지원이 쉽다.
  • deffered update
• commit 되지 않은 transaction에서 buffer frame을 steal 한다.
  • transaction 완료 전에 disk에 기록한다. (중간 상태가 disk에 저장된다)
  • 이렇게 하지 않으면 throughput이 떨어진다.
  • atomicity 지원이 어렵다. → fail이 나면 누구는 기록이 있고 누구는 없을 수 있어서
  • interrupt 걸렸을 때 등장한다.
  • 안 끝났는데 종료해서 디스크에 남을 수도 있다.
  • Ex. buffer이 10개인데 transaction이 15개이면
    • buffer가 부족해지면 → 쓰던 buffer을 다른 transaction에게 분다.
    • 내 것을 steal 하려면? steal 전에 상태를 buffer에 보관해야 한다. (작업 보존을 위해)
• 현실은 No forcing과 No stealing 이다. → 그래서 Recovery 시스템과 logging이 필요하다.
• no steal & force → 모든 변경이 완료시점에 디스크에 기록되기 때문에 가장 편하다.

 

 

 

Basic Idea : Logging

• REDO와 UNDO를 위해 기록을 남긴다.
• read는 문제 없지만 write가 문제다.
• REDO
  • commit 된 transaction을 재실행
  • 새로운 value가 필요 (어떻게 바꾸었다.)
  • 로그의 적당한 위치에서 시작하여 모든 액션들을 반복하고 DB 상태를 장애시점이 있었던 상태로 복구한다.
• UNDO
  • dirty data를 읽는 fail이나 uncommit 된 transaction의 operation을 실행취소 해야 한다.
  • old value가 필요하다. (어떤걸 UNDO 할지)
  • DB에 완료된 transaction 액션만 반영이 되도록 하기 위해서 완료하지 않은 transaction의 액션들을 실행 취소한다.
• log에 모든 업데이트에 대한 REDO, UNDO 정보를 기록해야 한다.
• log에 순차적으로 작성한다. (separate disk에 둔다.)
• 최소한의 정보(diff)를 기록하여 여러개의 update가 하나의 log page에 들어간다. (시간 단축을 위해서)

 

 

 

Write-Ahead Logging (WAL) Protocol

1. 해당 data page가 disk에 도달하기 전에 update를 위해 log record를 강제로 기록한다.
   • log가 먼저 쓰여져야 한다.
   • automicity를 보장한다. (undo가 난 상황을 생각했을 때)
2. commit 하기 전에 transaction에 대한 모든 log record를 write 해야 한다.
   • durability를 보장한다.
   • commit 하면 어차피 log에 남는데 log를 먼저 쓰고 commit을 수행하는 것

• logging(recovery)가 어떻게 이루어지는지
  • ARIES와 유사하다.

 

 

 

Checkpointing

• system crash일 때 recovery에 걸리는 시간을 최소화 하기 위해 DBMS가 주기적으로 checkpoint를 생성한다.
• checkpoint도 log에 남아야 한다.
• checkpoint가 포함하는 것
  • checkpoint record를 log storage에 강제로 보낸다.
  • DB buffer의 내용을 DB로 강제로 보낸다.
  • log 내 checkpoint record의 주소를 master record에 기록한다. (checkpoint 시점의 정보가 있다.)
• chekpoint : recovery 시 sacn할 log의 양을 제한할 수 있는 빠른 방법
• Checkpoint가 없다면 crash → 전체 Transaction REDO → 오래걸린다. → 중간중간 Disk에 반영해놔야 한다. → Recovery 부담을 줄이자.
• checkpoint 이전에 수행된 작업은 REDO 할 필요가 없다.