4.

Crash Recovery
 Recovery
• A crash is the sudden failure of a software application or
operating system or of a hardware device such as a hard
disk.
• Database recovery is the process of restoring the database
to a consistent state in the event of a failure.
• In other words, it is the process of restoring the database to
the most recent consistent state that existed shortly before
the time of system failure.
• Recovery is required to protect the database from data
inconsistencies and data loss.
• Recovery is done by rolling back incomplete transactions
and completing committed transactions that were still in
memory when the crash occurred.
Classification of Transaction Failure
Classification of Transaction Failure
Failure can be
• Simple-No Loss of data or information
• Complex- Loss of data or information
1.Transaction Failure
There are 2 types of errors
a) System Error-deadlock condition
b) Logical Error-some mistakes in the code or
presence of some internal faults.
2. System Crash
failure of the transaction, operating system errors, power
cuts, main memory crash etc.
3. Disk Failure
Disk head crash, disk unreachability , formation of bad
sectors, read write errors on the disk
 Transaction Logging

Recovery is done by either

Re-execute
or Do Not Re-execute of transaction

Transaction Logging
• To recover from failures, database systems maintain a
transaction log, which records all changes made by
transactions. The log includes information about what
operations were performed, the data affected, and
when they were executed.
 Recovery and Log
• Log -The most widely used structure for recording
modifications to database.
• It records significant events during transaction
processing.
• Update log records contains following fields:
• Transaction identifier is the unique identifier of the
transaction that performed the write operation.
• Data-item identifier is the unique identifier of the data
item written. It is the location on disk of the data item.
• Old value is the value of the data item prior to the
write.
• New value is the value that the data item will have
after the write.
• Other special log records such as the start of a
transaction and the commit or abort of a transaction.

• Start of transaction: denoted as <Ti start>

Update log:
• It describes a single database write and it is denoted
as: <Ti,Xj,V1,V2>
where, Ti –Transaction identifier
Xj- Data item identifier
V1 – Old value of Xj
V2 - New value of after the write operation.
• Transaction commits: denoted as <Ti commit>
• Transaction abort: denoted as:<Ti abort>
 Recovery with concurrent
transactions
• Rollback
• Checkpoint
• Commit
 Rollback

– User rollback a failed transaction T, using the log.

– The log is scanned backward for every log record
of the form <T ,Xi,V1,V2>found in the log, the data
item Xi is restored to its old value V1.
– The scanning of the log terminates when the log
record <T, start> is found.
– Scanning the log backward is more important,
since a transaction may have updated a data item
more than once.
– Consider the pair of log records as given below:
• <T,A,10,20>
• <T,A,20,30>

•
•
•
 Rollback

– They represent a modification of data item A by Ti

followed by another modification of A by Ti Scanning
.

the log backward set A correctly to 10.

– If the log were scanned in the forward direction, A
would be set to 20, which value is incorrect.
– If strict two-phase locking is used for concurrent
concurrenency control, locks held by a transaction T
may be released only after the transaction has been
rolled back as described.
– Once transaction T has updated a data item, no other
transaction could have updated same data item, due
to the concurrency-control requirements.
 Checkpoint

• Keeping and maintaining logs in real time and in

real environment may fill out all the memory
space available in the system.
• As time passes, the log file may grow too big to
be handled at all.
• Checkpoint is a mechanism where all the
previous logs are removed from the system and
stored permanently in a storage disk.
• Checkpoint declares a point before which the
DBMS was in consistent state and all the
transactions were committed.
 Checkpoint

• The recovery system reads the logs backwards from the

end to the last checkpoint.
• It maintains two lists, an undo-list and a redo-list.
• If the recovery system sees a log with <Tn, Start> and <Tn,
Commit> or just <Tn, Commit>, it puts the transaction in the
redo-list.
• If the recovery system sees a log with <Tn, Start> but no
commit or abort log found, it puts the transaction in undo-
list.
• All the transactions in the undo-list are then undone and
their logs are removed.
• All the transactions in the redo-list and their previous logs
are removed and then redone before saving their logs.
 Commit
