Database Recovery Techniques in DBMS

When an error or failure occurs, database recovery is the process of getting the database back
to a consistent and useable condition. Failures can be brought on by glitches in hardware or
software, power failures, human mistake, or other difficulties. Database recovery is essential
to preserving the database's integrity and guaranteeing the availability and accuracy of the
data.

In general, database recovery involves the following three main steps:

1. Identifying the problem: This step examines the system logs, error messages, and
other diagnostic data, to extract the reason for the failure.
2. Restoring the database: To use recovery techniques like rollback, checkpoint, redo,
undo, or shadow paging in order to bring the database back to a consistent state.
3. Verifying the recovery: Run a number of tests and queries to make sure the data is
accurate and the system is working properly in order to confirm that the database has
been restored to a consistent and usable state.

History of Database Recovery Techniques in DBMS

Database recovery techniques have a long history that consists the invention of computers. As
databases grew and gained importance for organizations, as well as hardware and software
failures increased in frequency, the necessity for recovery strategies developed.
 In 1970, the undo log was one of the recovery technique introduced in R database
systems.
 The redo log, first used in the 1970s with the IBM/38 database system, is another
early recovery technique.
 Checkpointing tool was used as a first recovery tool in the 1980s.
 In 1990, shadow paging was introduced as a recovery method that entails making a
copy of the database on a disc and making changes to the copy rather than the original
database.
These and other recovery approaches are now used in modern database systems to guarantee
the dependability, availability, and performance of database systems. As hardware and
software technology change and new possibilities and difficulties in the field of database
administration present themselves.

Database Recovery Techniques in DBMS

There are several techniques used in database management systems (DBMS) for database
recovery in the event of failures or mistakes. These methods make a guarantee that even after
failures or mistakes, the database is consistent and recoverable.

Here are a few typical methods for recovering databases:

1. Rollback:
Undoing the changes made by a transaction that failed or aborted is the goal of the database
recovery technique known as rollback. By undoing the consequences of the failed transaction,
it is used to return the database to a consistent state.
A transaction is often a sequence of actions carried out as a single piece of labor. The
database management system (DBMS) records the alterations that a transaction makes to the
database as it is carried out. The DBMS utilizes the data in the transaction log to reverse the
changes made by the transaction if it fails or cancelled due to an error.
The rollback approach operates as follows:
 When a transaction starts, the DBMS creates a savepoint or a point at which a
rollback is possible in the transaction.
 The DBMS rolls back the transaction to the savepoint and undoes all of the changes
performed by the transaction if it meets an error or is aborted.
 To reflect the fact that the transaction was rolled back, the DBMS also updates the
transaction log.
After a failure, the database may be returned to a consistent state by using the potent rollback
mechanism. If the big transactions are involved then it definitely reduces the performance. In
order to reduce the need for rollback, it's crucial to utilise it sparingly and optimise the
database design and transaction processing.

2. Checkpoint:
A checkpoint is a database recovery technique that stores the database's current state to a
reliable storage medium, such a hard drive, to guarantee recoverability. The checkpoint
procedure comprises updating the log file and writing all updated pages to disc. In the case of
power or any other failure, the recovery procedure may begin from the previous checkpoint.
The main function of checkpoint is to minimise the amount of effort required during recovery
in the case of a failure. The checkpoint assures that all changes made to the database up to
that point are robust and recoverable by writing the database's current state to disc. As a
result, in the case of a failure, the recovery procedure may begin at the most recent
checkpoint rather than from the beginning of the transaction log.
Here's how the checkpoint technique works:
 The DBMS periodically triggers a checkpoint to save the current state of the database
to a stable storage device.
 During the checkpoint, the DBMS writes all the modified pages to disk and updates
the log file to indicate the checkpoint position.
 After the checkpoint is completed, the DBMS can discard the log records before the
checkpoint position, since they are no longer needed for recovery.
 If a failure occurs, the recovery process starts from the last checkpoint, and the DBMS
only needs to apply the log records after the checkpoint position.

