Chapter 17 (TCDS)

Coping With System

Failures
Sukarna Barua
Associate Professor, CSE, BUET
03/20/2024
 

Undo Logging Disadvantages

 Cannot commit transaction without first writing all changes to the disk.
 Commit is slow as all changes must be updated to disk before commit.
 It is often efficient to keep changes in memory for a while.
 Other transactions are also updating.
 Better to write update to disk after changes done by multiple transactions.
 Otherwise disk I/O may need to be done multiple times.

 Alternative to undo logging?

 Use Redo Logging

03/20/2024
 

Redo Logging Rules

 Remember a <> log record for redo logging uses the new value v instead of old value
[which is the case for undo logging]

 Rules for redo logging :

 R1: Before any update X on disk, it is necessary that both the <> and <> appear
on disk.
 R2: COMMIT can be written to disk only after all <> log records written to disk.

 The following order is strictly followed writing updates and log records to disk:
1. The log records <> for each X.
2. The <> log record.
3. The updated elements X.

03/20/2024
 

Redo Logging Rules

 Consider the transaction and the log records for redo logging.
 Note that <> records are ahead of <> log record.
 Note the <> records and <> record is flushed to disk before updated As and Bs are
flushed to disk.

03/20/2024
 

Recovery with redo logging

 Committed vs uncommitted:
 If there is a <>, then T is committed; otherwise uncommitted.
 In redo logging recovery, nothing needs to be done for uncommitted transactions.
[Why?]
 Algorithm for recovery after a system crash:
 Identify all committed transactions.
 Scan the log forward from the beginning. For each log record <> encountered,
perform the following:
 If T is a committed transaction, update X with new value v.
 If T is uncommitted, do nothing.
 For each incomplete transaction, write an <> record and flush the log.
03/20/2024
 Recovery with redo logging
 Analyze the steps performed by recovery manager if the system crashes:
 After <> written to disk
 After <> written to disk
 After <> written to disk

03/20/2024
 

Checkpointing Redo Log

 Algorithm for checkpointing:

 Write a log record <)> where are all active (uncommitted) transactions. Flush the
log.
 Write to disk all DB elements X that were updated but not written to disk.
 X was updated by a transaction committed at the point of writing <> log
record.
 Write an <> log record. Flush the log.

03/20/2024
 

Checkpointing Redo Log

 Example:
 Checkpoint started when was active but committed.
 Element A must be written to disk before <>
is written to disk log.
 Note the log records before <> and
<>. Active transactions were still writing to log.

03/20/2024
 

Recovery With a Checkpointing Redo Log

 Algorithm for recovery:

 Find the last <>log record.
 Scan backward until the corresponding <>is found.
 All transactions committed before <>have their updates sent to disk. [why?]
 We need to consider only as these are uncommitted transactions.
 Neither of these transactions can have <>record <>record [why?]
 Find the earliest value of <>among .
 Start recovery from the earliest <>record.
 Process log records normally going forward.
 Redo all committed transactions thereafter.

03/20/2024
 

Recovery With a Checkpointing Redo Log

 Algorithm for recovery: What if scanning first encounters a record?

 Transactions started before this log record are not guaranteed to have their changes
reflected on disk. [ why? ]
 So scan for the previous <> and matching <>
 And Redo all committed transactions from the earliest start time of .

03/20/2024
 

Recovery With a Checkpointing Redo Log

 Analyze the recovery process for the following scenarios:

 System crashes at the end.
 System crashes between <C0MMIT T2> and <C0MMIT T3>.
 System crashes just prior <END CKPT>.

03/20/2024
 

Undo and Redo Logging Issues

 Undo logging problem: Undo logging requires that data be written to disk after a
transaction committed.
 This increases number of disk I/Os.
 Redo logging problem: Redo logging requires that data be kept in buffers till
transactions is committed.
 This increases average number of buffers required in memory.
 Undo+redo logging: An efficient approach is combining both undo and redo logging
