📕 목차

1. Failure Classification
2. Storage Structure
3. Recovery and Atomicity
4. Log-Based Recovery
5. ARIES
6. Media Recovery

1. Failure Classification

 

📌 실패 종류
  • Transaction Failure
    • Logical Error: 잘못된 입력, Overflow, data not fount, …
    • System Error: deadlock
  • System Crash
    • DBMS나 OS 실행 중지 (ex. 정전)
    • Volatile memory 내용 파손
  • Media Failure
    • 가장 최악의 경우 → HDD가 깨짐
    • Nonvolatile memory의 내용 파손

 

2. Storage Structure

 

📌 Storage Types
  • Volatile storage
    • 정전과 같은 system crash 발생 시 내용 파손
    • ex. Main memory, Cache memory
  • Nonvolatile storage
    • System crash가 발생해도 내용 유지
    • Media Failre나 도난에는 대책 없음
    • ex. HDD, SSD
  • Stable storage
    • 어떤 형태의 Failure에도 내용 유지 
    • 복제에 의해 S/W적으로 구현 → 백업을 하자!

 

교수님께서 말씀하시길, 조선왕조실록 백업본이 4개 있어서 지금까지 전해질 수 있었던 걸 보면

데이터 백업도 적어도 그 정도는 해야..

 

