Information Technology Reference
In-Depth Information
before the crash has all its log records on the log disk before the crash, the database
state resulting from the redo pass thus contains all the updates by committed
transactions. The undo pass rolls back all the transactions that were active, that is,
either forward-rolling or backward-rolling, at the time of the crash. Because of the
assumption that each undo action involved in the rollbacks can be performed on the
database, each individual active transaction will be rolled back correctly, removing
its effect from the database. At the end of the undo pass, the database thus contains
only the updates by a set of committed transactions and is therefore transaction-
consistent.
t
The provision mentioned in Theorem
4.8
is needed, because if the transactions
have not been run sufficiently isolated, the undo pass may not be possible to
execute.
Example 4.9
Assume that action DŒx;
u
by transaction T
1
is followed by action
IŒx;
v
by transaction T
2
,afterwhichT
2
commits and a crash occurs when T
1
is still
forward-rolling:
B
1
D
1
Œx;
u
B
2
I
2
Œx;
v
C
2
crash!
After the redo pass, the current database contains the tuple .x;
v
/.NowT
1
,which
should roll back, cannot perform its undo action D
1
Œx;
u
on a database that
contains .x;
v
/, because of the key constraint.
The action IŒx;
v
by T
2
is termed a “dirty write,” the most serious of the isolation
anomalies to be discussed in Chap.
5
: the action overwrites an uncommitted (or
“dirty”) update. To make recovery possible in all circumstances, dirty writes must
be prevented.
t
As the very last phase of restart recovery, a checkpoint is taken. After this, the
system is ready to process new transactions.
Example 4.10
In the case of our running example, the following is written to the
log at the end of restart recovery:
124:
h
begin-checkpoint
i
125:
h
active-transaction-table
;
fgi
126:
h
modified-page-table
;
f
.p
1
;
R
EC
-LSN
D
103/; .p
2
;
R
EC
-LSN
D
112/
gi
127:
h
end-checkpoint
i
As a conclusion, we note that the database state after recovery is as shown in Fig.
4.6
.
Observe that the active-transaction table is always empty in this case, unless we
allow new transactions to enter the system while the undo pass of recovery is still
ongoing—an issue to be discussed in Sect.
9.7
.
t
