NAME – Prince Kumar

ROLL NO - 1806048
GROUP - G2
BRANCH - INFORMATION TECHNOLOGY
SUBJECT - Database Management System
DATE - 22 APRIL 2020

ASSIGNMENT 4

Q1.State all aspects of Time Stamp based protocols with suitable example.

The timestamp method for concurrency control doesn’t need any locks and therefore
this method is free from deadlock situation. Locking methods generally prevent
conflicts by making transaction to wait; whereas timestamp methods do not make the
transactions to wait. Rather, transactions involved in a conflicting situation are simply
rolled back and restarted.

A timestamp is a unique identifier created by the Database system that indicates the
relative starting time of a transaction. Timestamps are generated either using the
system clocks or by incrementing a logical counter every time a new transaction
starts .Timestamp protocol is a concurrency control protocol in which the fundamental
goal is to order the transactions globally in such a way that older transactions get
priority in the event of a conflict.

Timestamp TS(Ti) is assigned by the database system before the transaction Ti starts
its execution .The timestamps of the transactions determine the serializability order.
Thus, if TS(Ti) < TS(Tj), then the system must ensure that the produced schedule is
equivalent to a serial schedule in which Ti appears before Tj There are two timestamp
values associated with each data item Q:

• W-Timestamp(Q): It denotes the largest timestamp of any transaction that executed

write(Q) operation successfully
• R-Timestamp(Q): It denotes the largest timestamp of any transaction that executed
read(Q) operation successfully

This ensures that any conflicting read and write operations are executed in timestamp
order

• Suppose transaction Ti issues read(Q):

• If TS(Ti) < W-TS(Q), then Ti needs to read a value of Q that was already
overwritten. Hence, the read operation is rejected and Ti is rolled back
• If TS(Ti) ≥ W-TS(Q), then the read operation is executed, and R-TS(Q) is set to
maximum of R-TS(Q) and TS(Ti)
• Suppose transaction Ti issues write(Q):
• If TS(Ti) < R-TS(Q), then the value of Q that Ti is producing was needed previously,
and the system assumed that the value would never be produced. Hence, the system
rejects the write operation and rolls Ti back
• If TS(Ti) < W-TS(Q), then Ti is attempting to write an obsolete value of Q. Hence,
the system rejects this write operation and rolls Ti back
• Otherwise, the system executes the write operation and sets W-TS(Q) to TS(Ti)

The timestamp ordering protocol always ensures conflict serializability. This is

because conflicting operations are processed in timestamp order .The protocol ensures
freedom from deadlock, since no transaction ever waits. However, there is a
possibility of starvation of long transactions if a sequence of conflicting short
transactions causes repeated restarting of the long transaction .If a transaction is found
to be getting restarted repeatedly; conflicting transactions need to be temporarily
blocked to enable the transaction to finish.

Q2.State the process of Log based recovery and shadow paging.

The recovery manager of a database system is responsible for ensuring two important
properties of transactions:
• atomicity
• durability

It ensures the atomicity by undoing the actions of transactions that do not commit. It
ensures the durability by making sure that all actions of committed transactions
survive in case of system crashes and media failures.

SHADOW PAGING -
This scheme is based on making copies of the database called shadow copies and it
assumes that only one transaction is active at a time.This scheme assumes that the
database is simply a file on disk. A pointer called db-pointer is maintained on disk; it
points to the current copy of the database.

Unfortunately, this implementation is extremely inefficient in the context of large

database, since executing a single transaction requires copying the entire database.
Also, the implementation does not allow transactions to execute concurrently with one
another. Thus, this cannot be used for efficient recovery.

LOG BASED RECOVERY-

Log is a sequence of log records, recording all the update activities in the database. It
is kept on stable storage. There are several types of log records. An update log record
describes a single database write. It has the following fields:

• Transaction Identifier: This is the unique identifier of the transaction that

performed the write operation.
• Data-item Identifier: This is the unique identifier of the data item written. Typically,
it is the location on disk of the data item.
• Old Value: This is the value of the data item prior to the write operation.
• New Value: This is the value that the data item will have after the write operation.

Various types of log records are:

• <Ti start>: Transaction Ti has started
• <Ti, xj,v1,v2>: Transaction Ti has performed a write operation on the data item xj .
This data item xj had value v1 before the write, and will have value v2 after the write
• <Ti commit>: Transaction Ti has committed
• <Ti abort>: Transaction Ti has aborted

When a transaction performs a write operation, it is essential that the log record for
that write be created before the database is modified.For log records to be useful for
recovery from system and disk failures, the log must reside in stable storage The log
contains a complete record of all database activities.

Deferred Database Modification.

This scheme ensures transaction atomicity by recording all the database modifications
in the log, but deferring the execution of all write operations of a transaction until the
transaction
partially commits .
The execution of transaction Ti proceeds as follows:
• Before Ti starts its execution, a record <Ti start> is written to the log.
• A write(X) operation by Ti results in the writing of a new record to the log as <Ti , X,
V>, where V is the new value of X. For this scheme, the old value is not required.
• When Ti partially commits, a record <Ti commit> is written to the log.

Suppose the transactions are executed serially in the order T1 followed by T2; and the
initial values of accounts A, B and C before the execution took place were $1000,
$2000 and $3000
respectively.

The values of different data items are changed in the database only after their
corresponding log records have been updated in the log.

Redo(Ti): It sets the value of all data items updated by transaction Ti to the new
values. The set of data items updated by Ti and their respective new values can be
found in the log.
The redo operation must be idempotent, i.e. executing it several times must be
equivalent to executing it once Transaction Ti needs to be redone iff the log contains
both the record <Ti start> and the record <Ti commit>.Thus, if the system crashes
after the transaction completes its execution, the recovery scheme uses the
information in the log to restore the system to a previous consistent state after the
transaction had completed.