The needs of the application and the system's features determine how frequently checkpoints
are made. The number of transactions completed, the volume of data updated, or the duration
of time from the previous checkpoint can all be used to determine when a checkpoint should
be made. To balance the recovery time and the performance overhead of the checkpoint
procedure, the checkpoint frequency must be properly used.
3. Redo:
Redoing is the process of replaying the changes made by committed transactions from the
transaction log to the database when a failure has occurred. By doing this, the database is
guaranteed to be restored to the condition it was in before to the failure.
A transaction is generally regarded as committed when the DBMS has made sure that the
changes made by the transaction have been recorded in the transaction log and the database
has been updated appropriately. The DBMS uses the information in the transaction log to
reapply the changes to the database in the case of a failure.
Here's how the redo technique works:
 When a transaction is committed, the DBMS writes the transaction's changes to the
transaction log, along with a commit record.
 If a failure occurs, the DBMS checks the transaction log to identify the last committed
transaction before the failure.
 The DBMS then replays the changes made by the committed transactions from the
transaction log to the database.
 Once the redo process is completed, the database is restored to the state it was in at
the time of the last committed transaction.

An advanced technique called redo can guarantee that the database is recovered
consistently after failure. But it can also take a while, mainly if there are many transactions to
replay. As a result, optimizing transaction processing and database architecture is critical to
lessen the need for redos and speed up recovery at the time of failure.

4. Undo
A transaction that failed or was aborted can be reversed as part of an undo database recovery
strategy. By reversing the consequences of the failed transaction, it is used to return the
database to a consistent state.
A transaction is often a sequence of actions carried out as a single piece of labour. The
database management system (DBMS) records the alterations that a transaction makes to the
database as it is carried out. The DBMS utilises the data in the transaction log to reverse the
changes made by the transaction if it fails or must be cancelled due to an error.
Here's how the undo technique works:
 When a transaction starts, the DBMS creates a savepoint, which is a point in the
transaction where it can be rolled back to.
 If the transaction encounters an error or is aborted, the DBMS uses the information in
the transaction log to undo the changes made by the transaction up to the savepoint.
 The DBMS updates the transaction log to record the fact that the transaction was
undone.
 Once the undo process is completed, the database is restored to the state it was in
before the failed transaction started.
After a failure, the database may be restored to a consistent form using the potent method of
undo. But, this method can also reduce the performance for the large number of transactions.
In order to reduce the need for undo, it's crucial to utilize it sparingly and optimize the
database design and transaction processing.

5. Log based Recovery in DBMS

The atomicity property of DBMS states that either all the operations of transactions must be
performed or none. The modifications done by an aborted transaction should not be visible to
the database and the modifications done by the committed transaction should be visible. To
achieve our goal of atomicity, the user must first output stable storage information describing
the modifications, without modifying the database itself. This information can help us ensure
that all modifications performed by committed transactions are reflected in the database. This
information can also help us ensure that no modifications made by an aborted transaction
persist in the database.

Log based Recovery in DBMS

Log and log records

The log is a sequence of log records, recording all the updated activities in the database. In
stable storage, logs for each transaction are maintained. Any operation which is performed on
the database is recorded on the log. Prior to performing any modification to the database, an
updated log record is created to reflect that modification. An update log record represented
as: <Ti, Xj, V1, V2> has these fields:
1. Transaction identifier: Unique Identifier of the transaction that performed the write
operation.
2. Data item: Unique identifier of the data item written.
3. Old value: Value of data item prior to write.
4. New value: Value of data item after write operation.
Other types of log records are:
1. <Ti start>: It contains information about when a transaction Ti starts.
2. <Ti commit>: It contains information about when a transaction Ti commits.
3. <Ti abort>: It contains information about when a transaction Ti aborts.
Undo and Redo Operations
Because all database modifications must be preceded by the creation of a log record, the
system has available both the old value prior to the modification of the data item and new
value that is to be written for data item. This allows system to perform redo and undo
operations as appropriate:
1. Undo: using a log record sets the data item specified in log record to old value.
2. Redo: using a log record sets the data item specified in log record to new value.
The database can be modified using two approaches –
1. Deferred Modification Technique: If the transaction does not modify the database
until it has partially committed, it is said to use deferred modification technique.
2. Immediate Modification Technique: If database modification occurs while the
transaction is still active, it is said to use immediate modification technique.

Recovery using Log records

