🧠 DBMS Recovery and Types of Failures

✅ What is Recovery?

In DBMS, recovery means bringing the database back to a consistent and correct state after a failure like a system crash or power failure.

It ensures:

Atomicity: All steps of a transaction are completed or none.
Durability: Once a transaction is committed, its changes stay even after a crash.

Recovery uses techniques like undo (to cancel incomplete changes) and redo (to reapply completed ones).

🧨 1. Types of Failures – Real-Life Examples

🔸 a. Transaction Failure

One transaction fails but others continue.

Example: While transferring money from A to B, power goes off. Money is deducted from A but not added to B.

🔸 b. System Crash

The whole system crashes due to power cut or OS failure.

Example: Multiple users are using the database, but system suddenly shuts down. Some data is lost.

🔸 c. Disk Failure

Database files on the disk are physically damaged.

Example: The disk storing customer records is corrupted and can’t be read.

🔁What is Undo and Redo in DBMS?

Action	Meaning	When Used
UNDO	Cancel the changes of incomplete transactions	If a transaction was not committed before the crash
REDO	Re-apply the changes of completed transactions	If a committed transaction's changes were not saved to disk

🎯Simple Example for Undo and Redo

Let's say account A = ₹1000, B = ₹500.

Case: Transaction T1

T1 transfers ₹200 from A to B

<START T1>
<T1, A, 1000, 800>
<T1, B, 500, 700>
<COMMIT T1>

If system crashes after this log is written but before data is saved:

✅ T1 is committed ⇒ Apply REDO
Result after recovery: A = 800, B = 700

Case: Transaction T2

T2 tries to transfer ₹300 from A to C

<START T2>
<T2, A, 800, 500>
**(Crash here)**

Since T2 is not committed, we use UNDO

Revert A back to ₹800

📘Log-Based Recovery (Detailed)

DBMS stores every change into a log file before applying it to the actual database. This helps in recovery.

🔸Log Entry Format

✅ Example:

<T1, A, 100, 200>

→ means T1 changed A from 100 to 200

✅Checkpoint in DBMS

📘What is Checkpoint?

Checkpoint is a safe point saved by DBMS.
It means: "All changes before this are safely saved on disk."

This reduces recovery time after crash.

✅Example with Checkpoint

Let's say we have the following log:

                    <START T1>
                    <T1, A, 100, 150>
                    <COMMIT T1>

                    <START T2>
                    <T2, B, 200, 300>

                    <CHECKPOINT>

                    <T2, B, 300, 400>
                    <T2, C, 400, 500>
                    <START T3>
                    <T3, A, 150, 180>
                    <CRASH>

💥Crash Happens Now. What to do?

➡️ After crash, DBMS checks the log and the last checkpoint.

At checkpoint:

T1 is committed → ✅ No need to process
T2 and T3 are active → DBMS checks them

🧠Recovery Actions:

Transaction	Status	Action
T1	Committed before checkpoint	Nothing to do
T2	Not committed	❌ Undo
T3	Not committed	❌ Undo

✅ Final State:

A = 150
B = 200
C = 400

🪞Shadow Paging (Alternative to Logs)

💡Idea: Work on a duplicate version until done

🔸Real-life Example:

You write an article. Instead of editing the original, you edit a copy. If all edits are good, you replace the original. If not, discard the copy.

🌗Shadow Paging in DBMS

Shadow Page Table: Original data (never touched)
Current Page Table: Used during transaction
If commit: Copy current to shadow
If crash: Discard current and use shadow

🔸Example:

Let's say:

A = ₹100
Transaction changes A to ₹200

Shadow Table: A = 100

Current Table: A = 200

Crash before commit → Discard current

Final value = 100 ✅ (safe)

🔄Recovery Phases in DBMS

After crash, recovery goes in these steps:

Analysis Phase
→ Find which transactions were active during crash.

Redo Phase
→ Reapply changes of committed transactions.

Undo Phase
→ Rollback changes of uncommitted transactions.

🧾FULL FINAL EXAMPLE: COMBINING ALL

Situation: Three transactions

Initial Values:

A = 100
B = 200
C = 300

Log File:

                    <START T1>
                    <T1, A, 100, 150>
                    <T1, B, 200, 250>
                    <COMMIT T1>

                    <START T2>
                    <T2, C, 300, 350>

                    <CHECKPOINT>

                    <T2, C, 350, 400>

                    <START T3>
                    <T3, A, 150, 180>

                    <CRASH>

Now Recovery Happens

Transaction	Status	Action
T1	Committed	✅ REDO
T2	Not committed	❌ UNDO
T3	Not committed	❌ UNDO

Final Values after Recovery:

A = 150 (from T1 REDO)
B = 250 (from T1 REDO)
C = 300 (T2 undone)

✅ Safe, consistent data.

📌Summary

🔄Undo

Meaning: Cancel uncommitted changes

Use: Recover from crash

🔄Redo

Meaning: Reapply committed changes

Use: Ensure durability

✅Checkpoint

Meaning: Safe save point

Use: Faster recovery

🪞Shadow Paging

Meaning: Copy-modify method

Use: Simple recovery, no logs

📘Log File

Meaning: History of all actions

Use: Used for recovery

🔄Recovery Phases

Meaning: Analyze → Redo → Undo

Use: Full process