vault backup: 2024-03-05 16:01:50

2024-03-05 16:01:50 +00:00
parent 8ce640b4ba
commit 28ea6a0a9b
36 changed files with 314 additions and 89 deletions
--- a/Systems/Week
+++ b/Systems/Week
@@ -0,0 +1,90 @@
+# [Undoing & Redoing Transactions](Semester%202/Database%20Systems/Week%207/Week%207%20Database%20Systems.md####Undoing%20Transactions)
+
+# Deferred Update Protocol
+
+Updates not written until after transaction has reached commit point.
+If transaction fails before committing, no modification is made to database, hence no undoing is required.
+May be necessary to redo updates of committed transactions as effect may not have reached database.
+
+## Procedure
+
+Redo transaction is both \<T1 start> and \<T1 commit> are present in the log
+
+### Example
+
+![](Pasted%20image%2020240305130824.png)
+Failure in different places:
+![](Pasted%20image%2020240305131110.png)
+In case(a), no commit is present, so no redo or undo is required.
+case(b), T0 commits, but T1 does not, hence T0 is redone.
+case(b), T0 and T1 commits, so both are redone.
+
+# Immediate Update Protocol
+
+Updates applied as they occur.
+Following a failure, redo updates of committed transactions.
+Undo effects of transactions uncommitted.
+If no commit record, transacation was active and must be undone.
+Undo operations performed in reverse order in log.
+In recovery, use log to undo or redo.
+
+## Protocol
+
+Undo
+
+- If <Ti,start> is in the log but <Ti,commit> is not then restore the value of all data items updated by Ti to their old values, going backwards from the last log record for Ti.
+Redo
+- If <Ti,start> and <Ti,commit> are both in the log then set the value of all data items updated by Ti to the new values, going forward from the first log record for Ti
+
+### Example
+
+![](Pasted%20image%2020240305134506.png)
+
+# Checkpoints
+
+After failure, may not know how far back to search log.
+Checkpoints limit log searching, made automatically by DBMS
+Creation of checkpoints schedules at predetermined intervals.
+Definition: Checkpoints are points of sync between database and log file. All buffers are written to secondary storage.
+
+## Procedure
+
+1. Write to secondary storage
+	- All log records
+	- All modified buffer blocks to database.
+	- Checkpoint record to log file which contains identities of transactions active at time of checkpoint
+2. Resume processing.
+
+![](Pasted%20image%2020240305134734.png)
+
+### Example 1 ( Immediate )
+
+- Starts at t0, fails at tf.
+- T1 and T6 have to be undone
+- In absence of other info, recovery manager has to redo T2, 3, 4, and 5.
+- ![](Pasted%20image%2020240305134835.png)
+### Example 2 ( serial with checkpoint, Immediate )
+
+- Dotted lines = checkpoints
+- T1 is safe since updates are written to disk
+- T4 needs to be undone
+- T2 and 3 need to be redone
+- ![](Pasted%20image%2020240305134944.png)
+### Example 3 ( concurrent with checkpoint, Immediate )
+
+- T2 and 3 safe since written to disk
+- T1 and 6 need to be undone.
+- Since checkpoint, redo T4 and 5.
+- ![](Pasted%20image%2020240305135043.png)
+# Purpose of Recovery Log File
+
+- Scan log backwards
+- Create undo / redo lists
+- Undo List: Transactions active at time of crash
+	- Perform undo(T) for every transaction in list
+	- Stop when reaching \<T, start> for every transaction in list.
+- Redo List: Transactions committed after last checkpoint
+	- Redo for each transaction in list.
+
+## Example of Log Use ( Immediate )
+![](Pasted%20image%2020240305135229.png)