Shadow Copy Scheme

Shadow Copy Scheme is a method used to ensure data consistency and durability by creating a
copy of the entire database before any changes are made.

How It Works:

1. Create Shadow Copy: Before making any changes, a complete copy of the database (called
a shadow copy) is created.
2. Make Changes: All changes are made to the shadow copy, not the original database.
3. Commit Changes: Once all changes are successfully made to the shadow copy, it is
swapped with the original database.
Example:Imagine a library database where you need to update the inventory.

1. Current Database:
◦ Book A: 5 copies
◦ Book B: 3 copies
2. Create Shadow Copy:

◦ Shadow Copy: (identical to the original)

▪ Book A: 5 copies
▪ Book B: 3 copies
3. Make Changes to Shadow Copy:

◦ Update Book A: 5 -> 4 copies

◦ Update Book B: 3 -> 5 copies
◦ Shadow Copy:
▪ Book A: 4 copies
▪ Book B: 5 copies
4. Commit Changes:

◦ Swap the shadow copy with the original database.

◦ New Database:
▪ Book A: 4 copies
▪ Book B: 5 copies
If something goes wrong during the update process, the original database remains unchanged
because changes were made to the shadow copy

Caption
LOG BASED RECOVERY:

Log-based recovery in DBMS (Database Management System) is a method used to restore a

database to a correct state after a failure. This process relies on a log, which is a record of all the
transactions and changes made to the database.

Caption

Deferred Database Modi cations

Concept: All database changes (writes) are recorded in the log but are not applied to the database
until the transaction completes. If the transaction fails, the changes are not applied. If the transaction
completes successfully, the changes are applied using the log.

Example:

Imagine a banking database with an account having an initial balance of $1000.

1. Transaction T1:
◦ Start
◦ Withdraw $200 (new balance should be $800, but this is not yet written to the
database)
◦ End
2. Log Entries:

◦ Start T1
◦ T1: Withdraw $200 (log this change but do not apply to database yet)
◦ End T1
3. Applying Changes:
fi
 ◦ Once T1 completes, the change is applied: new balance is $800
4. Crash Scenario:
◦ If the system crashes before T1 ends, no changes are applied to the database, and the
log entry is ignored.
Immediate Database Modi cations

Concept: Database changes are applied immediately as the transaction progresses. The log records
both old and new values for each change. If a transaction fails or the system crashes, the log is used
to undo (rollback) or redo (reapply) changes.

Example:

Imagine the same banking database with an initial balance of $1000.

1. Transaction T1:
◦ Start
◦ Withdraw $200 (new balance should be $800, this is written immediately to the
database)
◦ End
2. Log Entries:

◦ Start T1
◦ T1: Old balance $1000, New balance $800 (log this change and apply to database)
◦ End T1
3. Applying Changes:

◦ As T1 progresses, the database is updated to $800, and the log records the old and
new values.
4. Crash Scenario:

◦ If the system crashes after logging but before T1 ends, the system uses the old value
($1000) from the log to undo the change.
◦ If the system crashes after T1 completes, the system uses the new value ($800) from
the log to redo the change.
Summary of Failure Handling:
1. Deferred Modi cations:
◦ Changes are logged but not applied until the transaction completes.
◦ If a failure occurs before the transaction completes, changes are ignored.
◦ If the transaction completes and then a failure occurs, changes are applied using the
log.
2. Immediate Modi cations:

◦ Changes are logged and applied immediately.

◦ If a failure occurs before the transaction completes, the old values from the log are
used to undo changes.
◦ If the transaction completes and then a failure occurs, the new values from the log
are used to redo changes.
Example Scenario:
fi
fi
fi
Deferred Modi cations:

1. Transaction T2:
◦ Start
◦ Deposit $300 (log the change, new balance should be $1300, but not applied yet)
◦ End
2. Log Entries:

◦ Start T2
◦ T2: Deposit $300 (log this change, but don't apply to database)
◦ End T2
3. If T2 completes:

◦ Apply the change: balance becomes $1300

4. If a crash occurs before T2 ends:
◦
No change is applied, log entry is ignored.
Immediate Modi cations:

1. Transaction T2:
◦ Start
◦ Deposit $300 (log the old balance $1000 and new balance $1300, and apply
immediately)
◦ End
2. Log Entries:

◦ Start T2
◦ T2: Old balance $1000, New balance $1300 (log and apply)
◦ End T2
3. If T2 completes:

◦ Balance is $1300, and log can be used to redo if needed.

4. If a crash occurs before T2 ends:
◦ Use old value ($1000) to undo the change.

Caption
fi
fi
CHECKPOINTS:

Checkpoints in a Database Management System (DBMS) are a way to simplify and speed up the
recovery process after a system crash. A checkpoint is like a snapshot of the database at a particular
point in time. It helps reduce the amount of work needed during recovery by providing a point from
which the system can start rather than having to process the entire log.

How Checkpoints Work

1. Create a Checkpoint: Periodically, the system will save a snapshot of the current state of
the database and record it as a checkpoint.
2. Flush Logs: Ensure that all log entries up to the checkpoint are written to stable storage.
3. Recovery Process:
◦ Start from Checkpoint: If a crash occurs, the recovery process can start from the
most recent checkpoint.
◦ Apply Changes: Only the log entries recorded after the checkpoint need to be
processed to bring the database to a consistent state.
Simple Example

Imagine you have a database managing account balances:

1. Initial State:
◦ Account A: $1000
Transactions:

1. Transaction T1:

◦ Withdraw $200 from Account A

2. Transaction T2:

◦ Deposit $300 to Account A

Logs and Checkpoints:

1. Log Before Checkpoint:

◦ T1: Withdraw $200 from Account A (new balance $800)

◦ T2: Deposit $300 to Account A (new balance $1100)
2. Create Checkpoint:

◦ The current state of the database is recorded (Account A: $1100)

◦ All log entries up to this point are written to stable storage.
Further Transactions After Checkpoint:

3. Transaction T3:

◦ Withdraw $100 from Account A (new balance $1000)

4. Log After Checkpoint:

◦ T3: Withdraw $100 from Account A (new balance $1000)

Crash Scenario:
 Imagine the system crashes right after T3 but before the new balance of $1000 is written to the
database.

Recovery Steps:

1. Start from Last Checkpoint: The recovery process starts from the last checkpoint
(Account A: $1100).
2. Redo Transactions After Checkpoint:
• Since T1 and T2 are already safely stored (due to the checkpoint), the system only needs to
redo T3.
• The recovery system checks the log for T3's actions and redoes them to restore the database
state.

Bene ts of Checkpoints:

• Speed Up Recovery: Instead of reprocessing all transactions from the very beginning, the
system starts from the last checkpoint, reducing the amount of work needed.
• Consistency: Checkpoints help ensure that the database remains consistent by providing a
known good state to start the recovery process.
Summary:

• Checkpoints: Periodic snapshots of the database state to simplify recovery.

• Logs: Record all changes; used to apply changes after the checkpoint during recovery.
• Recovery: Start from the last checkpoint and apply only the changes logged after that point.
This way, checkpoints make the recovery process faster and more ef cient.
fi
fi