Introduction

1. Forward processing - refers to the updates performed when the system is in normal processing, i.e. the updates are not being done by recovery processes
2. Recovery - Process of restoring the database to a consistent state after failure
   • Normal recovery - recovery that takes place during normal processing due to reasons like deadlock, etc.
   • Restart recovery - recovery that takes place when the system crashes
3. LSN (Log Sequence Number) - a unique logical number given to log records. Typically, they are the logical addresses of the corresponding log records.
4. Types of log records
   1. Undo-only log record - log record that contains only undo information
   2. Redo-only log record - log record that contains only redo information
   3. Undo-Redo log record - log record that contains both undo and redo info
5. Types of logging
   1. Value logging - Writing the log such that the log records the values of the database items being updated before and after the transaction.
   2. Operation logging - Writing the log such that the log records operations performed on the database rather than the resulting value
6. WAL (Write Ahead Logging) protocol -
   • the log records representing changes to some data must already be on stable storage before the updates are written to the database
   • an updated page is written to the same place in the system from where it was read
   • in every page, the LSN of the log record that describes the most recent update performed on that page is stored
   • WAL is better than the shadow-paging technique

    
   Figure 1: Shadow-page technique
   

7. Recovering from different types of failures
   • Transaction failure - undo the updates of the transaction
   • System failure - the virtual storage contents would have been lost and the transaction system will have to be restarted and recovery performed using the database and the log
   • Media failure - recover lost image using archive dump and the log
8. Savepoints - point in the transaction state saved by the transaction Checkpoints - point in the database state saved by the transaction processing system
9. Partial rollback - perform rollback till the previous savepoint
   Total rollback - perform complete rollback (undo the effect) of the transaction and terminate the transaction
10. Normal undo - may be caused by a transaction request to rollback or it may be system initiated because of deadlock or errors (eg. violation of integrity constraints)
    Restart undo - refers to transaction rollback during restart recovery or after system failure
11. Page-oriented redo - the redo log record describes the page which was modified originally and the redo is being performed on the same database page
    Logical redo - this refers to redoing a logical operation and hence may require access to several pages and descriptors of the database
    • Page-oriented redo makes the system allow recovery independence amongst objects. That is recovery of one page's contents does not require access to other pages of the database. This makes media recovery very simple.
12. Page-oriented undo - the undo log record describes the page which was modify ed originally and the undo is being performed on the same database page
    Logical undo - this refers to undoing a logical operation and hence may require access to several pages and descriptors of the database
    • Being able to perform logical undos allows the system to provide higher levels of concurrency than what would be possible if the system were restricted to only page-oriented undos
    • ARIES supports page-oriented redo (for efficiency) and logical undo (for high concurrency)
13. CLR (Compensation Log Record)
    • records the updates performed during a rollback
    • a CLR is a REDO-ONLY log record
14. Latches
    • used to guarantee physical consistency of data
    • are cheaper, since all associated information is in memory
15. Locks
    • used to guarantee logical consistency of data
    • all relevant information is maintained in a single, central hash table
    • no. of locks required is several orders of magnitude than no. of latches
16. Hierarchical Locking
    • the intention locks (IS, IX, SIX) are generally obtained on the higher levels of the hierarchy (eg. table) and
    • the nonintention locks (S, X) on lower levels (eg. record)
    • obtaining a nonintention lock mode (S or X) at a certain level of the hierarchy implicitly grants locks of the corresponding mode on lower level objects

     
    Figure 2: Lock Mode Compatibility Matrix
    

17. Lock Request Modes
    • Conditional - requester is not willing to wait if lock is not immediately available
    • Unconditional - requester is willing to wait till lock is available

    Lock Durations

    • Instant - the status of a lock request will be returned only when lock becomes available, till then the lock request result is held back
    • Manual - locks are released some time after they are acquired, but long before the transaction commits
    • Commit - locks are released only when the transaction terminates
18. Buffer Primitives
    1. Fix - used to request the buffer address of a logical page in the DB; if the requested page is not in the buffer pool, the BM (Buffer Manager) allocates a buffer slot and reads the page in. The fix primitive is also used to communicate the intention of modifying the page
    2. Fixnew - used to allocate a new buffer slot if that page is not in the buffer pool
    3. Unfix - make the page (buffer slot) available for replacement
    • Note : Once a page is fixed in the buffer pool, it is not available for replacement
19. Buffer Management Policies
    1. Steal Policy - a page modified by transaction is written to the non-volatile storage before it commits
    2. No-Steal Policy - no page modified by the transaction is written to the non-volatile storage until it commits
    3. Force Policy - the transaction is not allowed to commit until all pages modified by it are written to the non-volatile storage
    4. No-Force Policy - the transaction is allowed to commit even if all the pages modified by it are not written yet to the DB