Recovery of damaged data caused by damage to operation. Data recovery can be done manually and using tools to recover it. Data protection is required by everyone to avoid data corruption and data loss caused by viruses or unexpected conditions. Data recovery is required to recover damaged data for reuse. Assuming the disk space allocated to the database is not damaged, then there are 3 scheme options to run the recovery mechanism automatically once the damage or system failure has occurred. The three schemes of choice are:
Recovery for Concurrent Transactions
a. Interaction with concurrency control
This recovery scheme will depend a lot on the concurrency control scheme used. To run the rollback against a failed/canceled transaction, we must cancel the changes that have been made by the transaction.
If a T transaction has changed a Q data item, no other transaction may change the same data item until T has been committed or rolled back. We can guarantee this by utilizing the Strict Two-Phase Protocols, which apply locking in exclusive mode until the end of the transaction.
b. Restart recovery
When the system performs data recovery, it forms two lists. The first is a list of undo (undo-lists) consisting of transactions that must be subject to undo operations and redo lists that contain transactions that must be subject to redo operations.
These two lists are formed for the following recovery process. At first the two lists are empty. We do a backward search of the log file, check the record until it finds <checkpoint>:
When all the records specified in the log file have been checked, we check the contents of the L list in the checkpoint record. For every transaction Ti in L, if Ti is not in redo-list then we add Ti in undo-list. Once the two lists have been established, then the recovery process will be done with the following steps:
After all transactions in the undo-list have been subject to undo operations, then redo-list transactions are also subject to redo operations.
Backup Operation
Disk damage (which is the most common type of permanent storage medium), data corruption due to user activity or data damage by external applications, can be anticipated by performing periodic backup operations. Running backup operations on a regular basis is an important database management task.
Based on the time of implementation or strategy, there are 2 types of backup operations that we can choose, namely:
Remote Backup System
Another alternative in addition to the application of distributed databases above is to run transaction processing on a site called the primary / primary site, but by having a site for remote backups, where all data from the main site is replicated. Remote backup sites are sometimes referred to as secondary sites. The remote backup site must be continuously synchronized with the primary site, as soon as the primary site changes. The remote backup site must physically be separate from the primary site.
Some of the issues we need to look at when designing a system with remote backups are:
• Damage Detection
• Transfer Control
• Time for Recovery
• Time for Commit
- Log Files with Deferred Update (Incremental Log With Deferred Update)
- Log Files with Direct Changes (Incremental Log With Immediate Updates)
- Shadow Paging (Shadow Paging), which requires access to fewer discs.
Recovery for Concurrent Transactions
a. Interaction with concurrency control
This recovery scheme will depend a lot on the concurrency control scheme used. To run the rollback against a failed/canceled transaction, we must cancel the changes that have been made by the transaction.
If a T transaction has changed a Q data item, no other transaction may change the same data item until T has been committed or rolled back. We can guarantee this by utilizing the Strict Two-Phase Protocols, which apply locking in exclusive mode until the end of the transaction.
b. Restart recovery
When the system performs data recovery, it forms two lists. The first is a list of undo (undo-lists) consisting of transactions that must be subject to undo operations and redo lists that contain transactions that must be subject to redo operations.
These two lists are formed for the following recovery process. At first the two lists are empty. We do a backward search of the log file, check the record until it finds <checkpoint>:
- For each record found in the form <Ti commit>, we add Ti in the redo-list.
- For each record found in the form <Ti start>, if Ti is not in the redo-list, we add Ti in the undo-list.
When all the records specified in the log file have been checked, we check the contents of the L list in the checkpoint record. For every transaction Ti in L, if Ti is not in redo-list then we add Ti in undo-list. Once the two lists have been established, then the recovery process will be done with the following steps:
- Repeat backtrack log file from last record, and run undo operation for each record in log file which has transaction Ti on undo-list. Record-record transactions in the redo-list are ignored in this phase. Searches are stopped when the record <Ti start> is found for each Ti transaction in the undo list.
- Look for the last <checkpoint L> record in the log file. Note that this step may involve advanced search, if the checkpoint record has been skipped in step 1.
- Perform a forward scan of the log file of the last <checkpoint L> record and run redo operation for each record in the log file owned by the Ti transaction which is in the redo-list. In this phase, ignore all records of transactions that are in the undo list.
After all transactions in the undo-list have been subject to undo operations, then redo-list transactions are also subject to redo operations.
Backup Operation
Disk damage (which is the most common type of permanent storage medium), data corruption due to user activity or data damage by external applications, can be anticipated by performing periodic backup operations. Running backup operations on a regular basis is an important database management task.
Based on the time of implementation or strategy, there are 2 types of backup operations that we can choose, namely:
- Static Backup, where backups are performed by first disabling the database as a whole.
- Dynamic Backup, where backups are performed without database deactivation (so the user can still work).
Remote Backup System
Another alternative in addition to the application of distributed databases above is to run transaction processing on a site called the primary / primary site, but by having a site for remote backups, where all data from the main site is replicated. Remote backup sites are sometimes referred to as secondary sites. The remote backup site must be continuously synchronized with the primary site, as soon as the primary site changes. The remote backup site must physically be separate from the primary site.
Some of the issues we need to look at when designing a system with remote backups are:
• Damage Detection
• Transfer Control
• Time for Recovery
• Time for Commit
Advertisement
No comments