[DB/1-4. Recoverability(회복 가능)]

4️⃣ Recoverability

복구 : 원자성 (Atomicity) 위해 필요

---

Recoverable Schedules

Recoverable Schedule?

: Write연산이 Read연산을 하기 전에 먼저 commit 되어야 함. → recoverable함

T8이 쓴 값을 T9가 읽은 경우, T9가 읽는 값은 아직 committed되지 않은 것. T9 완료하고 T8이 rollback을 하면 T9수행 연산을 취소하여야 하는데 T9는 이미 완료되었으므로 복구 불가능한 문제 발생 ⇒ Durable 성질 위배

 

T8의 rollback 전에 commit됨 → inconsistent함

 

 

만약 commit 후 rollback해야 하는 상황?

• abort 발생해서 rollback된 상황
• 근데 commit은 이미 완료
• Commit을 연기해서 방지 (rollback 끝나고 수행)

=> DB는 스케줄이 recoverable하도록 보장해야 함.

---

Cascading Rollbacks

: a single transaction failure leads to a series of transaction rollbacks
→ Can lead to the undoing of a significant amount of work

(트랜잭션하나의 철회가 다른 트랜잭션 철회를 유도, 방지 위해 기본적으로 committed read만을 허용)

 

→ T10이 Rollback을 하면, T11, T12도 같이 철회해야 함 (T11, T12의 Read(A)가 dirty read이므로 committed된 값이 아니기 때문)

 

---

Cascadeless Schedules

Cascadeless (avoid cascading aborts, ACA) Schedules

• cascading rollback은 발생할 수 없음
• 기본적으로 committed된 데이터 읽기만을 허용
• 임의의 트랜잭션이 읽으려고 하는 데이터에 대해, 트랜잭션이 해당 데이터를 읽기 전에 그 데이터를 마지막으로 쓰기한 트랜잭션이 commit하기를 요구하는 스케줄
• 모든 ACA 스케줄은 recoverable함

---

Relationship Between Histories

ST - 더 제한적임

: 쓰기 연산을 한 트랜잭션이 (commit/abort) 종료될 때까지 해당 데이터를 읽거나 쓸 수 없음.

• RC : recoverable
• ACA : avoids cascading aborts
• ST : strict
• SR : conflict serializable

[ACA schedule that is not in ST]

• ACA? (W-R 사이에 commit?) : T1의 W(Y), T2의 R(Y) 사이에 Commit 존재 → ACA (O)
• ST? (W-W 사이에 commit?) : T1의 W(X), T2의 W(X) 사이에 Commit 존재하지 않음 → ST (X)

---

Concurrency Control

• Consistency 유지하려면?
  1. View serializable or Conflict Serializable
  2. recoverable (+ cascadeless는 부가적으로)
• 한번에 하나의 트랜잭션 수행? serial하지만 concurrency ↓ (차라리 throughput을 개선해야)
• 실행한 후 serializability를 검사하는 것은 너무 느림 (현실적이지 x) → Concurrency control protocols 사용

 

• Concurrency control protocol이 보장하는 것
  • 스케줄 동시 수행
  • conflict / view serializable
  • recoverable
  • cascadeless

•