Dbms

-Transaction failure, reasons, system crash, disk failure
-Recovery and atomicity, log based recovery
-Checkpoint and recovery

1. Reasons of transaction failure, system recovery and media recovery - Sandhya Devkota

2. Transaction Failure → The transaction failure occurs when it fails to execute or when it reaches a point from where it cannot go any further. If a few transaction or process is hurt, then this is called as transaction failure. Reasons for a transaction failure could be: Logical error: Transaction cannot complete due to some internal error condition. System errors: The database system must terminate an active transaction due to an error condition (e.g., dead lock) 

3. System Crash → It can occur due to power failure or other hardware/software failure. Example: Operating system error. Disk Failure → It occur where hard disk drives or storage device used to fail frequently. Disk failure occurs due to the formation of bad sectors, disk crash and unreachability to the disk or any other failure which destroy all the part of disk storage.

4. Recovery and Atomicity Recovery: → Recovery is the process of retrieving data from damaged, failed or corrupted storage. Atomicity: → Transaction as a whole must be maintained, that is, either all or none. Example: online shopping or ATM.

5. When a DBMS recovers from a crash, it should maintain the following: It should check the states of all the transactions, which were being executed. A transaction may be in the middle of some operation; the DBMS must ensure the atomicity of the transaction in this case. It should check whether the transaction can be completed now or it need to be rolled back. No transactions would be allowed to leave the DBMS in an inconsistent state.

6. Inconsistent → Data Inconsistent means that different files contain different information of a particular person or object. Example: Consider these two table student and address table. - Student table contains ID, Name, Class and Mobile Number - Address table contains Address of student, ID, District and Mobile Number. In these two tables mobile number column is same. So, same data in the student table will be present in address table. Now one student wants to change his mobile number. The mobile number in student table is updated. So, there is inconsistent between these two data. This term is called data inconsistency.

7. There are two types of techniques, which can help a DBMS in recovering as well as maintaining the atomicity of a transaction. Log-based recovery → It assumes that transactions are executed serially, that means only one transaction is active at a time. It uses a structure called log to store the database modification. Shadow paging → This is the method where all the transactions are executed in the primary memory or the shadow copy of database. Once all the transactions completely executed, it will be updated to the database. Hence, if there is any failure it will not be reflected in the database. Data base will be updated after all transaction is completed.

8. Log-based Recovery → Log is a sequence of record, which maintains the record 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. The database can be modified using two approaches- Deferred database modification – All logs are written on the stable storage and the database is updated when a transaction commits. Immediate database modification – Each log follows an actual database modification. That is, the database is modified immediately after every operation.

9. Recovery with Concurrent Transaction → If it is a case of execution of two or more transactions, the interleaving of logs will occur. It will become very inconvenient for the system of recovery to backtrack every record and start the process of recovering. → Most database management system make use of the concept of “checkpoint” to make the situation more convenient and more manageable.

10. CHECKPOINT → The checkpoint is a type of mechanism where all the previous logs are removed from the system and permanently stored in the storage disk. → The checkpoint is like a bookmark. The checkpoint is used to declare a point before which the DBMS was in the consistent state, and all transactions were committed. During transaction executed, such checkpoints are marked, and after execution, the log files will be created. When it reaches to the checkpoint, then the transaction will be updated into the database, and till the point, the entire log file will be removed from the file. Then the log file is updated with the new step of transaction till next checkpoint and so on.

11. Why do we need checkpoint? → Whenever transaction logs are created in a real-time environment, it eats up lots of storage space. Also keeping track of every update and its maintenance may increase the physical space of the system. Eventually, the transaction log file may not by handled as the size keeps growing. This can be addressed with checkpoints. Advantages of using checkpoints: Speeds up data recovery process. Prevents unnecessary redo operations. Since dirty pages are flushed out continuously in the background, it has very low overhead and can be done frequently.

12. Recovery → Recovery is the process of restoring the database to a correct (consistent) state in the event of a failure. The failure may be result of system crash or system error. Recovery system is used to return the database to the checkpoint state. The behaviour when the system crashes and recovers when concurrent transaction are executed is shown by figure: Checkpoint Failure T1 T2 T3 T4

13. Recovery The recovery system reads log file from the end to start. It reads log files from T4 to T1. It maintains two list, a redo-list, and an undo-list. The transaction is put into redo state if the recovery system sees a log with < Tn , Start> and < Tn , Commit> or just < Tn , Commit>. In the redo-list and their previous list, all the transaction are removed and then redone before saving their logs. For example: In the log file, transaction T2 and T3 will have < Tn , Start> and < Tn , Commit>. The T1 transaction will have only < Tn , Commit> in the log file. That’s why the transaction is committed after the checkpoint is crossed. Hence it puts T1, T2 and T3 transaction into redo list. Te transaction is put into undo state if the recovery system sees a log with < Tn , Start> but no commit or abort log found. In the undo-list, all the transaction are undone, and their logs are removed. For example: Transaction T4 will have < Tn , Start>. So T4 will be put into undo list since this transaction is not yet completed and failed amid

14. THANK YOU SANDHYA DEVKOTA (BBA,III SEM) -Presidency College Of Management Science