📌 Data Access

  • Failure의 가장 어려운 점
    • 언제 실패할 지?
    • 실패하는 도중에 어떤 작업을 하고 있는지?
  • 모든 DB 연산에 대해 경우의 수를 따져야 한다.

  • \(Read(X, x_{i})\)
    • X를 저장한 Buffer block \(B_{x}\)가 없을 경우, input(\(B_{x}\))
    • \(B_{x}\) block에서 X를 읽어 지역 변수 \(x_{i}\)에 할당
  • \(Write(X, x_{i}\)
    • X를 저장한 Buffer block \(B_{x}\)가 없을 경우, input(\(B_{x}\))
    • 지역변수 \(x_{i}\)의 값을 \(B_{x}\) block X에 할당
  • Output ≠ Write & Input ≠ Read
    • System crash 발생 시 recovery 필요
    • Synchronous IO하면 성능 저하로 인해 권장하지 않음. (네트워크 통신 빈번해짐) 

 

3. Recovery and Atomicity

 

📌 Buffer Policy 
  • 실행 중인 Transaction 결과가 Disk에 기록 가능한가?
    • STEAL, ~STEAL
    • 중간 결과를 기록 (검증 X)
  • 완료한 Transaction의 결과를 반드시 Disk에 기록할 것인가?
    • FORCE, ~FORCE
    • 모든 Commit 시점에 DB에 기록

 

📌 Recovery Operations

  • UNDO: 실행 중인 Transaction 결과를 Disk에서 삭제
    ⇒ "Commit도 안 한 거니까, 지우고 Rollback"
  • REDO: 이전에 완료한 Transaction 재실행
    ⇒ "Commit 했는데 DB에 반영 안 됐으니 다시 하자."

 

4. Log-Based Recovery

 

📌 Concept
  • def. Recovery를 위한 기록
  • Update Log Record
    • Transaction이 update 연산을 실행할 때마다 생성
    • 구조
      • Transaction 식별자, Data 식별자
      • Old value, New value (Log 성격에 따라 선택적)
      • Failure 발생 시, 다 사라지고 Log만 남는다. (UNDO - Old, REDO - New)
  • Log Record 종류
    • <\(T_{i} start\)>
    • <\(\T_{i}, X_{j}, V_{1}, V_{2}\)>
    • <\(T_{i} commit\)>
    • <\(T_{i} abort\)>

 

📌 Deffered DB Modification

  • ~STEAL: Transaction 완료 전에 갱신 내용을 DB에 반영하지 않는다.
  • UNDO가 불필요하므로, log에 old value를 기록할 필요 없다.

 

📌 Immediate DB Modification

  • STEAL: Transaction 완료 전에 갱신 내용을 DB에 반영할 수 있다.
  • UNDO와 REDO가 모두 필요하므로, Log에 old, new value 모두 기록

 

📌 Checkpoints

  • Problems at System Restart
    • 어떤 Log record부터 조사할 것인가?
    • 대부분 Transaction 실행 결과는 DB에 이미 반영
  • Checkpoint Steps
    • Log buffer의 모든 Log record들을 Log Disk에 기록
      ⇒ 항상 Log를 먼저 써서 회복이 가능하게 해라 (WAL; Write-ahead Logging)
    • 갱신된 Data buffer page들을 Disk에 기록
    • <checkpoint> Log record를 Log Disk에 기록

 

📌 Checkpoint & System Restart

 

5. ARIES

 

📌 Concept
  • def. Lecovery Standard
  • Transaction Recovery Method
    • Fine-Granularity Locking 지원
    • Partial Rollback 지원
    • Write Ahead Loggin(WAL) 이용
  • 기본 개념
    • Log Sequence Number (LSN) 이용
    • Index에 대한 Logical Undo 지원
    • Flexible Buffer Management: Steal & ~Force
    • Fuzzy Checkpoint 지원

 

📌 Data Structures of ARIES

  • Data Page = Data + PageLSN
  • Log Record
    • Log Sequence Number(LSN)
    • Type: Update, Commit, Compensation, …
    • Transaction Identifier
    • Previous LSN (PrevLSN)
    • Record Identifier
    • Data: Value Logging / Operation Logging

 

🟡 Transaction Table

  • Transaction Table
    • Transaction Identifier
    • State: P(Prepared) or U(Un-prepared)
    • LastLSN
    • UndoNxtLSN

 

🟡 Dirty Pages Table 

  • Page Identifier
  • RecoveryLSN
    • Page가 dirty 상태로 변환될 때의 LSN
    • Page를 회복하기 위한 로그의 starting point
  • check point는 Dirty Pages Table만 관리하면 된다.

 

📌 Normal Processing
  • Page의 record를 update하는 과정
    • Record에 대한 lock 요청 & 승인
    • Page를 buffer에 fix & 'X' mode로 latch
      • X mode: 다른 Transaction이 접근 못 하게 막는다
      • latch: Critical Section은 Lock이 아니라 세마포어로 수정 접근 권한을 제어한다.
    • Record update
    • Log record 생성, in-memory log list에 추가
    • Log의 LSN을 Page의 PageLSN 필드에 저장
    • Page Latch 해제 & unfix
  • Transaction commit
    • commit log 생성, log force, lock release
  • Transaction Abort 과정
    • rollback log record 작성
    • Transaction 시작 위치로 Rolling back
    • pending actions list 제거
    • Lock 제거
  • Fuzzy Checkpoint
    • Begin_Checkpoint log record 기록
    • End_Checkpoint log record 생성
    • End_Checkpoint log record 기록
    • Master record에 Begin_Checkpoint log의 LSN 저장

 

🤔 왜 Log는 Force를 사용할까?

  • data에서는 Steal & ~Force 전략을 사용하지만, Log는 반드시 commit한 시점에 써져야 한다.
  • I/O가 증가해서 불합리하다고 생각할 수 있지만, 두 가지 관점에서 data와는 다르다.
    • "append only storage", Log는 쓰는 위치가 정해져 있기 때문에 순차적이며 빠르다.
    • Log 필요한 것만 전달하면, 하나의 log가 여러 log를 표현하는 효과를 갖는다. (전달량이 훨씬 적음)

 

📌 Restart Processing
  1. Analysis(Master-Addr, Trans-Table, DPT, RedoLSN)
  2. Restart-Redo(RedoLSN, Trans-Table, DPT): commit 내역 기반으로 Redo
  3. Buffer pool DPT = DPT;
  4. Restart-Undo(Trans-Table): 선택적 Undo
  5. Require locks for prepared transactions;
  6. Checkpoint()
  7. RETURN

 

6. Media Recovery

 

📌 Concept
  • HDD가 깨진 경우. 백업 말고는 답이 없음
  • Media Recovery: Archival Dump + Redo Logs

 

저작자표시 비영리

티스토리툴바