Recovery and Atomicity
When we modify the database without ensuring that the transaction will commit it may leave the database in an inconsistent state. For example: Consider a transaction Ti that transfers $50 from account A to account B. Now the goal is either to perform all the database modifications made by Ti or none at all. Several output operations may be required for Ti (to output A and B). A failure may occur after one of these modifications have been made but before all of them are made.To ensure atomicity despite the failures, we first output information describing the modifications to the stable storage without modifying the database itself. We study two approaches and they are Log-based recovery and Shadow-paging. We assume that the transactions run serially that is one after the another.
Summary
When we modify the database without ensuring that the transaction will commit it may leave the database in an inconsistent state. For example: Consider a transaction Ti that transfers $50 from account A to account B. Now the goal is either to perform all the database modifications made by Ti or none at all. Several output operations may be required for Ti (to output A and B). A failure may occur after one of these modifications have been made but before all of them are made.To ensure atomicity despite the failures, we first output information describing the modifications to the stable storage without modifying the database itself. We study two approaches and they are Log-based recovery and Shadow-paging. We assume that the transactions run serially that is one after the another.
Things to Remember
- When we modify the database without ensuring that the transaction will commit it may leave the database in an inconsistent state
- For example: Consider a transaction Ti that transfers $50 from account A to account B.
- Now the goal is either to perform all the database modifications made by Ti or none at all.
- Several output operations may be required for Ti (to output A and B). A failure may occur after one of these modifications have been made but before all of them are made.
- To ensure atomicity despite the failures, we first output information describing the modifications to the stable storage without modifying the database itself.
- We study two approaches and they are Log-based recovery and Shadow-paging. We assume that the transactions run serially that is one after the another.
MCQs
No MCQs found.
Subjective Questions
No subjective questions found.
Videos
No videos found.
Recovery and Atomicity
Recovery and Atomicity
When we modify the database without ensuring that the transaction will commit it may leave the database in an inconsistent state. For example,
Consider a transaction Ti that transfers $50 from account A to account B. Now the goal is either to perform all the database modifications made by Ti or none at all. Several output operations may be required for Ti (to output A and B). A failure may occur after one of these modifications have been made but before all of them are made.To ensure atomicity despite the failures, we first output information describing the modifications to the stable storage without modifying the database itself.
We study two approaches:
- Log-based recovery, and
- Shadow-paging.
We assume that the transactions run serially that is one after the another.
The given two approaches will be discussed in the next chapter.
References:
- H.F.Korth and A. Silberschatz,"Database system concepts",McGraw Hill,2010
- A.K.Majumdar and p, Bhatt acharya,"Database Management Systems",Tata McGraw Hill,India,2004
- F.Korth, Henry. Database System Concepts. 6th edition.
Lesson
Crash Recovery
Subject
Computer Engineering
Grade
Engineering
Recent Notes
No recent notes.
Related Notes
No related notes.