ใน Deferred Update Recovery การปรับเปลี่ยนฐานข้อมูลจริงบนดิสก์ถูกเลื่อนจนกว่า Transaction จะ Commit Updates ถูกบันทึกแค่ใน Log และ Cache Buffers ระหว่าง Execution หาก Transaction ล้มเหลวก่อน Commit ฐานข้อมูลบนดิสก์ไม่ได้รับผลกระทบ ดังนั้น NO-UNDO ต้องการแค่ REDO สำหรับ Transactions ที่ Committed แล้วแต่ยังไม่ได้เขียนลงดิสก์
Deferred Update Protocol
- Transaction ไม่สามารถแก้ไขฐานข้อมูลบนดิสก์ได้จนกว่าจะถึง Commit Point
- REDO Log Entries ทั้งหมดต้อง Force-write ลงดิสก์ก่อน Commit (Write-Ahead Logging)
- ต้องการแค่ REDO Log Entries (ค่าใหม่/AFIM) ไม่ต้องการ UNDO Entries
กระบวนการ Recovery (RDU_M)
สำหรับระบบ Multi-user พร้อม Strict Two-Phase Locking อัลกอริธึม Recovery รักษา 2 รายการ
- Commit List: Transactions ที่ Committed ตั้งแต่ Checkpoint ล่าสุด
- Active List: Transactions ที่ยัง Active (ยังไม่ Commit)
REDO ถูกนำไปใช้กับ WRITE Operations ของ Committed Transactions ตามลำดับ Log Active (Uncommitted) Transactions ถูกยกเลิกโดยมีประสิทธิภาพ และต้องส่งใหม่ (Resubmit)
ตัวอย่าง Timeline
Checkpoint (t1) → Crash (t2) T1 (Committed) → T2 (REDO) → T3 (REDO) → T4 (Ignored - No Commit) → T5 (Ignored - No Commit)
T1 Committed ก่อน Checkpoint → ไม่ต้อง REDO T2, T3 Committed หลัง Checkpoint → ต้อง REDO T4, T5 ไม่เคย Commit → Ignored (ไม่มีการเปลี่ยนแปลงบนดิสก์ภายใต้ Deferred Update)
การเพิ่มประสิทธิภาพ REDO
หาก Item X ถูกอัปเดตหลายครั้งโดย Committed Transactions ต้อง REDO แค่ครั้งสุดท้าย
- เดิน Log ย้อนกลับ (Reverse Order)
- เก็บรายการ Items ที่ REDO แล้ว
- ข้าม Items ที่อยู่ในรายการแล้ว (ค่าสุดท้าย Recovered แล้ว)
- REDO แค่ Items ที่ยังไม่อยู่ในรายการ แล้วเพิ่มเข้าไป
ข้อได้เปรียบและข้อจำกัด
| ข้อได้เปรียบ | ข้อจำกัด |
|---|---|
| ไม่ต้อง Rollback เมื่อล้มเหลว (NO-UNDO) | Items ที่ Write-locked อยู่ Lock จนกว่า Commit |
| ไม่มี Cascading Rollbacks (Items Locked จนกว่า Commit) | ต้องการ Buffer Space สำหรับ Updates ทั้งหมดจนกว่า Commit |
| Aborted Transactions ส่งใหม่ได้ง่าย | เหมาะสมเฉพาะ Short Transactions ที่มีการเปลี่ยนแปลงน้อย |
สรุป
NO-UNDO/REDO Deferred Update เลื่อนการเขียนดิสก์จนกว่า Commit ทำให้ไม่ต้องการ UNDO Operations ระหว่าง Recovery ต้องการแค่ REDO สำหรับ Committed Transactions หลัง Checkpoint ล่าสุด ทำให้ Recovery เรียบง่าย แต่จำกัด Concurrency และต้องการ Buffer Space พอสำหรับ Uncommitted Changes ทั้งหมด
