Checkpoints Flashcards
Checkpoints
Used to declare a point before which the DBMS was in a consistent state, and all transactions were committed.
Advantages of Checkpoints
- faster recovery
- less space used for log-file
Simple checkpointing
Checkpoint the log periodically.
No need to undo transactions before a checkpoint.
Simple Checkpointing process
- Stop accepting new transactions
- Wait until all active transactions finish and have written commit/abort record on log
- Flush the log to disk
- Write log record checkpoint
- Flush again
- Resume accepting transactions
Transactions interrupting checkpoints
Other transactions cannot interrupt a checkpoint, and the transactions within a checkpoint have to finish before we can start anything else.
ARIES Checkpoints
Two things are required for ARIES checkpoints:
- Undo and redo logging
- Transactions do not write to buffer before they are sure they want to commit
Writing ARIES Checkpoints
We write:
<CHECKPOINT(T1, T2, …)>
in the log and flush it, with these transactions not being committed or aborted as they are in progress.
We then write the content of the buffer to disk.
Then we write
<END>
in the log and flush it.
</END>
How writing ARIES checkpoints work
- we have a checkpoint with a set amount of transactions.
- when using undo/redo, we look for the first checkpoint with a corresponding end checkpoint.
- we check that checkpoint’s transactions to see which ones have committed.
- we then undo to the earliest transaction that has not committed.
Writing checkpoints example
If T1 begins before T2, and neither has committed, we start at T1 and undo both.
However, lets say you have T1 and T2 again, and T2 has committed but T1 has not. We then redo the committed transactionsafter the cehckpoint and undo the uncommitted transactions before the checkpoint.
Conflict serialisability v Recovery
CS:
- equivalent to serial schedules
- ensures consistency and correctness
- can be enforced using two-phase locking
Logging and Recovery:
- ensures we can restore desired database states
- undo incomplete transactions, redo complete transactions
- robust; works even after system failure
Dirty reads
The isolation property is not fully enforced for efficiency reasons, which leads to us reading uncommitted transactions.
Can slow the system when an abort occurs, since you have to rollback multiple transactions (since one transaction reads from another uncommitted one, both may have to be rollbacked).
Cascading Rollbacks
Lets say we have two transactions which happen in a serial manner (T1 -> T2). Both commits happen after T2.
If we have to rollback T1, then if T2 has used something from T1, then we also rollback T2.
The issue is that if we do not rollback everything, it leads to isolation problems.
If we do abort them, we are rolling back a committed transaction, leading to durability breaks.
Recoverable Schedules
A schedule s is recoverable if the following is true:
If a transactions T1 commits and has read item X that was written before by a different transaction T2, then T2 must commit before T1.
Recoverable Schedules Example
Lets say we have:
T2 ; Write X
T1; Read X
T2 ; Commit
SYSTEM ERROR
T1; Commit
If we were to perform cascading rollbacks, since they should only effect active transactions, only T1 will be rolled back. This is not an issue since it is performing the read again with the same data since we committed beforehand.
Cascade-less Schedules
Only reads values that were written by committed transactions.