• If a transaction executes all its operations successfully, it is said to be
committed.
• All its effects are now permanently established on the database system.
• Commit command is used to permanently save any transaction into
database.
Syntax:
• commit;
For example:
• INSERT into student values(5,’Rahul’);
• commit;
• After commit point the transaction writes a commit record [COMMIT , Ti]
into the log.
• If a system failure occurs, the log is searched back for all transactions that
have written a [START_TRANSACTION, TJ] records in the log but do not
make[ COMMIT, TJ]
• Then these transactions may have to be rolled back to undo their effect on
the database.
• Transactions that are committed must also have recorded all their write
entries in the log. So, their effect on the database can be redone from the
log entries.
 Log Based Recovery
Recovery Procedures:
• Two operations applied to recover from a failure are, undo and
redo. These are applied with the help of the log on the last
consistent state of the database.
Undo: This operation reverses (rolls back) the changes made to the
database by an uncommitted transaction and restores the database
to the consistent state that existed before the start of the
transaction.
Redo: This operation reapplies the changes of a committed
transaction and restores the database to the consistent state it
would be at the end of the transaction.
• This operation is required when the changes of a committed
transaction are not or partially reflected to the database on disk.
The redo modifies the database on disk to the new values for the
committed transaction.
 Recovery Algorithm
Deferred Update (No Undo/Redo Algorithm)
• This technique does not physically update the database on
disk until a transaction has reached its commit point.
• Before reaching commit, all transaction updates are
recorded in the local transaction workspace.
• If a transaction fails before reaching its commit point, it will
not have changed the database in any way so UNDO is not
needed.
• In a deferred update we mainly deals with new values of
variables.
• The REDO is needed in case the system fails after the
transaction commits but before all its changes are
recorded in the database
• The database is never updated until after the transaction
commits and there is never a need to UNDO any
operations.
 Deferred Update
Initially values of A=100 and B=200 are stored in database
Transaction T1 Transaction Log Transaction Log
Read(A) <T1 ,Start> <T1 ,Start>
A=A+100 <T1,A,200> <T1,A,200>
Write(A) 200 <T1,B,400> <T1,B,400>
Read(B) <T1,Commit> <T1,Commit>
B=B+200 <T2 ,Start>
Write(B) 400 <T2,C,500>
Commit

Redo Transaction T1 and not undo transaction T2

 Immediate Update
• In the immediate update, the database may be
updated by some operations of a transaction
before the transaction reaches its commit point.
• These operations are recorded in a log on disk
before they are applied to the database, making
recovery still possible.
• If a transaction fails to reach its commit point, the
effect of its operation must be undone i.e. the
transaction must be rolled back
• We require both undo and redo. This technique is
known as undo/redo algorithm.
 Immediate Update
Undo/Redo Algorithm - Immediate Update
Initially values of A=100 and B=200 are stored in database
Transaction T1 Transaction Log Transaction Log
Read(A) <T1 ,Start> <T1 ,Start>
A=A+100 <T1,A,100,200> <T1,A,100,200>
Write(A) 200 <T1,B,200,400> <T1,B,500,600>
Read(B) <T1,Commit> <T1,Commit>
B=B+200 <T2 ,Start>
Write(B) 400 <T2,C,700,800>
Commit
Redo (Commit)Transaction T1 and Undo(Fail) Transaction T2
 Dirty and Clean Pages
Dirty Pages:
Dirty pages are the pages in the memory
buffer that have modified data, yet the data is
not moved from memory to disk.
Clean Pages:
Clean pages are the pages in a memory buffer
that have modified data but the data is moved
from memory to disk.
 Buffer Management
• A buffer is a memory location used by a database
management system (DBMS) to temporarily hold data
that has recently been accessed or updated in the
database.
• The buffer manager of a DBMS is the software
component responsible for using a limited amount of
main storage as disk page buffers, there by reducing
the number of disk I/O per database transaction.
• The buffer manager is responsible for the efficient
management of the database buffers that are used to
transfer(flushing) pages between buffer and
secondary storage.
Steal versus No Steal Buffer Management

• A page with modifications by an uncommitted

