With hundreds of transactions being executed every second, DBMS is a highly complex system. A DBMS 's durability and robustness depend on its complex architecture and the hardware and system software underlying it. If it fails or crashes in the middle of transactions, it is assumed some kind of algorithm or techniques to recover lost data will be followed by the system.
We make generalizations a failure into various categories, as follows, to see where the problem has occurred.
When it fails to execute or when it reaches a point from which it can't go any further, a transaction has to abort. This is called a failure of a transaction where only a few transactions or processes are hurt.
Reasons for a failure of a transaction may be-
Within the system, there are problems that can cause the system to stop suddenly and cause the system to crash. For instance, power supply interruptions can cause the failure of underlying hardware or software failure.
Examples may include errors with the operating system.
It was a common issue in the early days of technological evolution, where hard disk or storage drives used to fail frequently.
Disk failures include bad sector creation, disk lack of access, disk head crash, or any other failure that destroys all or part of the disk storage.
We have the storage system mentioned already. In brief, the structure of storage can be split into two categories:
When a system crashes, multiple transactions may be executed and different files may be opened for them to modify the data items. Transactions are made of different operations, which are atomic in nature. However, according to DBMS' ACID properties, the atomicity of transactions as a whole must be retained, i.e. if all or none of the operations are performed.
When a DBMS recovers from a crash, the following should be maintained:
There are two types of techniques, which can aid a DBMS in recovering as well as preserving the atomicity of a transaction −
Log is a sequence of records, which maintains the records of actions performed by a transaction. It is important that the logs are written prior to the actual modification and stored on a stable storage media, which is failsafe.
Recovery based on logs works as follows-
<Tn, X, V1, V2>
It reads Tn has changed the value of X, from V1 to V2.
Two approaches can be used to modify the database.
The logs are interleaved when more than one transaction is executed in parallel. It would become difficult for the recovery system to backtrack all logs at the time of recovery, and then start recovering. Most modern DBMS use the 'checkpoints' concept to ease this situation.
All the memory space available in the system can be used out by keeping and storing logs in real time and in various systems. The log file may grow too big to be handled at all as time passes. Checkpoint is a process that eliminates from the system all previous logs and permanently stores them in a storage disk. Checkpoint declares that the DBMS was in a consistent state until the point at which all transactions were committed.
When a system crashes and recovers with concurrent transactions, it acts in the following way:
All the undo-list transactions are then undone and their logs are removed. Before saving their logs, all the transactions in the redo-list and their previous logs are removed and then redone.