Transaction Management Database Recovery

Transaction Management
Database Recovery
1
Database Recovery
Process of restoring database to a correct state in
the event of a failure.
 Need for Recovery Control

– Two types of storage: volatile (main memory) and
nonvolatile.
– Volatile storage does not survive system crashes.
– Stable storage represents information that has
been replicated in several nonvolatile storage
media with independent failure modes.
2
Types of Failures
 System crashes, resulting in loss of main
memory.
 Media failures, resulting in loss of parts of
secondary storage.
 Application software errors.
 Natural physical disasters.
 Carelessness or unintentional destruction of
data or facilities.
 Sabotage.
3
Transactions and Recovery
 Transactions represent basic unit of recovery.
 Recovery manager responsible for atomicity and
durability.
 If failure occurs between commit and database
buffers being flushed to secondary storage then, to
ensure durability, recovery manager has to redo
(rollforward) transaction’s updates.
 If transaction had not committed at failure time,
recovery manager has to undo (rollback) any effects
of that transaction for atomicity.
4
Example
 DBMS starts at time t0, but fails at time tf. Assume data
for transactions T2 and T3 have been written to secondary
storage.
 T1 and T6 have to be undone. In absence of any other
information, recovery manager has to redo T2, T3, T4, and
T5.
5
Recovery Facilities
 DBMS should provide following facilities to assist
with recovery:
– Backup mechanism, which makes periodic backup

copies of database.
– Logging facilities, which keep track of current state of
transactions and database changes.
– Checkpoint facility, which enables updates to database
in progress to be made permanent.
– Recovery manager, which allows DBMS to restore
database to consistent state following a failure.
6
Log File
 Contains information about all updates to
database:
– Transaction records.
– Checkpoint records.
 Often used for other purposes (for example,
auditing).
7
Log File
 Transaction records contain:
– Transaction identifier.
– Type of log record, (transaction start, insert,
update, delete, abort, commit).
– Identifier of data item affected by database
action (insert, delete, and update operations).
– Before-image of data item.
– After-image of data item.
8
Sample Log File
9
Log File
 Log file may be duplexed or triplexed.
 Log file sometimes split into two separate files.
 Potential bottleneck; critical in determining
overall performance.
10
Checkpointing
Checkpoint
Point of synchronization between database and
log file. All buffers are force-written to
secondary storage.
 Checkpoint record is created containing identifiers

of all active transactions.
 When failure occurs, redo all transactions that
committed since the checkpoint and undo all
transactions active at time of crash.
11
Checkpointing
 In this example, with checkpoint at time t c, changes made by T2 and T3 have

been written to secondary storage.
 Thus:
– only redo T4 and T5,
– undo transactions T1 and T6.
12
Recovery Techniques
 If database has been damaged:
– Need to restore last backup copy of database and
reapply updates of committed transactions using
log file.
 If database is only inconsistent:
– Need to undo changes that caused inconsistency.
May also need to redo some transactions to ensure
updates reach secondary storage.
– Do not need backup, but can restore database
using before- and after-images in the log file.
13
Main Recovery Techniques
 Three main recovery techniques:
– Deferred Update
– Immediate Update
– Shadow Paging
14
Deferred Update
 Updates are not written to the database until
after a transaction has reached its commit point.
 If transaction fails before commit, it will not have
modified database and so no undoing of changes
required.
 May be necessary to redo updates of committed
transactions as their effect may not have reached
database.
15
Immediate Update
 Updates are applied to database as they occur.
 Need to redo updates of committed transactions
following a failure.
 May need to undo effects of transactions that
had not committed at time of failure.
 Essential that log records are written before
write to database. Write-ahead log protocol.
16
Immediate Update
 If no “transaction commit” record in log, then
that transaction was active at failure and must
be undone.
 Undo operations are performed in reverse order
in which they were written to log.
17
Shadow Paging
 Maintain two page tables during life of a
transaction: current page and shadow page table.
 When transaction starts, two pages are the same.
 Shadow page table is never changed thereafter
and is used to restore database in event of failure.
 During transaction, current page table records all
updates to database.
 When transaction completes, current page table
becomes shadow page table.
18
Advanced Transaction Models
 Look at five advanced transaction models:
– Nested Transaction Model

– Sagas
– Workflow Models
19

Transaction Management Database Recovery

Uploaded by

Copyright:

Available Formats

Transaction Management Database Recovery

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Transaction Management Database Recovery

Uploaded by

Copyright:

Available Formats

Transaction Management

 Need for Recovery Control

– Backup mechanism, which makes periodic backup

 Checkpoint record is created containing identifiers

 In this example, with checkpoint at time t c, changes made by T2 and T3 have

– Nested Transaction Model

You might also like