Académique Documents
Professionnel Documents
Culture Documents
♦ Main memory
♦ Magnetic disk
♦ Magnetic tape
♦ Optical disk.
Stable Storage
∀♦ System Crashes
∀♦ User Error
∀♦ Carelessness
∀♦ Sabotage (intentional corruption of data)
∀♦ Statement Failure
∀♦ Application software errors
∀♦ Network Failure
∀♦ Media Failure
∀♦ Natural Physical Disasters
Recovery from failures
Read(B,b)
b=b+50
Write(B,b)
Output(BX)
In this example we suppose that after each write operation output
operation is performed or in other-words we can say that this is an
example of Force-Output operation.
Log file is a sequence of log records. Log Record maintain a record of all
the operations (update) of the database. There are several types of log
record.
<Start> Log Record:
Contain information about the start of each transaction. It has
transaction identification. Transaction identifier is the unique
identification of the transaction that starts.Representation
<Ti , start>
<Update> Log Record:
It describes a single database write and has the following fields:
< Ti, Xj, V1,V2 >
Here, Ti is transaction identifier, Xj is the data item, V1 is the old value
of data item and V2 is the modified or new value of the data item Xj.
For example < T0, A, 1000, 1100 >
Here, a transaction T0 perform a successful write operation on data Item
A whose old value is 1000 and after write operation A has value 1100.
<Commit> Log Record
T2
Read (C,c)
c=c-200
Write(C,c)
Suppose that these transaction are executed serially, in the order T1
followed by T2 and the value of account A,B and C before the
execution takes place were Rs 1000, Rs 2000 and Rs 3000
respectively.
Recovery procedure
The recovery procedure of deferred database modification is based on
Redo operation as explain below:
Redo(Ti)
It sets the value of all data items updated by transaction Ti to the new
values from the log of records.
After a failure has occurred the recovery subsystem consults the log to
determine which transaction need to be redone. Transaction Ti needs to
be redone if an only if the log contain both the record <Ti, start> and the
record <Ti, commit>. Thus, if the system crashes after the transaction
completes its execution, then the information in the log is used in
restoring the system to a previous consistence state.
Conclusion
Redo: If the log contain both records <Ti, start> and
<Ti, commit>
This transaction may be or may not be stored to disk physically. So use
Redo operation to get the modified values from the log record.
Re-execute: In all other cases ignore the log record and re-execute
the transaction.
Case a:
Crash occurs just after write (B,b), then the log record is as shown in case (a) of above
figure 11.7. In this case, since no commit record appear in the log , then it mean that no
write operation performs on the database item. So, database items just retain their old
values. The values of accounts A and B are Rs1000 and Rs2000 respectively. Thus,
when the system comes back no redo actions need to be taken, the log records of the
incomplete transaction T1 can be deleted from the log.
Case b:
Crash occurs just after write(C,c), then the log record state is shown in case (b) of
above figure 11.7. Since, transaction T1 is completed successfully before the crash,
when the system comes back then the new value of items must be copied from the log
record to the data items. It means that redo (T1) must be performed to recover the
system after the crash. The transaction T2 is not committed, so there is no need of
redo(T2) operation. Transaction T2 is re-executed. As before the log record of the
incomplete transaction T2 can be deleted for the log.
Recovery: redo (T1) is performed since the record <T1,commit> appear in the
log which results A=1100, B=2100.
T2 transaction must be re-executed; the value of C is 3000.
Case c:
Crash occurs just after <T2, commit>, then log record state is shown in
case(c) of above figure 11.7. When the system comes back, two commit
records are in the log, one from T1 and another from T2 transaction, the
operation redo (T1) and redo (T2) must be performed. After these
operations are executed the values of accounts A,B and C becomes
Rs1100, Rs2100 and Rs2800 respectively.
Recovery: redo (T1) and redo (T2)
Result A=1100,B=2100 and C=2800
Case d:
Crash occurs during recovery action. If the crash occurs during the
recovery action, then some transaction may recover and other
transactions may not recover. Thus, in order to remove above problems
recovery actions are restarted from the beginning. Because, the result of
a successful second attempt at redo is same as though redo had succeed
the first time.
Immediate Database Modification
The immediate database modification technique allows database
modification to be output to the database while the transaction is still in
the active state. The data modification written by active transactions are
called “uncommitted modification”.
If the system crash or transaction aborts, then the old value field of the
log records is used to restore the modified data items to the value they
had prior to the start of the transaction. This restoration is accomplished
through the undo operation. In order to understand undo operations, let
us consider the format of log record.
<Ti, Xj, Vold, Vnew>
Here, Ti is transaction identifier, Xj is the data item, Vold is the old value
of data item and Vnew is the modified or new value of the data item Xj.
Undo (Ti):
It restores the value of all data items updated by transaction T1 to the old
values.
Before a transaction T1 starts its execution the record <T1, start> is
written to the log. During its execution, any write (x) operation by T1 is
performed by writing of the apropriate new update record to the log.
When T1 partially commits the record <T1, commit>is written to
the log.
Example:
Let us reconsider our simplified banking system. Let T1 be a transaction
that transfers Rs100 from account A to account B and T2 be a
transaction that withdraws Rs200 from account C. Suppose these
transactions are executed serially as in previous example with initial
values of A, B and C as Rs1000, Rs2000 and Rs3000 respectively.
After a failure has occurred, the recovery scheme consults the log record
to determine which transaction needs to be undone. Transaction Ti needs
to be undone if the log contains the record <Ti, start> but does not
contain the record <Ti, commit>. This transaction is crashed during
execution. Thus, transaction Ti needs to be undone.
Redo (Ti):
Sets the values of all data items updated by transaction Ti to the new
values. These new values can be found in log record. After a failure has
occurred log record is consulted to determine which transaction need to
be redone.
Transaction Ti needs to be redone if the log contains both the record <Ti,
start> and the record <Ti, commit>. This transaction is crashed just after
partially committed. Thus transaction Ti needs to be redone.
Case b:
Crash occurs just after write (C,c), when the system comes back two recovery actions
needs to be taken, the operation undo (T2) must be performed , since the record <T2
,start> appears in the log, but there is no record <T2,commit>.The operation redo(T1)
must be performed, since the log contains both the records <T1,start> and record <T1,
commit>
Recovery: redo (T1) and undo (T2)
A=1100,B=2100 and C=3000. T2 transaction must be re-executed.
Case c:
Crash occurs just after <T2, commit>
When the system comes back both transactions T1 and T2 need to be redone, since the
records <T1,start> and <T1,commit> appears in the log as do the records <T2,start>
and <T2,commit>
Recovery: redo (T1) and redo (T2)
A=1100, B=2100, C=2800.
Checkpoints
To recover the database after some failure we must consult the
log record to determine which transaction needs to be undone and
redone. For this we need to search the entire log to determine this
information. There are two major problems with this approach. These
are:
♦ The search process is time-consuming.
• The most recent checkpoint prior to time tf was taken at time tc.
• Finally, transactions of type T5 also started after time tc, but did
not complete by time tf.
It should be clear that, in case of immediate modification technique those
transactions that have <Ti, start> and <Ti, commit> must be redo and
those transactions that have only <Ti, start> and no <Ti, commit> must
be undo.
The rules for the output of log records limit the freedom of the system to
output blocks of data. If the input of block B2 causes block B1 to be
chosen for output, all log records pertaining to data in B1 must be output
to stable storage before B1 is output.
Thus, the sequence of actions by the system would be as follows:
• Output log records to stable storage until all log records pertaining
to block B1 have been output.
• Output block B1 to disk.
• Input block B2 from disk to main memory.
3. Output all log records currently residing in main memory onto stable
storage.