Home » DBMS

Database Recovery Techniques | DBMS

DBMS | Database Recovery Techniques: In this tutorial, we will learn about the database recovery techniques like crash recovery, log-based recovery, etc., with the help of examples in the database management system. By Anushree Goswami Last updated : May 31, 2023

Database Recovery

Database Recovery is a process of recovering or restoring data in the database when a data loss occurs or data gets deleted by system crash, hacking, errors in the transaction, damage occurred coincidentally, by viruses, sudden terrible failure, commands incorrect implementation, etc. Data loss or failures happen in databases like other systems but the data stored in the database should be available whenever it's required. For fast restoration or recovery of data, the database must hold tools which recover the data efficiently. It should have atomicity means either the transactions showing the consequence of successful accomplishment perpetually in the database or the transaction must have no sign of accomplishment consequence in the database.

From any failure set of circumstances, there are both voluntary and involuntary ways for both, backing up of data and recovery. So, recovery techniques which are based on deferred update and immediate update or backing up data can be used to stop loss in the database.

Database Recovery Techniques

1. Crash Recovery

Crash recovery is the operation through which the database is transferred back to a compatible and operational condition. In DBMS, this is performed by rolling back insufficient transactions and finishing perpetrated transactions that even now existed in memory when the crash took place.

With many transactions being implemented with each second shows that, DBMS may be a tremendously complex system. The fundamental hardware of the system manages to sustain robustness and stiffness of software which depends upon its complex design. It’s anticipated that the system would go behind with some methodology or techniques to restore lost data when it fails or crashes in between the transactions.

Classification of failure

The following points are the generalization of failure into various classifications, to examine the source of a problem,

1. Transaction failure: a transaction has to terminate when it arrives at a point from where it can’t extend any further and when it fails to implement the operation.
   Transaction failure reasons could be,
   • Logical errors: The errors which take place in some code or any intrinsic error situation, where a transaction cannot properly fulfill.
   • System errors: The errors which take place when the database management system is not able to implement the active transaction or it has to terminate it because of some conditions in a system.
2. System Crash: There are issues which may stop the system unexpectedly from outside and may create the system condition to crash. For example, disturbance or interference in the power supply may create the system condition of fundamental hardware or software to crash or failure.
3. Disk Failure: Disk failures comprise bad sectors evolution in the disk, disk inaccessibility, and head crash in the disk, other failures which damage disk storage completely or its particular parts.

Storage structure

The storage structure can be classified into two following categories,

• Volatile storage: A volatile storage cannot hold on crashes in the system. These devices are located within reach of CPU. Examples of volatile storage are the main memory and cache memory.
• Non-volatile storage: A non-volatile storage are created to hold on crashes in the system. These devices are enormous in the magnitude of data storage, but not quick in approachability. Examples of non-volatile storage are hard-disks, magnetic tapes, flash memory, and RAM.

Recovery and Atomicity

To recover and also to sustain the transaction atomicity, there are two types of methodology,

• Sustaining each transaction logs and before actually improving the database put them down onto some storage which is substantial.
• Sustaining shadow paging, in which on a volatile memory the improvements are completed and afterward, the real database is reformed.

2. Log-based Recovery

The log is an order of sequence of records, which sustains the operations record accomplished by a transaction in the database. Before the specific changes and improvements survive on a storage media which is stable and failing securely, it’s essential that the logs area unit put down in storage.

Following are the workings of Log-based Recovery,

The log file is not damaged on a stable storage media.

Log-based recovery puts down a log regarding a transaction when a transaction begins to be involved in the system and starts implementation.

Recovery with Concurrent Transactions

The logs are interleaved, when multiple transactions are being implemented in collateral. It would be difficult for the system of recovery to make an order of sequence of all logs again, and then start recovering at the time of recovery. Most recent times Database systems use the abstraction of 'checkpoints' to make this condition uncomplicated.

Checkpoint

The checkpoint is an established process where all the logs which are previously used are clear out from the system and stored perpetually in a storage disk. Checkpoint mention a point before which the DBMS was in a compatible state, and all the transactions were perpetrated.