Heading

Database failures usually occur due to the malfunctioning of the database software. The database failures can be classified into three types:

i. System Crash
A System crash occurs due to the failure of the operating system or due to hardware malfunctioning. A system crash can lead to loss of volatile memory or can bring transactions to a halt.
ii. Disk Failure
Disk failure is caused due to some failure in the hard-disk drives or the other storage devices. Disk failure occurs when a certain portion of the hard disk is inaccessible due to formation of bad sectors. Disk failure leads to loss of data from the disk. Disk failure may also be called ‘media failure’.
iii. Transaction Failure
When a process or a transaction abruptly stops at some point in the middle during execution and is unable to proceed further, a transaction failure is said to have occurred. Transaction failure occurs when sufficient resources are not available for the transaction.
iv. Statement Failure
Statement failure occurs when the Database Management System is unable to execute the SQL Statements. When the statement failure occurs, the output of the SQL queries will be corrupted or misleading.
v. Application Software Failure
Application software error occurs due to some internal error or due to malicious code. It may also occur due to logical errors in the code. Application software failure can be avoided by using an error-free and optimized software code.

After a database failure has occurred, the database must be recovered and restored.
The following are the different database recovery techniques:

i. Manual reprocessing
Manual reprocessing is done by backing up the database periodically. If a database failure occurs, the back-up is restored. All the transactions performed on the database before the failure, are applied again.
ii. Recovery using system log
A system log is a file which records all the changes made to the database by the transaction operations. If a transaction fails before reaching commit, all the changes made by that particular transaction can be rolled back to undo their effect on the database. Hence, the database can be recovered from the failure.
iii. Deferred update
In deferred update, all the changes made by a transaction is updated only after it reaches the commit point. Before reaching the commit point, all the updates are stored in a local workspace. Hence, there is no need to roll back the changes made by an incomplete transaction.
iv. Immediate update
In immediate update method, the transaction makes changes to the database before reaching the commit point. But, if a transaction fails, all the updates made by that transaction in the database must be rolled back.
v. Caching
The DBMS cache is an in-memory buffer which is maintained by the DBMS. Some disk pages are cached into the main memory. If the cached disk pages are updated in main memory, it is indicated by the dirty bit. If the dirty bit associated with the cache is 1, it indicates that the page has been modified and vice versa. The modified data in the main memory is then updated to the database.
vi. Shadow paging
Shadow paging is a technique which is used to prevent transaction failures in the database. A shadow copy of the database is maintained in the primary memory until all the transactions are complete. Once all the transaction operations are completed, the data will be updated to the original database. So, if a transaction failure occurs, it will not affect the database. Shadow paging technique enables us to achieve atomicity of transactions.

Shadow paging is a technique which is used to prevent transaction failures in the database. A shadow copy of the database is maintained in the primary memory until all the transactions are complete. Once all the transaction operations are completed, the data will be updated to the original database. So, if a transaction failure occurs, it will not affect the database. Shadow paging technique enables us to achieve atomicity of transactions.