Recovery
• Whenever a transaction is submitted to a DBMS for
execution, the system is responsible for making sure that
either all the operations in the transaction are completed
successfully and their effect is recorded permanently in the
database, or that the transaction does not have any effect
on the database or any other transactions.
• In the first case, the transaction is said to be committed,
• whereas in the second case, the transaction is aborted.
• The DBMS must not permit some operations of a
transaction T to be applied to the database while other
operations of T are not, because the whole transaction is a
logical unit of database processing.
• If a transaction fails after executing some of its operations
but before executing all of them, the operations already
executed must be undone and have no lasting effect
“Recovery”.
Transaction States
• BEGIN_TRANSACTION. This marks the beginning of transaction
execution.
• READ or WRITE. These specify read or write operations on the
database items that are executed as part of a transaction.
• END_TRANSACTION. This specifies that READ and WRITE
transaction operations have ended and marks the end of
transaction execution. However, at this point it may be necessary to
check whether the changes introduced by the transaction can be
permanently applied to the database (committed)
• COMMIT_TRANSACTION. This signals a successful end of the
transaction so that any changes (updates) executed by the
transaction can be safely committed to the database and will not be
undone.
• ROLLBACK (or ABORT). This signals that the transaction has
ended unsuccessfully, so that any changes or effects that the
transaction may have applied to the database must be undone.
• State transition diagram illustrating the states
for transaction execution.
Recovery
The System Log
• To be able to recover from failures that affect
transactions, the system maintains a log to
keep track of all transaction operations that
affect the values of database items, as well as
other transaction information that may be
needed to permit recovery from failures.
• The log is a sequential, append-only file that is
kept on disk, so it is not affected by any type
of failure except for disk or catastrophic
failure.
Types of entries “log records ” that are written to the log
file :
• [start_transaction, T]. Indicates that transaction T has
started execution.
• [write_item, T, X, old_value, new_value]. Indicates
that transaction T has changed the value of database
item X from old_value to new_value.
• [read_item, T, X]. Indicates that transaction T has read
the value of database item X.
• [commit, T]. Indicates that transaction T has completed
successfully, and affirms that its effect can be
committed (recorded permanently) to the database.
• [abort, T]. Indicates that transaction T has been
aborted.
Properties of Transactions
ACID properties:
• Atomicity. A transaction is an atomic unit of processing; it should
either be performed in its entirety or not performed at all.
• Consistency preservation. A transaction should be consistency
preserving, meaning that if it is completely executed from
beginning to end without interference from other transactions, it
should take the database from one consistent state to another.
• Isolation. A transaction should appear as though it is being executed in
isolation from other transactions, even though many transactions are
executing concurrently. That is, the execution of a transaction should
not be interfered with by any other transactions executing concurrently.
• Durability or permanency. The changes applied to the database by a
com- mitted transaction must persist in the database. These changes
must not be lost because of any failure.
• The atomicity property requires that we execute a
transaction to completion.
• It is the responsibility of the transaction recovery
subsystem of a DBMS to ensure atomicity.
• If a transaction fails to complete for some reason,
such as a system crash in the midst of transaction
execution, the recovery technique must undo any
effects of the transaction on the database.
• On the other hand, write operations of a
committed transaction must be eventually
written to disk.
• The preservation of consistency is generally considered
to be the responsibility of the programmers who write
the database programs and of the DBMS module that
enforces integrity constraints.
• Recall that a database state is a collection of all the
stored data items (values) in the database at a given
point in time.
• A consistent state of the database satisfies the
constraints specified in the schema as well as any other
constraints on the database that should hold.
• A database program should be written in a way that
guarantees that, if the database is in a consistent state
before executing the transaction, it will be in a
consistent state after the complete execution of the
transaction.
• The isolation property is enforced by the
concurrency control subsystem of the DBMS.
• If every transaction does not make its updates
(write operations) visible to other transactions
until it is committed, one form of isolation is
enforced that solves the temporary update
problem and eliminates cascading rollbacks
but does not eliminate all other problems.
• The durability property is the responsibility of
the recovery subsystem of the DBMS.
Characterizing Schedules Based on Recoverability
A schedule (or history) S of n transactions T1, T2, … , Tn
is an ordering of the operations of the transactions.
Operations from different transactions can be
interleaved in the schedule S. T T 1 2
read_item(X );
X := X – N; read_item(X );
• Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y); write_item(X ); X := X + M;
read_item(Y ); write_item(X );
Y := Y + N;
write_item(Y );
T1 T2
read_item(X );
X := X – N;
write_item(X );
read_item(X );
X := X + M;
write_item(X );
read_item(Y );
• Sb: r1(X); w1(X); r2(X); w2(X); r1(Y); a1;
Conflicting Operations in a Schedule
• Two operations in a schedule are said to
conflict if they satisfy all three conditions:
• (1) they belong to different transactions;
• (2) they access the same item X;
• (3) at least one of the operations is a
write_item(X).
Example on conflicting
• Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y);
yes
Conflict operations
R1(x) W2(x)
R2(x) W1(x)
W1(x) W2(x)