mechanism.
 Requires us to store more information in log records.

03/20/2024
 

Undo/Redo Logging Rules

 Log records in undo/redo logging:

 Log records are of the form <> where is the previous value and is the new value
of .

 Rules for undo/redo logging:

 : Before updating X on disk, update record <> appear on disk.

 Note that there is no constraint on <> log record in undo/redo logging.

 It can appear on disk or after any updated X on disk.

03/20/2024
 Undo/Redo Logging Rules
 Consider the transaction below undo/redo logging.
 Note <COMMIT T> is not flushed while A and B are written to disk.

03/20/2024
 Recovery With Undo/Redo Logging
 Recover process in undo/redo logging:
 Step 1: Redo all the committed transactions in the order earliest-to-latest.
 Step 2: Undo all the uncommitted transactions in the order latest-to-earliest.

 What happens if redo and undo involve transactions modifying same element X?
 Suppose X is modified by and is uncommitted.
 X is modified by and is committed.
 Now, if Step 1 “redo” is done first and then Step 2 “undo” then there is a possibility that ’s
changes will not be reflected.
 Now, if Step 2 “undo” is done first and then Step 1 “redo” then there is a possibility that ’s
changes may not be reflected.

03/20/2024
 Recovery With Undo/Redo Logging
 Analyze the recovery for the following cases:
 Crash occurs after <> flushed to disk.
 Crash occurs before <> flushed to disk.

03/20/2024
 Checkpointing Undo/Redo Log
 Algorithm for checkpointing:
 Write a log record <> where are all active (uncommitted) transactions. Flush this
log.
 Write to disk all DB elements X that were updated but not written to disk.
 Unlike redo logging, flush all dirty buffers! [all buffers updated by both
committed and uncommitted transactions]
 Write an <> log record. Flush the log.

03/20/2024
 Recovery Under Checkpointing

 Analyze recovery under the following:

 Crash occurs after the <>:
 Recovery starts from <>.
[Why not <>?]
 Redo <>.
 Redo <>.
 Crash occurs before <>:
 Redo <>.
 Undo <>.

03/20/2024
 Protect From Media Failures
 Archiving:
 Maintain a copy of the database
 Shutdown the database and copy database state to a backup storage medium such
tape or optical device
 Copy all log files starting from an archived copy.
 The log files can be used to store the database state using archived copy.
 Once log is written to disk, it is also written to an archived medium.
 To prevent from site failure, log can be written to remote site

03/20/2024
 Archiving
 Database archives can be two types:
 Full dump: A full dump in which entire database is copied
 Incremental dump: An incremental dump in which database changed since the
previous full dump are copied.

03/20/2024
 Nonquiescent Archiving
 It is always not possible to shutdown database for archiving.
 Non-quiescent arching can be taken without shutting down the database.
 Algorithm:
 Write a log record <START DUMP>.
 Perform a checkpoint appropriate for whichever logging method is used.
 Perform a full or incremental dump of data disk, making sure the copy of the
database has reached the remote site.
 Make sure enough of the log has been copied to the remote site at least of the log
up to the checkpoint above to survive a media failure of the database.
 Write a log record <END DUMP>.

03/20/2024
 Nonquiescent Archiving
 Example scenario of dump:
 Safe to ignore log records before <START CKPT(T1,T2)>. [why? ]

03/20/2024
 Recovery from archived log
 Step1: Restore the database from the archive.
 Find the most recent full dump and reconstruct the database from it.
 If there are later incremental dump, modify the database according to each, earliest
first.
 Step 2: Modify the database using surviving logs.
 Use the method of recovery appropriate to the log method being used.

 Analyze the recovery:

 When crashes occur at the end of dump?
 Restore database from archive.
 Redo <T2,C,3,6>.
 Undo <T1,A,1,5>.
 Undo <T1,B,2,7>.

03/20/2024