Database Recovery

Need for recovery

Database Recovery: The process of restoring the database to a correct state in the event of a failure.

Need for Recovery

1. Data Integrity:

●The primary goal of recovery in a DBMS is to maintain data integrity. Data integrity ensures that the database accurately
reflects the real-world information it is supposed to represent.

●Failures can result in incomplete or inconsistent updates to the database, and recovery mechanisms are necessary to
bring the database back to a consistent state.
2. Transaction Atomicity:

● The system must ensure that either all operations of a transaction are completed successfully or none at all.

●Recovery mechanisms ensure that transactions are atomic, providing a way to undo the effects of incomplete or failed
transactions.

2
 Need for recovery
3. Durability:

●The durability property of a DBMS ensures that once a transaction is committed, its effects persist even in the face of
failures.

●Recovery mechanisms are essential for maintaining durability by storing transaction logs or other information that
allows the system to reconstruct the state of the database before a failure occurred.

● 4. Consistency:

●Recovery processes are designed to restore the database to a consistent state by either rolling back incomplete
transactions or applying necessary compensating transactions when failure occurs.

● 5. User Confidence and Trust:

● Users and applications rely on the database to provide accurate and reliable information.

●The existence of robust recovery mechanisms enhances user confidence by assuring them that, in the event of a failure,
the system can recover to a consistent and reliable state.

3
 Failures
1. Catastrophic Failures:

●Catastrophic failures are severe and often result in the loss of a significant portion of the database or even the entire
database. Examples include hardware failures, disk crashes, or natural disasters.

● Recovery from catastrophic failures typically involves backup and restoration procedures.

2. Non-Catastrophic Failures:

●Non-catastrophic failures are less severe and may affect specific transactions, components, or functionalities within the
database. Examples include software bugs, transaction failures, or human errors.

● Recovery from non-catastrophic failures typically involves transaction management and log-based recovery.

4
 Recovery Facilities
● A DBMS should provide the following facilities to assist with recovery:

1.Backup mechanism -

Makes periodic backup copies of the database;

2.Logging facilities -

Keeps track of the current state of transactions and database changes;

3.Checkpoint facility -

Enables updates to the database that are in progress to be made permanent;

4.Recovery manager -

Allows the system to restore the database to a consistent state following a failure.

5
 Backup Mechanism
●The DBMS should provide a mechanism to allow backup copies of the database and the log file (discussed next) to
be made at regular intervals without necessarily having to stop the system first.
Backup Types
1. Full Database Backup:

A full database backup includes a copy of the entire database, capturing all data, schema, and associated objects.
●

After a full backup, the subsequent transaction log entries are not needed for recovery of the backup itself.

Advantages:

● Complete backup, suitable for restoring the entire database.

● Simplicity in restoration as it involves copying the backup files.

6
 Backup Mechanism

2. Differential Database Backup:

● A differential backup captures changes made since the last full backup, reducing the volume of data to be backed
up compared to a full backup.

Advantages:

● Faster backup process than a full backup.

● Reduces the amount of data transferred during backup.

 Backup Types
3. Incremental Database Backup: - An incremental backup captures changes made since the last backup, whether it
was a full or incremental backup. There may be multiple incremental backups between full backups.

Advantages:

● Even smaller backup sizes compared to differential backups.

● Granular point-in-time recovery is possible.

4. Continuous or Real-Time Database Backup: - In some systems, a continuous or real-time backup process is
implemented, where changes are captured and backed up in near real-time.

Advantages:

● Minimizes data loss in case of failure.

● Allows for very granular recovery points.

8
 Logging Facilities
●To keep track of database transactions, the DBMS maintains a special file called a log (or journal) that contains
information about all updates to the database. The log may contain the following data:

Transaction records, containing:

● Transaction identifier;

● Type of log record (transaction start, insert, update, delete, abort, commit);

● Identifier of data item affected by the database action (insert, delete, and update operations);

● Before-image of the data item, that is, its value before change (update and delete operations only);

● After-image of the data item, that is, its value after change (insert and update operations only);

●Log management information, such as a pointer to previous and next log records for that transaction (all
operations).

Checkpoint records, which we’ll describe shortly.

9
 Logging Facilities
● The log is often used for purposes other than recovery (for example, for performance monitoring and auditing).

●The log may be duplexed or triplexed (that is, two or three separate copies are maintained) so that if one copy is
damaged, another can be used.

10
 Checkpoint facility
It involves periodically saving the current state of the database to stable storage, typically onto disk, marking point from
●

which recovery can begin. Let's delve into the details of checkpointing in a DBMS:

Process of Checkpointing:

1. Write Dirty Pages to Disk:

