Atomicity and Durability
Atomicity and Durability
Atomicity deals with these failures:- User aborts transaction (e.g., cancel button)
- System aborts transaction (e.g., deadlock)
- Transaction aborts itself (e.g., unexpected db state)
- System crashes
- Media failure
Log
Log:Append-only sequence of records used to restore database to a consistent state after a failure. Stored on non-volatile device physically separate from the mass storage device that contains database
Update record:
- Appended to log when a transaction updates an item
- Contains before image: value of item prior to update
- Used to restore item when transaction is aborted
- Read operations are not necessarily logged
- Scan log backward; apply "before image" data in each of the transaction’s update records to database items to restore them to their original state.
- Encountering a Begin Record tag terminates scan
Recovery From Crash
Crash:
Active transactions must be identified and aborted when system recovers
Commit and Abort Records identify completed transactions. If, during a backward log scan, the first record encountered for T is an update record, then T was active at time of crash and must be rolled back
Commit
- Transaction is not committed until its commit record is in the log even if the database operations had completed.
- A crash at any time before that causes transaction to be rolled back
Write-Ahead Log
Both the log and database must be updated when a transaction modifies an item. If a crash occurs between updates, abort the transaction- Database updated first - On recovery, item is in the new state but there is no before image to roll it back. Transaction cannot be aborted.
- Log updated first - On recovery, item in old state and before image in log. Use of before image has no effect, but transaction can be aborted
Practical Database Systems
Two writes to mass store for each database update results in intolerable performanceReal world:
- DBMS maintains cache of recently accessed pages in memory. Most accesses are to cache. Pages which have been updated eventually written to disk
- DBMS maintains log buffer in memory. Records appended to buffer until it fills; then buffer written to log
- Maintaining write-ahead feature more complex when buffers taken into account
Media Failure
Durability requires that database be stored redundantly. The log can be used as second copy if :- Update records contain after image (as well as before image): new value of item
- A snapshot, or dump, of the database is periodically stored in non-volatile memory
Checkpoints
After a failure, we may not know how far back in the log to search for redo of transactionsCan limit log searching using checkpoints
Scheduled at predetermined intervals
Checkpoint operations
- Write modified blocks in the database buffers to disk
- Write a checkpoint record to the log-contains the names of all transactions that are active at the time of the checkpoint
- Write all log records now in main memory out to disk
Using Checkpoint Records
When a failure occurs, check the log- If transactions are performed serially
- Find the last transaction that started before the last checkpoint
- Any earlier transaction would have committed previously and would have been written to the database at the checkpoint
- Need only redo the one that was active at the checkpoint (provided it committed) and any subsequent transactions for which both start and commit records appear in the log
- Checkpoint record contains the names of all transactions that were active at checkpoint time
- Redo all those transactions (if they committed) and all subsequent ones that committed
No comments:
Post a Comment