vault backup: 2024-03-05 13:01:43

2024-03-05 13:01:43 +00:00
parent 8f7a395bdb
commit 8ce640b4ba
44 changed files with 1177 additions and 177 deletions
--- a/Systems/Week
+++ b/Systems/Week
@@ -102,12 +102,149 @@ Several issues that DBMS needs to address
 | T1          | X      |             |
 | T2          | Z      |             |
 | T3          |        | Z           |
+
 ![](Pasted%20image%2020240227161426.png)

-3. ![](Pasted%20image%2020240227161946.png)
+1. ![](Pasted%20image%2020240227161946.png)
 There is no deadlock since there are no cycles.

-4. ![](Pasted%20image%2020240227162324.png)
+2. ![](Pasted%20image%2020240227162324.png)
 There may be a deadlock, since there are multiple cycles in the WFG

 # Database Recovery Part 1
+
+Database recovery is the process of restoring the database to a correct state after a failure
+
+## Types of Failures
+
+- Media Failures
+	- Hard Disk head crashes
+	- Loss of secondary storage
+- System Crashes
+	- Hardware or software errors
+	- Results in loss of primary storage ( RAM )
+- Application software errors
+	- Logical errors in programs that access the database
+	- Causes one or more transactions to fail
+- Carelessness
+	- Unintentional destruction of data by users or operators
+- Sabotage
+	- Intentional corruption or destruction of data, hardware, or software facilities
+- Natural disasters
+	- Fires, floods, solar flares, earthquakes, power failure, bit flips, etc.
+
+## Facilities Required for Recovery
+
+Log File ( Journal )
+
+- Keeps track of transactions and database changes
+Backups / Snapshots
+- Periodic ( Incremental ) copies of database and journal
+Checkpoint facility
+- Used to make recovery more efficient
+DBMS recovery subsystem ( Recovery Manager )
+- Allows system to restore the database to a consistent state during a failure
+
+Just having backups is not a solution if the facility to recover ( backup protocol ) does not exist.
+
+## Buffers
+
+The database buffers occupy an area of primary storage from which data is transferred to and from secondary storage.
+
+Only when buffers have been written to secondary storage can any updates be regarded permanent.
+
+Flushing can be triggered by:
+
+- Commits
+- Buffer full
+
+## Effects of Failure
+
+- Loss of primary storage ( buffer loss )
+- Loss of database on secondary storage
+
+DBMS recovery subsystem uses techniques that minimise effects
+
+## Atomicity and Durability
+
+Recovery manager is responsible for maintaining atomicity and durability of transactions in event of failure.
+
+### Atomicity
+
+All operations of transaction are performed, or none.
+
+- Recovery manager ensures all effects of committed transactions reach the database, and effects of uncommitted transactions are undone or ignored.
+
+### Durability
+
+Effects of committed transactions are permanent
+
+- Effects must survive both loss of RAM and disk storage.
+
+## Recovery Management
+
+### System Failure
+
+- Transaction can commit once writes are made to database buffers.
+- Updates made to buffer are not automatically written to secondary storage.
+- There may be delay between committing and writing to secondary storage
+	- If system fails during this delay, recovery manager must ensure updates reach the copy of the database on secondary storage.
+- If system failure occurs:
+	- Database buffers are lost
+	- Copy of the database on secondary storage may be incorrect.
+
+### Log File ( Journal )
+
+To keep track of database transactions, the DBMS maintains a journal.
+Two or three copies of the log file are kept on secondary storage due to the importance in the recovery process.
+If the system fails, the log file is examined to see which transactions to redo / which transactions to undo or ignore.
+
+#### Contents of Journal
+
+- Transaction identifier
+- Type of log record
+	- Start, insert, update, delete, abort, commit
+- Identifier of data item affected by database action
+	- Insert, delete, update
+- Before Image
+	- Value of data item before operation of log entry
+- After Image
+	- Value of data item after operation of log entry
+- Log management information
+- Checkpoint records
+
+##### Data Entries
+
+`Start_transaction( T )` - Records transaction T starts execution
+`Write_item( T, X, old_value, new_value )` - Records transaction T changes the value of database item X from the before image to the new image.
+`Read_item( T, X )` - Records transaction T reads the value of database item X. Not always logged.
+`Commit( T )` - Records transaction T has completed all accesses to the database successfully and its effect can be recorded permanently to the database.
+`Checkpoint` - Used to make recovery more efficient. Covered in Part 2.
+
+##### Example 1
+
+![](Pasted%20image%2020240227171626.png)
+
+##### Example 2
+
+Schedule:
+![](Pasted%20image%2020240227171700.png)
+Log File:
+![](Pasted%20image%2020240227171728.png)
+
+### Recovery Rules
+
+- Identify transactions that were committed.
+- Undo / Ignore uncommitted transactions, depending on protocol.
+- Redo committed transactions.
+
+#### Undoing Transactions
+
+- If transaction crash occurs, recovery manager may undo transactions.
+- This is achieved by examining the transaction log and for every write entry, setting the value of item X in the database to the old value.
+- Undoing a number of write item operations from one or more transactions from the log must proceed in the reverse order from the order in which the operations appear in the log.
+
+#### Redoing Transactions
+
+- For every write entry in the transaction log, the value of item X in the database is set to the new value.
+- Redoing a number of write operations from one or more transactions from the log must proceed in the same order in which the operations were written in the log.