[20 points] After a system's crash, the undo-log using non-quiescent checkpointing contains the following data:
| <START T1> |
| <T1, X1, 1> |
| <START CKPT ????> |
| <START T2> |
| <T2, X2, 2> |
| <T1, X1, 3> |
| <START T3> |
| <COMMIT T1> |
| <END CKPT> |
| <START CKPT ????> |
| <T2, X2, 4> |
| <T3, X3, 5> |
| <START T4> |
| <COMMIT T2> |
| <T4, X4, 6> |
| <COMMIT T3> |
| <END CKPT> |
| <START T5> |
| <T5, X5, 7> |
| <START CKPT ????> |
| <T4, X4, 8> |
| CRASH !!! |
|
<START T1> |
|
<T1, X1, 55> |
|
<START T2> |
|
<T2, X2, 99> |
|
<COMMIT T1> |
|
. . . . |
Is represented by the table:
|
N |
T |
E |
V |
|---|---|---|---|
|
0 |
T1 |
-1 |
|
|
1 |
T1 |
X1 |
55 |
|
2 |
T2 |
-1 |
|
|
3 |
T2 |
X2 |
99 |
|
4 |
T1 |
-2 |
|
|
. . . |
|
|
|
Recall that each transaction starts
and ends at
most once; for example, a sequence <START T> … <COMMIT T> …
<START T>
… will not occur in the log. Moreover, any update by the transaction T
will
occur between its <START T> and <COMMIT T>, or between
<START
T> and <ABORT T> respectively. Finally, once a transaction has ended
in COMMIT or ABORT and the corresponding log record is on disk, the transaction
has completed and does not need to be undone.
Write a SQL query that can be run during database recovery, after a
system
crash. The answer to your query should return a table with two
attributes, E,
and V, indicating which elements have to be updated with what
values.
You should include each element E at most once in your answer:
otherwise
it would be ambiguous how to update it.