●During normal operation, databases maintain a buffer pool in memory where changes to data pages are made. Before
initiating a checkpoint, the DBMS writes all dirty (modified) pages from the buffer pool to disk.

2. Create Checkpoint Record:

●Once all dirty pages are flushed to disk, the DBMS creates a checkpoint record in the transaction log, indicating the
completion of the checkpoint process.

3. Update Control Information:

●Metadata or control information within the database is updated to reflect the completion of the checkpoint. This
information typically includes the LSN (Log Sequence Number) of the last checkpoint.

11
 Checkpoints
Purpose of using Checkpoints:

1.Consistency:

●Checkpointing ensures that the database is in a consistent state at certain intervals, reducing the amount of work
needed to recover from failures.

2. Recovery Efficiency:

●By providing a known starting point for recovery operations, checkpointing minimizes the amount of transaction log data
that needs to be replayed during recovery.

Types of Checkpoints:

1. Automatic Checkpoints: Most modern DBMS employ automatic checkpointing, where the system periodically triggers
a checkpoint based on predefined criteria such as elapsed time, number of log records, or amount of data modifications.

2. Manual Checkpoints: Some DBMS also allow for manual initiation of checkpoints by administrators, particularly in
scenarios where a known stable state is desired before performing critical operations.

12
 Checkpoints
Advantages of Checkpointing:

1. Faster Recovery:

●Checkpointing reduces the amount of transaction log data that needs to be replayed during recovery, speeding up the
recovery process.

2. Consistency Guarantees:

●Checkpointing ensures that the database is in a consistent state at known intervals, reducing the risk of data corruption
or inconsistencies.

3. Performance Optimization:

By flushing dirty pages to disk, checkpointing helps optimize database performance by maintaining a balance between
●

memory usage and disk I/O operations.

13
 Checkpoints
Challenges and Considerations:

1. Checkpoint Frequency:

●Determining the optimal checkpoint frequency requires balancing the overhead of checkpointing against the benefits of
faster recovery and improved consistency.

2. Checkpoint Overhead:

●The checkpointing process itself incurs overhead in terms of disk I/O and CPU utilization, which can impact system
performance, particularly in high-transaction-rate environments.

3. Recovery Point Objective (RPO):

●The frequency of checkpoints should align with the organization's recovery point objectives, ensuring that acceptable
levels of data loss are maintained in the event of failures

4. Storage Requirements: Checkpointing increases disk space usage due to the need to persistently store database pages
on disk, particularly if the database experiences frequent updates.

14
 Recovery Techniques
●The particular recovery procedure to be used is dependent on the extent of the damage that has occurred to the
database. We consider two cases:

Catastrophic Failures
●If the database has been extensively damaged, for example a disk head crash has occurred and destroyed the database,
then it is necessary to restore the last backup copy of the database and reapply the update operations of committed
transactions using the log file.

Non-Catastrophic Failures
●If the database has not been physically damaged but has become inconsistent, for example the system crashed while
transactions were executing, then it is necessary to undo the changes that caused the inconsistency.

●It may also be necessary to redo some transactions to ensure that the updates they performed have reached secondary
storage.

●Here, we do not need to use the backup copy of the database but can restore the database to a consistent state using
the before- and after-images held in the log file.

15
 Recovery Techniques in Non-Catastrophic Failures
Deferred Update
Changes made by transactions are not immediately reflected in the database but are instead recorded in the transaction
log until the transaction successfully commits.

Only after the transaction commits are the changes applied to the database.

Process of Deferred Update:

1. Transaction Execution: -When a transaction modifies data, the DBMS records these changes in a transaction log,
rather than directly updating the database.

2. Transaction Commit: Upon successful completion of the transaction, the changes recorded in the transaction log are
applied to the database. The modifications become permanent and visible to other transactions after the commit
operation.

3. Transaction Abort: If a transaction aborts or rolls back, the changes recorded in the transaction log are discarded, and
the database remains unchanged. However, it may be necessary to redo the updates of committed transactions as their
effect may not have reached the database

16
 Deferred Update
Note that we write the log records to disk before the transaction is actually committed, so that if a system failure occurs
●

while the actual database updates are in progress, the log records will survive and the updates can be applied later.

●In the event of a failure, we examine the log to identify the transactions that were in progress at the time of failure.
Starting at the last entry in the log file, we go back to the most recent checkpoint record:

●Any transaction with transaction start and transaction commit log records should be redone. The redo procedure
performs all the writes to the database using the after-image log records for the transactions, in the order in which they
were written to the log. This method guarantees that we’ll update any data item that was not properly updated prior to
the failure.