transaction is a dirty page until either commit or
rollback processing for that transaction has been
completed.
• The buffer manager can either distinguish dirty
pages from clean pages when deciding which
page to remove from the buffer pool or it can
ignore the update status of a page.
• In later case, the buffer manager uses a Steal
Policy which means pages can be written out to
disk even if the transaction having modified the
pages is still active.
Steal versus No Steal Buffer Management
• The alternative is the No-steal policy , in which case all dirty
pages are retained in the buffer pool until the final outcome
of the transaction has been determined.
• A steal policy dictates whether the DBMS allows an
uncommitted transaction to overwrite the most recent
committed value of an object in non-volatile storage (can a
transaction write uncommitted changes to disk).
• STEAL: Is allowed • NO-STEAL: Is not allowed.
• Advantages:
– The steal policy implies that rollback of a transaction
requires access to pages on disk in order to re-establish
their old state.
– With the no-steal policy, no page on disk ever has to be
touched when rolling back a transaction.
 FORCE and NO-FORCE
• A force policy dictates whether the DBMS requires that all
updates made by a transaction are reflected on non-volatile
storage before the transaction is allowed to commit.
• Force versus No-force concerns writing of clean pages from
the buffer pool
• There are two basic approaches
Force policy When a transaction commits, the buffer
manager locates all pages modified by that transaction and
immediately writes the pages to disk.
No-force policy page whether modified or not, stays in the
buffer as long as it is still needed. With a 110-force policy,
when a transaction commits, the changes made to the actual
pages are non forced", are required to be written to disk in
place.
 FORCE and NO-FORCE
Advantage
• It avoids any REDO recovery during restart.
• If a transaction issue successfully committed,
then by definition, all its modified pages must
be on disk.
• FORCE: Is required
• NO-FORCE: Is not required
 Log record buffering
• Log records are buffered in main memory, instead of being
output directly to stable storage.
• Log records are output to stable storage when a block of log
records in the buffer is full or a log force operation is
executed.
Rules Of Buffering
• T1Transaction enters that commit state after the <T1commit>
log record has been output to stable storage.
• Before the <T1 commit> log record can be output to stable
storage, all log records belonging to transaction T1must have
been output to stable storage.
• A write ahead log is an append-only auxiliary disk-resident
structure used for crash and transaction recovery. The changes are
first recorded in the log, which must be written to stable storage,
before the changes are written to the database.
 Relationship between Recovery
Management & Buffer Management

•I/O Operations of OS
•Recovery fro hardware &
software failure
•Recover DB in case of
failure by log files,
commit and abort of
transactions
 ARIES Algorithm
• Algorithm for Recovery and Isolation Exploiting Semantics
It is based on the Write Ahead Log (WAL) protocol.
Every update operation writes a log record which is one of
the following :
• Analysis: The analysis phase identifies the dirty (updated)
pages in the buffer and the set of transactions active at the
time of the crash. The appropriate point in the log where
the REDO operation should start is also determined.
• Undo-only log record:
Only the before image is logged. Thus, an undo operation
can be done to retrieve the old data.
• Redo-only log record:
Only the after image is logged. Thus, a redo operation can
be attempted.
• Undo-redo log record:
Both before images and after images are logged.
 ARIES Algorithm

• It uses a steal/no force approach for writing and it is based

on following three concepts:
• Write ahead Logging: Any change to an object is first
recorded in the log and the log must be written to stable
storage before changes to the object are written to disk.
• Repeating History During Redo: ARIES will retrace all
actions of the database system prior to the crash to
reconstruct database state when the crash occurred.
Transactions that were uncommitted at the time of the
crash (active transactions) are undone.
• Logging Changes During Undo: Will prevent ARlES from
repeating the completed undo operations if a failure occurs
during recovery, which causes a restart of the recovery
process.
 DATABASE BACKUP AND RECOVERY FROM
CATASTROPHIC FAILURE
Database backup and recovery from catastrophic failures involve:
• Backup: Regularly create backups of the database including full and
incremental backups, storing them securely off-site.
• Disaster Recovery Plan: Develop a comprehensive disaster recovery
plan outlining roles, responsibilities and recovery objectives.
• Backup Restoration: In case of a failure, restore the latest full
backup and apply incremental backups and transaction logs to
reach the desired recovery point.
• Data Integrity: Ensure the recovered database is consistent and
maintain data integrity.
• High Availability: Implement mechanisms like clustering or
replication for high availability and failover.
• Testing: Test the recovery plan and backups periodically to ensure
they work as expected.
• Documentation: Maintain detailed documentation of recovery
procedures for quick action during a catastrophic event.
 SHADOW PAGING
