회복

필요성

• 트랜잭션 T를 수행하는 도중에 시스템이 다운되면 어떻게 복구할 것인가?

• 트랜잭션 T가 완료된 직후 시스템이 다운되면 주기억장치의 버퍼에는 기록되었으니 디스크에는 기록되지 않았을 수도 있음

• 디스크의 헤드가 고장나거나 디스크가 아예 손상나면 어떻게 할 것인가?

고장

• 재해적 고장
  디스크가 손상 → 백업을 통해 해결

• 비재해적 고장
  갑작스런 시스템 다운 → 로그기반 즉시갱신 및 지연갱신, 그림자 페이징

비재해적 고장

로그를 사용한 즉시 갱신

• 트랜잭션이 완료되기 전이라도 디스크의 데이터베이스에 로그로 기록
• 이 로그는 로그 레코드안에 있으며 로그 순서 번호로 식별
  
• 주기억장치의 로그 버퍼에 로그 레코드들을 기록하고 꽉차면 디스크로 Push
• 이중 로그 이 로그도 날아갈 수 있으므로 로그를 두 개로 복사해 저장
• 동일한 트랜잭션의 로그 레코드들은 연결 리스트로 관리

로그 레코드 유형

• [T-ID, start]
  트랜잭션이 생성될 때 기록되는 로그 레코드

• [T-ID, X, old_value, new_value]
  트랜잭션이 X를 old_value에서 new_value로 수정함을 기록한 로그 레코드

• [T-ID, commit]
  트랜잭션을 완료하고 디스크까지 갱신을 모두 했음을 알리는 로그 레코드

• [T-ID, abort]
  트랜잭션이 도중 문제가 생겨 철회되었음을 알리는 로그 레코드

REDO, UNDO

트랜잭션을 수행하다 다운되었을 때 DBMS 회복 모듈은....

• [T-ID, start], [T-ID, commit] 로그 레코드가 모두 존재하는 트랜잭션은 REDO
• [T-ID, commit] 로그 레코드가 존재하지 않는 트랜잭션은 UNDO

로그 먼저 쓰기(WAL: Write Ahead Logging)

• 트랜잭션은 갱신을 하면 데이터를 주기억장치의 버퍼로 먼저 옮김
• 이후 버퍼가 일정양만큼 차면 디스크로 기록
• 데이터베이스 버퍼보다 로그 버퍼를 먼저 디스크에 기록
• WHY? 로그 버퍼를 기록 전에 튕기면 로그는 없는데 데이터는 존재하므로 로그가 없어서 UNDO처리하기 때문

체크포인트

• 일정 시간 10~20분마다 [checkpoint] 로그 레코드를 기록
• 체크포인트 시점에는 주기억장치 버퍼의 내용이 디스크로 강제 기록됨
  → 주기억장치, 디스크의 데이터 일치 상태

재해적 고장

디스크 헤드나, 디스크 자체가 손상 나는 경우는 점진적인 백업
→ 지난 번 백업 이후에 갱신된 내용만 백업을 하는 과정