After a system crash has occurred, the system consults the log to determine which
transactions need to be redone and which need to be undone.
1. Transaction Ti needs to be undone if the log contains the record <Ti start> but does
not contain either the record <Ti commit> or the record <Ti abort>.
2. Transaction Ti needs to be redone if log contains record <Ti start> and either the
record <Ti commit> or the record <Ti abort>.
Use of Checkpoints – When a system crash occurs, user must consult the log. In principle,
that needs to search the entire log to determine this information. There are two major
difficulties with this approach:
1. The search process is time-consuming.
2. Most of the transactions that, according to our algorithm, need to be redone have
already written their updates into the database. Although redoing them will cause no
harm, it will cause recovery to take longer.
To reduce these types of overhead, user introduce checkpoints. A log record of the form
<checkpoint L> is used to represent a checkpoint in log where L is a list of transactions active
at the time of the checkpoint. When a checkpoint log record is added to log all the
transactions that have committed before this checkpoint have <Ti commit> log record before
the checkpoint record. Any database modifications made by Ti is written to the database
either prior to the checkpoint or as part of the checkpoint itself. Thus, at recovery time, there
is no need to perform a redo operation on Ti. After a system crash has occurred, the system
examines the log to find the last <checkpoint L> record. The redo or undo operations need to
be applied only to transactions in L, and to all transactions that started execution after the
record was written to the log. Let us denote this set of transactions as T. Same rules of undo
and redo are applicable on T as mentioned in Recovery using Log records part. Note that user
need to only examine the part of the log starting with the last checkpoint log record to find
the set of transactions T, and to find out whether a commit or abort record occurs in the log
for each transaction in T. For example, consider the set of transactions {T0, T1, . . ., T100}.
Suppose that the most recent checkpoint took place during the execution of transaction T67
and T69, while T68 and all transactions with subscripts lower than 67 completed before the
checkpoint. Thus, only transactions T67, T69, . . ., T100 need to be considered during the
recovery scheme. Each of them needs to be redone if it has completed (that is, either
committed or aborted); otherwise, it was incomplete, and needs to be undone.
Log-based recovery is a technique used in database management systems (DBMS) to recover
a database to a consistent state in the event of a failure or crash. It involves the use of
transaction logs, which are records of all the transactions performed on the database.
In log-based recovery, the DBMS uses the transaction log to reconstruct the database to a
consistent state. The transaction log contains records of all the changes made to the database,
including updates, inserts, and deletes. It also records information about each transaction,
such as its start and end times.
When a failure occurs, the DBMS uses the transaction log to determine which transactions
were incomplete at the time of the failure. It then performs a series of operations to undo the
incomplete transactions and redo the completed ones. This process is called the redo/undo
recovery algorithm.
The redo operation involves reapplying the changes made by completed transactions that
were not yet saved to the database at the time of the failure. This ensures that all changes are
applied to the database.
The undo operation involves undoing the changes made by incomplete transactions that were
saved to the database at the time of the failure. This restores the database to a consistent state
by reversing the effects of the incomplete transactions.
Once the redo and undo operations are completed, the DBMS can bring the database back
online and resume normal operations.
Log-based recovery is an essential feature of modern DBMSs and provides a reliable
mechanism for recovering from failures and ensuring the consistency of the database.
Advantages of Log based Recovery
 Durability: In the event of a breakdown, the log file offers a dependable and long-
lasting method of recovering data. It guarantees that in the event of a system crash, no
committed transaction is lost.
 Faster Recovery: Since log-based recovery recovers databases by replaying
committed transactions from the log file, it is typically faster than alternative recovery
methods.
 Incremental Backup: Backups can be made in increments using log-based recovery.
Just the changes made since the last backup are kept in the log file, rather than creating a
complete backup of the database each time.
 Lowers the Risk of Data Corruption: By making sure that all transactions are correctly
committed or cancelled before they are written to the database, log-based recovery lowers
the risk of data corruption.

Disadvantages of Log based Recovery

 Additional overhead: Maintaining the log file incurs an additional overhead on the
database system, which can reduce the performance of the system.
 Complexity: Log-based recovery is a complex process that requires careful
management and administration. If not managed properly, it can lead to data
inconsistencies or loss.
 Storage space: The log file can consume a significant amount of storage space,
