DATABASE RECOVERY IN DBMS AND ITS TECHNIQUES
DATABASE RECOVERY IN DBMS AND ITS TECHNIQUES: There can be any case in database system like any computer system when database failure happens. So data stored in database should be available all the time whenever it is needed. So Database recovery means recovering the data when it get deleted, hacked or damaged accidentally. Atomicity is must whether is transaction is over or not it should reflect in the database permanently or it should not effect the database at all. So database recovery and database recovery techniques are must in DBMS. So database recovery techniques in DBMS are given below.
Also See: Keys in DBMS
DBMS may be an extremely complicated system with many transactions being executed each second. The sturdiness and hardiness of software rely upon its complicated design and its underlying hardware and system package. If it fails or crashes amid transactions, it’s expected that the system would follow some style of rule or techniques to recover lost knowledge.
DATABASE RECOVERY IN DBMS AND ITS TECHNIQUES
Classification of failure:
To see wherever the matter has occurred, we tend to generalize a failure into numerous classes, as follows:
- Transaction failure
- System crash
- Disk failure
- Transaction failure: A transaction needs to abort once it fails to execute or once it reaches to any further extent from wherever it can’t go to any extent further. This is often known as transaction failure wherever solely many transactions or processes are hurt. The reasons for transaction failure are:
- Logical errors
- System errors
- Logical errors: Where a transaction cannot complete as a result of its code error or an internal error condition.
- System errors: Wherever the information system itself terminates an energetic transaction as a result of the DBMS isn’t able to execute it, or it’s to prevent due to some system condition. to Illustrate, just in case of situation or resource inconvenience, the system aborts an active transaction.
- System crash: There are issues − external to the system − that will cause the system to prevent abruptly and cause the system to crash. For instance, interruptions in power supply might cause the failure of underlying hardware or software package failure. Examples might include OS errors.
- Disk failure: In early days of technology evolution, it had been a typical drawback wherever hard-disk drives or storage drives accustomed to failing oftentimes. Disk failures include the formation of dangerous sectors, unreachability to the disk, disk crash or the other failure, that destroys all or a section of disk storage.
Also See: Concurrency Control in DBMS
Classification of storage structure is as explained below:
- Volatile storage: As the name suggests, a memory board (volatile storage) cannot survive system crashes. Volatile storage devices are placed terribly near to the CPU; usually, they’re embedded on the chipset itself. For instance, main memory and cache memory are samples of the memory board. They’re quick however will store a solely little quantity of knowledge.
- Non-volatile storage: These recollections are created to survive system crashes. they’re immense in information storage capability, however slower in the accessibility. Examples could include hard-disks, magnetic tapes, flash memory, and non-volatile (battery backed up) RAM.
Recovery and Atomicity:
When a system crashes, it should have many transactions being executed and numerous files opened for them to switch the information items. Transactions are a product of numerous operations that are atomic in nature. However consistent with ACID properties of a database, atomicity of transactions as an entire should be maintained, that is, either all the operations are executed or none.
When a database management system recovers from a crash, it ought to maintain the subsequent:
- It ought to check the states of all the transactions that were being executed.
- A transaction could also be within the middle of some operation; the database management system should make sure the atomicity of the transaction during this case.
- It ought to check whether or not the transaction is completed currently or it must be rolled back.
- No transactions would be allowed to go away from the database management system in an inconsistent state.
Also See: What is Deadlock in DBMS
There are 2 forms of techniques, which may facilitate a database management system in recovering as well as maintaining the atomicity of a transaction:
- Maintaining the logs of every transaction, and writing them onto some stable storage before truly modifying the info.
- Maintaining shadow paging, wherever the changes are done on a volatile memory, and later, and the particular info is updated.
Log-based recovery Or Manual Recovery):
Log could be a sequence of records, which maintains the records of actions performed by dealing. It’s necessary that the logs area unit written before the particular modification and hold on a stable storage media, that is failsafe. Log-based recovery works as follows:
- The log file is unbroken on a stable storage media.
- When a transaction enters the system and starts execution, it writes a log regarding it.
Recovery with concurrent transactions (Automated Recovery):
When over one transaction is being executed in parallel, the logs are interleaved. At the time of recovery, it’d become exhausting for the recovery system to go back all logs, and so begin recovering. To ease this example, the latest package uses the idea of ‘checkpoints’. Automated Recovery is of three types
Deferred Update Recovery
Immediate Update Recovery
So it was all about DATABASE RECOVERY IN DBMS AND ITS TECHNIQUES, if you lied this post then please share it with your friends.