●For any transactions with transaction start and transaction abort log records, we do nothing since no actual writing was
done to the database, so these transactions do not have to be undone.

17
 Deferred Update
Advantages of Deferred Update
1.Reduced Disk I/O:
Deferred update reduces the number of disk writes during transaction execution since changes are not immediately
applied to the database.
2.Rollback Efficiency:
Since changes are not applied immediately, rolling back a transaction involves discarding the recorded changes,
which can be more efficient than reverting database modifications.
Limitations of Deferred Update

1.Transaction Visibility:
2.Until a transaction commits, its changes are not visible to other transactions, potentially leading to inconsistencies
or isolation violations.
2.Recovery Complexity:
3.Deferred update may require complex recovery mechanisms to ensure that changes are properly applied or
discarded in case of failures.

18
 Immediate Update
Immediate Update
●Changes made by transactions are immediately applied to the database, typically as soon as the transaction executes
the corresponding update operation.

● This approach ensures that modifications are immediately visible to other transactions.

Process of Immediate Update

1.Transaction Execution: When a transaction modifies data, the changes are immediately applied to the database.

2.Transaction Commit: Committing a transaction in immediate update systems typically involves finalizing the
changes already made to the database. - The commit operation ensures the durability of the changes and completes
the transaction.

3.Transaction Abort: If a transaction aborts or rolls back, the changes made by the transaction are reverted,
restoring the affected data to its original state. The log is used to undo it since it contains all the old values for the
updated fields. As a transaction may have performed several changes to an item, the writes are undone in reverse
order .

19
 Immediate Update
●As well as having to redo the updates of committed transactions following a failure, it may now be necessary to undo
the effects of transactions that had not committed at the time of failure

●It is essential that log records (or at least certain parts of them) are written before the corresponding write to the
database. This is known as the write-ahead log protocol. If updates were made to the database first, and failure occurred
before the log record was written, then the recovery manager would have no way of undoing (or redoing) the operation.

●Under the write-ahead log protocol, the recovery manager can safely assume that, if there is no transaction commit
record in the log file for a particular transaction then that transaction was still active at the time of failure and must
therefore be undone.

● If the system fails, recovery involves using the log to undo or redo transactions:

●For any transaction for which both a transaction start and transaction commit record appear in the log, we redo using
the log records to write the after-image of updated fields. This ensures that any writes that did not actually reach the
database will be performed.

●For any transaction for which the log contains a transaction start record but not a transaction commit record, we need
to undo that transaction. The log records are used to write the before-image of the affected fields in the reverse order,
and thus restore the database to its state prior to the transaction’s start.

20
 Immediate Update
Advantages of Immediate Update:

1. Immediate Visibility: Changes made by transactions are immediately visible to other transactions, ensuring
consistency and reducing the risk of isolation violations.

2. Simplicity: Immediate update simplifies recovery and concurrency control mechanisms since changes are applied
directly to the database without intermediate steps.

Limitations of Immediate Update:

3. Increased Disk I/O:

●Immediate update may lead to higher disk I/O operations, particularly in systems with frequent updates, due to the
immediate application of changes to the database.

4. Concurrency Issues:

●Immediate update may result in higher contention and potential conflicts among transactions, especially in systems with
high concurrency

21
 Shadow Paging
●Shadow paging is a technique used in Database Management Systems (DBMS) to implement atomic
transactions and ensure data consistency.

It's a method of maintaining multiple versions of a database page, with one version representing the current
●

state (Shadow copy) of the database and another version representing the changes made (Current copy)
by active transactions. Here's a detailed description of shadow paging in a DBMS:

●In the shadow page scheme, the database is not directly modified but a copy, stored on permanent storage
(e.g. disk), is made of the portion of the database to be modified and all modifications are made to this copy
(Current copy).

●Meanwhile, the old version of the database remains intact. Once the transaction commits, the modified
copy(Current copy) replaces the original (Shadow copy) in an atomic manner, i.e. the replacement is carried
out in its entirety or not at all.

● If a system crashes at this point, the old version is still available for recovery.

22
 Shadow Paging
Advantages of Shadow Paging:

1. Simplicity:

●The use of shadow copies simplifies recovery processes, as the database can easily revert to a consistent state by
discarding uncommitted changes.

2. Atomicity:

●Shadow paging ensures atomicity by keeping transaction modifications isolated from other transactions until they
commit successfully.

Limitations of Shadow Paging:

●1. Overhead: Shadow paging may incur overhead due to the need to maintain multiple copies of database pages,
particularly in systems with large databases or high transaction rates.

●2. Space Utilization: Shadow paging may result in increased storage requirements, as both the shadow and current
copies of database pages need to be maintained.

23