especially in a database with a large number of transactions.
 Time-Consuming: The process of replaying the transactions from the log file can be
time-consuming, especially if there are a large number of transactions to recover.
6. Shadow Paging:
In this technique, a shadow copy is used for recovery of the data. In this recovery approach, a
copy of the entire database is created at the start of a transaction, and all modifications are
made to the shadow copy rather than the original database. If all the transaction are
successfully completed, then the shadow copy is deleted, and the original database is
untouched. If the transaction fails or is aborted, the changes in the shadow copy are not
applied to the original database.
Here's how the shadow paging technique works:
 At the start of a transaction, the DBMS creates a shadow copy of the database by
copying all the database pages to a separate area of disk.
 The transaction executes as usual, but all changes made by the transaction are written
to the shadow copy instead of the original database.
 If the transaction is committed, the changes in the shadow copy are applied to the
original database.
 If the transaction is aborted or fails, the shadow copy is simply discarded, and the
original database remains unchanged.
 During recovery, the DBMS simply discards the shadow copy and uses the original
database.

Shadow paging is an easy-to-use recovery method that eliminates the need for complicated
recovery algorithms and can reduce transaction recording costs.
However, maintaining the shadow copy consumes a significant amount of disc space,
particularly for big databases, and can also cause transactions to lag as every database page
must be replicated at the start of a transaction. Therefore, the usage of shadow paging must be
balanced with the requirements of the application and the limitations of the system.

Advantages of Database Recovery Techniques in DBMS

Database recovery techniques in DBMS have several advantages, including:
 Ensuring data integrity: The main objective of database recovery techniques is to
ensure the integrity of the data recorded in the database. This is the main benefit of
using database recovery strategies in DBMS. Redo, undo, and shadow paging are
examples of recovery techniques that are intended to return the database to a
consistent state. These techniques helps in preventing data loss and guaranteeing data
integrity.
 Minimizing downtime: Database recovery techniques are intended to reduce the
downtime brought on by database failures. Recovery strategies can minimise the
 negative effects on business operations and the loss of income and productivity by
recovering from a failure.
 Improving reliability: By guaranteeing that all database changes are documented and
can be retrieved in the case of a failure, recovery strategies like checkpointing and
logging are intended to increase the dependability of the database. This reduces the
possibility of data loss as a result of hardware or software issues.
 Enhancing performance: By lowering the overhead associated with transaction
logging, recovery techniques like shadow paging can improve the performance of
database systems. Due to this, throughput of the database can rise and the system's
responsiveness can be enhanced.
 Providing a consistent view of data: Transactions that were enrolled in process at
the moment of a failure are completed or rolled back using recovery mechanisms.
This makes sure that regardless of the failure, every user sees the data consistently.
Overall, database recovery techniques are essential for ensuring the reliability, availability,
and performance of database systems. By implementing these techniques, organizations can
minimize the impact of failures and ensure that their data remains consistent and accurate.

Disadvantages of Database Recovery Techniques in DBMS

With the advantages of database recovery techniques in DBMS, they also have some
disadvantages, which are discussed below:
 Increased disk space usage: To keep the transaction log or shadow copy of the
database, extra disc space is needed at the time of using recovery strategies like
logging and shadow paging. This may result in higher storage costs, particularly for
sizable datasets.
 Increased overhead: Recovery techniques may increase system overhead, which
may have an impact on performance. For instance, transaction logging adds more disc
I/O operations, which might make the system slower.
 Increased complexity: Recovery procedures may make the system more
complicated, which might make management and upkeep more challenging. For
instance, putting sophisticated recovery algorithms into practice might be difficult and
call for specialized knowledge.
 Recovery time: Depending on the size of the database and the nature of the failure,
recovery time can be significant. This can result in downtime and lost productivity.
 Data inconsistencies: In some cases, recovery techniques may not be able to fully
recover the database to a consistent state. This can result in data inconsistencies that
may be difficult to detect and correct.
Overall, while the advantages of database recovery techniques generally outweigh the
disadvantages, it is important to carefully consider the costs and benefits of implementing
recovery techniques in each specific situation. By carefully balancing the advantages and
disadvantages, organizations can implement recovery techniques that meet their specific
needs and requirements.