CHAPTER 19: DATABASE RECOVERY
TECHNIQUES
Answers to Selected Exercises
19.21 Suppose that the system
crashes before the [read_item,T3,A] entry is written to
the log in Figure 19.1(b); will that
make any difference in the recovery process?
Answer:
There will be no difference in the
recovery process, because read_item operations are
needed only for determining if
cascading rollback of additional transactions is necessary.
19.22 Suppose that the system
crashes before the [write_item,T2,D,25,26] entry is
written to the log in Figure 19.1(b);
will that make any difference in the recovery process?
Answer:
Since both transactions T2 and T3
are not yet committed, they have to be rolled back
during the recovery process.
19.23 Figure 19.7 shows the log
corresponding to a particular schedule at the point of a
system crash for the four
transactions T1, T2, T3, and T4 of Figure 19.4. Suppose that we use the
immediate update protocol with checkpointing. Describe the recovery process
from the system crash. Specify which transactions are rolled back, which
operations in the log are redone and which (if any) are undone, and whether any
cascading rollback takes place.
Answer:
First, we note that this schedule is
not recoverable, since transaction T4 has read the
value of B written by T2, and then
T4 committed before T2 committed. Similarly,
transaction T4 has read the value of
A written by T3, and then T4 committed before T3
committed. The [commit, T4] should
not be allowed in the schedule if a recoverable
protocol is used, but should be
postponed till after T2 and T3 commit. For this problem,
let us assume that we can roll back
a committed transaction in a non-recoverable
schedule, such as the one shown in
Figure 21.7.
By using the procedure RIU_M
(recovery using immediate updates for a multiuser
environment), the following result
is obtained:
From Step 1 of procedure RIU_M, T2
and T3 are the active transactions. T1 was
committed before the checkpoint and
hence is not involved in the recovery.
From Step 2, the operations that are
to be undone are:
[write_item,T2,D,25]
[write_item,T3,A,30]
[write_item,T2,B,12]
Note that the operations should be
undone in the reverse of the order in which they were
written into the log. Now since T4
read item B that as written by T2 and read item A that
as written by T3, and since T2 and
T3 will be rolled back, by the cascading rollback
rule, T4 must be also rolled back.
Hence, the following T4 operations must also be
undone:
[write_item,T4,A,20]
[write_item,T4,B,15]
(Note that if the schedule was
recoverable and T4 was committed, then from Step 3, the
operations that are to be redone
would have been:
[write_item,T4,B,15]
[write_item,T4,A,20]
In our case of non-recoverable
schedule, no operations need to be redone in this
example.)
At the point of system crash,
transactions T2 and T3 are not committed yet. Hence, when
T2 is rolled back, transaction T4
should also be rolled back as T4 reads the values of
items B and A that were written by
transactions T2 and T3. The write operations of T4
have to be undone in their correct
order. Hence, the operations are undone in the
following order:
[write_item,T2,D,25]
[write_item,T4,A,20]
[write_item,T3,A,30]
[write_item,T4,B,15]
[write_item,T2,B,12]
19.24 Suppose that we use the
deferred update protocol for the example in Figure 19.7.
Show how the log would be different
in the case of deferred update by removing the unnecessary log entries; then
describe the recovery process, using your modified log. Assume that only redo
operations are applied, and specify which operations in the log are redone and
which are ignored.
Answer:
In the case of deferred update, the
write operations of uncommitted transactions are not
recorded in the database until the
transactions commit. Hence, the write operations of T2
and T3 would not have been applied
to the database and so T4 would have read the
previous (committed) values of items
A and B, thus leading to a recoverable schedule.
By using the procedure RDU_M
(deferred update with concurrent execution in a
multiuser environment), the
following result is obtained:
The list of committed transactions T
since the last checkpoint contains only transaction
T4. The list of active transactions
T' contains transactions T2 and T3.
Only the WRITE operations of the
committed transactions are to be redone. Hence, REDO
is applied to:
[write_item,T4,B,15]
[write_item,T4,A,20]
The transactions that are active and
did not commit i.e., transactions T2 and T3 are
canceled and must be resubmitted.
Their operations do not have to be undone since they
were never applied to the database.
19.25 How does checkpointing in
ARIES differ from checkpointing as described in Section 19.1.4?
Answer:
The main difference is that with
ARIES, main memory buffers that have been modified are not flushed to disk.
ARIES, however writes additional information to the LOG in the form of a
Transaction Table and a Dirty Page
Table when a checkpoint occurs.
19.26 How are log sequence numbers
used by ARIES to reduce the amount of REDO work needed for recovery? Illustrate
with an example using the information shown in Figure 19.6. You can make your own
assumptions as to when a page is written to disk.
Answer:
Since ARIES writes the Dirty Page
Table to the LOG at checkpoint time, ARIES can use the LSN (log sequence number)
information stored in that table and the data pages during recovery.
REDO only has to start after the
point where all prior changes are known to be in the database. Hence, REDO can
start at the place in the LOG that corresponds to the smallest LSN from the
Dirty Page Table.
In Figure 21.6, since the smallest
LSN in the Dirty Page Table is 1, REDO must start at location 1 in the LOG.
Let's assume that when Transaction T2 performed the update of page C, page C
was written to disk. So, page C on disk would have an associated LSN of 7. When
REDO starts at location 1 in the LOG (LSN of 1), page C would be read into the
main memory buffer, however no change is necessary since the the LSN of page C
is 7, which is larger than LSN of 1 for the current LOG update operation.
Proceeding with location 2
in the LOG, page B would be brought
into memory. If the LSN of page B is less than 2, then page B would be updated
with the corresponding change in location 2 in the LOG. Similarly for location
6, page A would be updated. For location 7, Page C need not be updated since
the LSN of page C (i.e., 7) is not less than the LSN of the current LOG update
operation.
21.27 What implications would a
no-steal/force buffer management policy have on checkpointing and recovery?
No-steal means that the cache
(buffer) page updated by a transaction cannot be written to disk before the
transaction commits. Force means that updated pages are written to disk when a
transaction commits.
With No-steal, the checkpoint scheme
that writes all modified main memory buffers to disk would not be able to write
pages updated by uncommitted transactions.
With
Force, once a transaction is done, its updates would be pushed to disk. If
there is a failure during this, REDO is still needed, however, no UNDO is
needed since uncommitted
updates
are never propagated to disk.
19.28 (b)
19.29 (b)
19.30 (b)
19.31 (a)
19.32 c
19.33 (a)
19.34 c
19.35 (d)
19.36 (b)
19.37 (b)