Log Based Recovery in DBMS
FREE
Log-based recovery in DBMS provides the ability to maintain or recover data in case of system failure. DBMS keeps a record of every transaction on some stable storage device to provide easy access to data when the system fails. A log file will be created for every operation performed on the database at that point. The original transaction should be processed before it is applied to the database. To understand Log-based recovery in DBMS let us look at an example
Log in DBMS
A log is a series of records. The logs for each transaction are kept in a log file to allow recovery in case of failure. A log is kept for each operation performed on the database. It is important to store the log before the actual transactions are applied to the database. Take the example of modifying a student's City. This transaction produces the following logs.
- A start log is produced when the transaction begins. <Tn, Start>
- A new log is written to the file when the City is changed from Chennai to NCR <Tn, City, 'Chennai', 'NCR' >
- Once the transaction has been completed, another log will be written to indicate that the operation has been completed
How to Perform Log-Based Recovery in DBMS?
The following terms are used for describing log-based recovery.
| Name | Description |
|---|---|
| Transaction identifier | It is an identifier that distinguishes one transaction from another. |
| Data item identifier | It uniquely identifies data. |
| Old value | This is the value of the data item before writing. |
| New value | This is the value of an item after it has been written. |
The different types of log records are denoted by the following names:
| Command | Description |
|---|---|
| <Ti start> | The transaction Ti has begun. |
| <Ti, Xi, V1, V2> | The transaction Ti performed a write operation on item Xi, and Xj contains value v1 before the write and will contain value V2 after it was completed. |
| <Ti commit> | It commits a transaction. |
| <Ti abort> | It aborts a transaction. |
Transactions that perform a write operation to the database only modify it when a log record is created for that write operation. The logs may or may not record the reading of data items. The reason is that reading a data item has no effect on the consistency of the database and is not beneficial to the recovery mechanism.
During the recovery process, we perform two operations:
- Undo(Ti): Restores the old values of each of the items in Ti that have been updated by the transaction Ti.
- Redo(Ti): Updates all data items updated by transaction Ti with their new values. Undoing a T requires the log to contain both the record <start> and the record <commit>.
Approaches to Modify the Database
In the recovery system, we use two different types of medication in the database. They are
Immediate Database Modification
By using immediate updates, the database can be modified and output while still in the active state of the transaction. Data modifications written during an active transaction are referred to as uncommitted modifications.
For consistency reasons, old values of data items should be used if the system crashes or a transaction fails. Undoing an operation is a way to accomplish this. In order for Ti to start its execution, a log entry called <Ti start> is written. A new update record is written to the log before the write(X) operation by Ti is executed. Partially committed Ti records are written to the log as <Ti commit>.
The following are examples of a banking system, the transaction To is followed by the transaction T1. In the case of a system crash right after the log record, and during recovery, we redo (T1) and undo (T1) since the log record includes both <To start> and <To commit>. However, the log record does not contain a <T1 commit> with a <T1 start>. First, we should undo (T1), and then we should redo (To).
Deferred Modification Technique
All database modifications are recorded in the log using the delayed database modification technique to ensure transaction atomicity. As a part of this technique, a transaction is only partially committed when all the written statements are applied to the database. As soon as the final action of an order has been completed, the order is said to be partially committed.
Whenever a partial commit occurs, deferred writes are executed according to the information in the transaction log. The information on the log is ignored if the system crashes before a transaction has been completed or if the transaction aborts. With the log, the system can deal with events that result in a loss of information on volatile storage. The recovery procedure uses the log.
It resets the values of data items that were updated by transaction Ti. The log includes a list of the data items that Ti updated and their new values. Redo transactions must be reversible. Repeating them many times must have the same effect as performing them once.
In the event of a failure, the recovery subsystem consults the log for information about which transactions need to be redone. If the log record includes both <Ti start> and <Ti commit> statements, Transaction Ti is redone.
There is a failure just after the record for step write(B) of transaction To. The recovery process will not perform any redo operations as we only have <To start> in our log record, but not <To commit>.
When a system crash occurs just after writing the log record C, during recovery we do only redo (To), since the log disk only contains data to commit and to start. However, we don't have the <T1 commit> in log disk at the same time, so we can't do the redo (T1).
If the system crashes just after the log record <T1 commit>, then during the recovery we will do both redos (T0) and redos (TI) since we have both <To start> and <To commit> and <T1 start>, <T1 commit> in log disk.
Recovery using Log records
The system uses the log to determine what transactions need to be undone and which need to be re-done if the system crashes.
The log should contain the records <Ti, Start> and <Ti, Commit> or <Ti, Commit>; otherwise, the Transaction Ti should be redone. There should be an undo of Transaction Ti if the log contains the record <Tn, Start> but does not contain the record <Ti, commit> or <Ti, abort>.
Conclusion
- In simple terms, a log is simply a file containing a sequence of records, each record representing a write operation. The log file is a stream of log records. It stores the history of all changes made to the logs.
- Logs contain the start and end of transactions, transaction numbers, record numbers, old value, new value, etc. Examples include mini statements in bank ATMs.
- A log is stored on a disk, so it is independent of disk failure and failures.