Database Recovery Techniques in DB! ‘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 ot 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 seneral, database recovery involves the following three main steps: 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 ing 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. Rollbacl 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 retuned 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 dise. 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. + Ifa failure occurs, the recovery process starts from the last checkpoint, and the DBMS only needs to apply the log records after the checkpoint position. Checkpoint Failure u 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. + Ifa 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. Dante 7 shove changes Dastaie 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 retum 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 1 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 w: before the failed transaction started. a savepoint, which is a point in the sin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 File l 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: has these fields:1, Transaction identifier: Unique Mdentifier of the transaction that performed the write operation. Data item: Unique identifier of the data item written. Old value: Value of data item prior to write, New value: Value of data item after write operation. \ther types of log records are: : It contains information about when a transaction Ti starts. : It contains information about when a transaction Ti commits. 3. : 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, itis 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. RroReN 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 or the record or the record . 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 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 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, Tl, . . ., 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 modem 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. Current Directory Shadow Directory Fig Shadow Paging Scheme 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 1g 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 VO 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