Chapter 17 (TCDS)

Coping With System

Failures
Sukarna Barua
Associate Professor, CSE, BUET
2/11/2024
 Undo Logging Disadvantages
▪ Cannot commit transaction without first writing all changes to the disk.
▪ 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

▪ Solution?
▪ Use Redo Logging

2/11/2024
 Redo Logging Rules
▪ Remember a <T,X,v> 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 <T,X,v> and
<COMMIT T> appear on disk.
▪ R2: COMMIT can be written to disk only after all <T,X,v> log records written to
disk.

▪ The following order is strictly followed writing updates and log records to disk:
1. The log records <T,X,v> for each X.
2. The COMMIT log record.
3. The changed elements X.
2/11/2024
 Redo Logging Rules
▪ Consider the transaction and the log records for redo logging.
▪ Note that <T,X,v> records are ahead of <COMMIT T> log record.
▪ Note the <T,X,v> records and <COMMIT T> record is flushed to disk before
updated A and Bs are flushed to disk.

2/11/2024
 Recovery with redo logging
▪ Committed or Uncommitted? If there is a <COMMIT T>, 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 <T,X,v>
encountered:
▪ If T is a committed transaction, update X with new value v.
▪ If T is uncommitted, do nothing.
▪ For each incomplete transaction, write an <ABORT T> record and flush the log.

2/11/2024
 Recovery with redo logging
▪ Analyze the steps performed by recovery manager if the system crashes:
▪ After <START T> written to disk
▪ After <COMMIT T> written to disk
▪ After <T,A,16> written to disk

2/11/2024
 Checkpointing Redo Log
▪ Algorithm for checkpointing:
▪ Write a log record <START CKPT(T1,T2,…,TK)> where T1, T2,..,Tk are all
active (uncommitted transactions). Flush this 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 <START …>
log record.
▪ Write an <END CKPT> log record. Flush the log.

2/11/2024
 Checkpointing Redo Log
▪ Example:
▪ Checkpoint started when T2 was active but T1 committed.
▪ Element A must be written to disk before <END CKPT>
is written to disk log.
▪ Note the log records before <START …> and
<END CKPT>. Active transactions were still writing to log.

2/11/2024
 Recovery With a Checkpointing Redo Log
▪ Algorithm for recovery:
▪ Find the last <END CKPT> log record.
▪ Scan backward until the corresponding <START CKPT(T1,T2,..,Tk) is found.
▪ All transactions committed before <START CKPT...> have their updates sent
to disk. [why?]
▪ We need to consider only T1,T2,..,TK as these are uncommitted transactions.
▪ Neither of these transactions can have <COMMIT T> record before <START
CKPT..> record [why?]
▪ Find the earliest value of <START T_i> among T1,T2,…,TK.
▪ Start recovery from the earliest <START T_i> record.
▪ Process log records normally going forward.
▪ Redo all committed transactions thereafter.

2/11/2024
 Recovery With a Checkpointing Redo Log
▪ Algorithm for recovery:
▪ What is scanning first encounters a <START CKPT …> record?
▪ Transactions started before this are not guaranteed to have their changes reflected
on disk. [ why? ]
▪ So scan for the previous <END CKPT> and matching <START CKPT(T1,T2,…>
▪ And Redo all committed transactions from the earliest start time of T1, T2, …, TK

2/11/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>.

2/11/2024
 Undo and Redo Logging Issues
▪ Undo logging requires that data be written to disk after a transaction committed.
▪ This increases number of disk I/Os.

▪ Redo logging requires that data be kept in buffers till transactions is committed.
▪ This increases average number of buffers required in memory.

▪ An efficient approach is combining both undo and redo logging mechanism

▪ Requires us to store more information in log records.

2/11/2024
 Undo/Redo Logging Rules
▪ Log records:
▪ Similar to before except that update log records are of the form <T,X,v,w> where v
is the previous value and w is the new value of X.

▪ Rules for undo/redo logging:

▪ UR1: Before updating X on disk, update record <T,X,v,w> appear on disk.

▪ Note that there is no constraint on <COMMIT T> log record in undo/redo logging.
▪ It can appear on disk or after any updated X on disk.

2/11/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.

2/11/2024
 Recovery With Undo/Redo Logging
▪ Recover process operate as follows:
▪ 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 T1 and T1 is uncommitted.
▪ X is modified by T2 and T2 is committed.
▪ Now, if Step 1 “redo” is done first and then Step 2 “undo” then there is a possibility that T2’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 T1’s
changes may not be reflected.

2/11/2024
 Recovery With Undo/Redo Logging
▪ Analyze the recovery for the following cases:
▪ Crash occurs after <COMMIT T> flushed to disk.
▪ Crash occurs before <COMMIT T> flushed to disk.

2/11/2024
 Checkpointing Undo/Redo Log
▪ Algorithm for checkpointing:
▪ Write a log record <START CKPT(T1,T2,…,TK)> where T1, T2,..,Tk 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!
▪ Write an <END CKPT> log record. Flush the log.

2/11/2024
 Recovery Under Checkpointing
▪ Analyze recovery under the following:
▪ Crash occurs after the <COMMIT T3>:
▪ Recovery starts from <START CKPT(T2)>.
[Why not <START T2>?]
▪ Redo <T2,C,14,15>.
▪ Redo <T3,D,19,20>.
▪ Crash occurs before <COMMIT T3>:
▪ Redo <T2,C,14,15>.
▪ Undo <T3,D,19,20>.

2/11/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

2/11/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.

2/11/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>.

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

2/11/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>.

2/11/2024