• Shadow Paging is recovery technique that is used to
recover database.
• In this recovery technique, database is considered as made up of
fixed size of logical units of storage which are referred as pages.
• Pages are mapped into physical blocks of storage, with help of
the page table which allow one entry for each logical page of
database.
• This method uses two page tables named current page
table and shadow page table.
• The entries which are present in current page table are used to
point to most recent database pages on disk.
• Shadow page table is used when the transaction starts which is
copying current page table.
• After this, shadow page table gets saved on disk and current page
table is going to be used for transaction.
• Entries present in current page table may be changed during
execution but in shadow page table it never get changed.
• After transaction, both tables become identical. This technique is
also known as Cut-of-Place updating.
•When transaction starts, both page tables are identical
•The shadow page table is never changed over the duration of the transaction.
•The current page table may be changed when a transaction performs a write
operation.
•All input and output operations use the current page table to locate database
pages on disk.
Shadow Paging
 Advantages
• This method require fewer disk accesses to perform
operation.
• There is no need of operations like- Undo and Redo.
• Recovery using this method will be faster.
• Improved fault tolerance: Shadow paging provides
improved fault tolerance since it isolates transactions
from each other.
• Increased concurrency: Since modifications made
during a transaction are written to the shadow copy
instead of the actual database, multiple transactions
can be executed concurrently without interfering with
each other.
• Simplicity: Shadow paging is a relatively simple
technique to implement.
• No need for log files : eliminates the need for log files
since all changes are made to the shadow copy.
 Disadvantages
• Data gets fragmented or scattered.
• Due to location change on disk due to update
database it is quite difficult to keep related pages in
database closer on disk.
• During commit operation, changed blocks are going to
be pointed by shadow page table which have to be
returned to collection of free blocks otherwise they
become accessible.
• The commit of single transaction requires multiple
blocks which decreases execution speed.
• To allow this technique to multiple transactions
concurrently it is difficult.
Example
Following are the log entries at the time of system crash:
[start _transaction, T1]
[write_item,T1,A,10]
[commit T1]
[start_transaction,T3]
[write_item T3, B,15]
[checkpoint]
[commit T3]
[start_transaction,T2]
[write_itemT2,B, 20]
[start_transaction,T4]
[write_item,T4,D, 25]
[writejternT2,C,30]-system crash
If a deferred update technique with checkpoint is used, what will be the
recovery procedure?
Solution:
Transactions T2 andT4 are ignored, because they did not reach their commit
points. i.e.T2 andT4 do not have commit instructions before the system
crash.
T1 is committed before the last system checkpoint hence it need not be
redone. T3 is redone because its commit point is after the last system
checkpoint.
Example
Following are the log entries at the time of system crash:
[start_transaction,T1]
[write_item,T1,B,100]
[commit,T1]
[checkpoint]
[start_transaction,T2]
[write_item,T2,D,100]
[commit,T2]
[start_transaction,T3)
[write_item,T3,D,200]
[write_item,T3,B,200] system crash.
If a deferred update technique with checkpoint is used, what will be
the recovery procedure?
Solution:
Transaction T3 is ignored because it does not have commit instruction
before the system crash.
T1is committed before the last system checkpoint hence it need not be
redone.
T2 is redone because its commit point is after the last system
checkpoint.
Example:
Following are the log entries at the time of system crash:
[start_transaction,T1]
[write_item,T1,A,10,100]
[commit,T1]
[checkpoint]
[start_transaction,T2]
[write_item,T2, B, 20,200]
[commit, T2]
[start_transaction,T3]
[write_item,T3,C,30,300] System Crash
If immediate update technique with a checkpoint is used,
what will be the recovery procedure?
Solution:
Log contains start instruction for T3, but does not contain
commit instructions for T3, before the system crash. Hence,
T3 needs to be undone.
• Consider the following log
image that is obtained during
recovery after a crash:
<T1,start>
<T1,X,10,10>
a) List the contents in the list L.
<T2,start>
b) List the contents in:
<T2,X,20,200>
<T1, commit>
Undo-list and Redo-list.
<T3,start> Solution:
<T3,z,10,20> The contents in the list L are =
<Checkpoint> {T1,T2,T3,T4}
<T3,K,20,200> a)Undo List={T3,T4}
<T2,commit> b)Redo List={T2}.
<T4,start>
<T4,X,200,100> System Crash