Recovery Techniques Dbms
Recovery Techniques Dbms
Recovery Techniques Dbms
techniques
Deferred
database modification
Immediate
modification
technique
Shadow paging
Checkpoints
Remote backup system
Example
To illustrate, reconsider our simplified banking system. Let T0 be a
transaction that transfers $50 from account A to account B:
T0: read(A);
A := A 50;
write(A);
read(B);
B := B + 50;
write(B).
Let T1 be a transaction that withdraws $100 from account C:
T1: read(C);
C := C 100;
write(C).
Suppose that these transactions are executed serially, in the order T0
followed by T1,
and that the values of accounts A, B, and C before the execution took
place were
$1000, $2000, and $700, respectively
Log
<T0
<T0
<T0
<T0
start>
, A, 950>
, B, 2050>
commit>
<T1 start>
<T1 , C, 600>
<T1 commit>
database
A = 950
B = 2050
C = 600
<T0 start>
<T0 , A, 950>
<T0 , B, 2050>
When the system comes back up, no redo actions
need to be taken, since no commit record
appears in the log. The values of accounts A and
B remain $1000 and $2000, respectively
Now, let us assume the crash comes just after the log
record for the step write(C) of transaction T1 has been
written to stable storage.
<T0 start>
<T0 , A, 950>
<T0 , B, 2050>
<T0 commit>
<T1 start>
<T1 , C, 600>
When the system comes back up, the operation
redo(T0) is performed, since the record
<T0 commit>
appears in the log on the disk. After this operation is executed, the
values of accounts
A and B are $950 and $2050, respectively. The value of account C
remains $700. As
before, the log records of the incomplete transaction T1 can be
deleted from the log.
WORKING:
let us assume that the crash comes just after the log
record for the step
write(C) of transaction T1
<T0 start>
<T0 , A, 1000, 950>
<T0 , B, 2000, 2050>
<T0 commit>
<T1 start>
<T1 , C, 700, 600>
The operation undo(T1) must
be performed, since the record <T1 start> appears in
the log, but there is no record
<T1 commit>. The operation redo(T0)must be performed,
since the log contains both
the record <T0 start> and the record <T0 commit>. At
the end of the entire recovery
procedure, the values of accounts A, B, and C are $950,
$
2050, and $700,
respectively
Checkpoints:
When a system failure occurs, we must consult the log to determine those
transactions
that need to be redone and those that need to be undone. In principle, we
need to search the entire log to determine this information. There are
two major difficulties
with this approach:
1. The search process is time consuming.
2. Most of the transactions that, according to our algorithm, need to be
redone
have already written their updates into the database. Although redoing
them
will cause no harm, it will nevertheless cause recovery to take longer.
To reduce these types of overhead, we introduce checkpoints
Transactions are not allowed to perform any update actions, such as writing
to a buffer block or writing a log record, while a checkpoint is in progress.
Working:
The presence of a <checkpoint> record in the log allows
the system to streamline
its recovery procedure. Consider a transaction Ti that
committed prior to the checkpoint.
For such a transaction, the <Ti commit> record appears in
the log before the
<checkpoint> record. Any database modifications made by
Ti must have been written
to the database either prior to the checkpoint or as part
of the checkpoint itself.
Thus, at recovery time, there is no need to perform a
redo operation on Ti.
Shadow paging
the database is partitioned into some number of fixed-length blocks,
Which are referred to as pages.
The key idea behind the shadow-paging technique is to maintain two
page tables during the life of a transaction: the current page table
and the shadow page table.
When the 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.
When the transaction commits, the system writes the current page
table to nonvolatile storage.
The current page table then becomes the new shadow page table, and
the next
transaction is allowed to begin execution.
NO REDO , NO UNDO
Architecture of remote
backup system
Two safe