Case-1: Crash occurs just before <T1 commit>

Database Log
<T1 start>
<T1,A,900>
<T1,B,2100>
When the system recovers, no redo actions need to be taken,because no commit
record appears in the log. The log records of the incomplete transaction T1 can be
deleted from the log.

Case-2 Crash occurs just after <T1 commit>

Database Log
<T1 start>
<T1,A,900>
<T1,B,2100>
<T1 commit>

When the system recovers, the operation redo(T1) is performed since the record
<T1 commit> appears in the log.

Case-3: Crash occurs just before <T2 commit>

Database Log
<T1 start>
<T1,A,900>
<T1,B,2100>
<T1 commit>
<T2 start>
<T2,C, 2900>

When the system recovers, the operation redo(T1) is performed since the record <T1
commit> appears in the log. The log records of the incomplete transaction T2 can be
deleted from the log.

Case-4: Crash occurs just after <T2 commit>

Database Log
<T1 start>
<T1,A,900>
<T1,B,2100>
<T1 commit>
<T2 start>
<T2,C, 2900>
<T2 commit>

When the system recovers, two commit records are found in the log. Thus, the system
must perform operations redo(T1) and redo(T2) in the order in which their commit
records appear in the log.

Immediate Database Modification

This scheme allows database modifications to be output to the database while the
transaction is still in the active state. Data modifications written by active transactions
are called uncommitted modifications. In the event of a crash or a transaction failure,
the system must use the old-value field of the log records to restore the modified data
items to the value they had prior to the start of the transaction. The undo operation
accomplishes this restoration.
The execution of transaction Ti proceeds as follows:
• Before Ti starts its execution, the system writes the record <Ti start> to the log.
• During its execution, any write(X) operation by Ti is preceded by the writing of the
appropriate new update record to the log.
• When Ti partially commits, the system writes the record <Ti commit> to the log.

Database Log
<T1 start>
<T1,A,1000,900>
<T1,B,2000,2100>
<T1 commit>
<T2 start>
<T2,C, 3000,2900>
<T2 commit>

The recovery scheme uses two recovery procedures:

• Undo(Ti): It restores the value of all data items updated by transaction Ti to the old
values
• Redo(Ti): It sets the value of all data items updated by transaction Ti to the new
values
The undo and redo operations must be idempotent Transaction Ti needs to be undone
if the log contains the record <Ti start>, but doesn’t contain the record <Ti commit>
Transaction Ti needs to be redone if the log contains both the record <Ti start> and
the record <Ti commit>
Case-1: Crash occurs just before <T1 commit>

Database Log
<T1 start>
<T1,A,1000,900>
<T1,B,2000,2100>

When the system recovers, it finds the record <T1 start> in the log, but no
corresponding <T1 commit> record. Thus, T1 must be undone, so an undo(T1) is
performed.

Case-2 Crash occurs just after <T1 commit>

Database Log
<T1 start>
<T1,A,1000,900>
<T1,B,2000,2100>
<T1 commit>

When the system recovers, the operation redo(T1) must be performed since the log
contains both the record <T1 start> and the record <T1 commit>
Case-3: Crash occurs just before <T2 commit>

Database Log
<T1 start>
<T1,A,1000,900>
<T1,B,2000,2100>
<T1 commit>
<T2 start>
<T2,C, 3000,2900>

When the system recovers, two recovery actions need to be taken. The undo(T2) must
be performed, because 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 record <T1 start> and the record <T1 commit>

Case-4: Crash occurs just after <T2 commit>

Database Log
<T1 start>
<T1,A,1000,900>
<T1,B,2000,2100>
<T1 commit>
<T2 start>
<T2,C, 3000,2900>
<T2 commit>
When the system recovers, both T1 and T2 need to be redone, since the records <T1
start> and <T1 commit> appear in the log, as do the records <T2 start> and <T2
commit>

Checkpoints
When a system failure occurs, we must consult the log to determine those transactions
that need to be redone and those that need to be undone. For this, we need to search
the entire
log to determine this information.
There are two major difficulties with this approach:
• The search process is time consuming.
• Most of the transactions that need to be redone have already written their updates
into the database. Although redoing them will cause no harm, it will nevertheless
cause recovery to take longer time. To reduce these types of overhead, checkpoints
can be used
• Output onto stable storage all log records currently residing in main memory
• Output to the disk all modified buffer blocks
• Output onto stable storage a log record <checkpoint>

While a checkpoint is in progress, transactions are not allowed to perform any update
actions such as writing to a buffer block or writing a log record .After a failure has
occurred, the recovery scheme examines the log to determine the most recent
transaction Ti that started executing before the most recent checkpoint took place.
• Scan backwards from end of log to find the most recent <checkpoint> record
• Continue scanning backward till a record <Ti start> is found
• Once the system has identified transaction Ti , the redo and undo operations need to
be applied to only transaction Ti and all transactions Tj that started executing
after transaction Ti . Let these transactions are denoted by the set T. The earlier part of
the log can be ignored and can be erased whenever desired
• For all transactions starting from Ti or later with no <Ti commit> record in the log,
execute undo(Ti)
• Scanning forward in the log, for all transactions starting from Ti or later with a <Ti
commit>, execute redo(Ti)

• Transaction T1 has to be ignored

• Transactions T2 and T3 have to be redone
• T4 has to be undone
By taking checkpoints periodically, the DBMS can reduce the amount of work to be
done during restart in the event of a subsequent crash.