Department of Information Technology

Database Management System

Lecture notes

Q) What is the transaction system? List the ACID properties of transactions. Discuss the transaction
failures also. (10 marks)

Transaction Concept
 A transaction is a unit of program execution that accesses and possibly updates various data items.
 A transaction must see a consistent database.
 During transaction execution the database may be inconsistent.
 When the transaction is committed, the database must be consistent.
 Two main issues to deal with:
o Failures of various kinds, such as hardware failures and system crashes
o Concurrent execution of multiple transactions

ACID Properties
 Atomicity: Either all operations of the transaction are properly reflected in the database or none
are.
 Consistency: Execution of a transaction in isolation preserves the consistency of the database.
 Isolation. Although multiple transactions may execute concurrently, each transaction must be
unaware of other concurrently executing transactions. Intermediate transaction results must be
hidden from other concurrently executed transactions. That is, for every pair of transactions Ti and
Tj, it appears to Ti that either Tj, finished execution before Ti started, or Tj started execution after Ti
finished.
 Durability: After a transaction completes successfully, the changes it has made to the database
persist, even if there are system failures.

Example of Fund Transfer

 Transaction to transfer $50 from account A to account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
 Consistency requirement – the sum of A and B is unchanged by the execution of the transaction.
 Atomicity requirement — if the transaction fails after step 3 and before step 6, the system should
ensure that its updates are not reflected in the database, else an inconsistency will result.
 Durability requirement — once the user has been notified that the transaction has completed (i.e.,
the transfer of the $50 has taken place), the updates to the database by the transaction must persist
despite failures.
 Isolation requirement — if between steps 3 and 6, another transaction is allowed to access the
partially updated database, it will see an inconsistent database (the sum A + B will be less than it
should be).

Shankar Thawkar, Sr. Lect. Dept of IT

Transaction State
 Active, the initial state; the transaction stays in this state while it is executing
 Partially committed, after the final statement has been executed.
 Failed, after the discovery that normal execution can no longer proceed.
 Aborted, after the transaction has been rolled back and the database restored to its state prior to the
start of the transaction. Two options after it has been aborted:
o restart the transaction – only if no internal logical error
o kill the transaction
 Committed, after successful completion.

Concurrent Executions

 Multiple transactions are allowed to run concurrently in the system. Advantages are:
o increased processor and disk utilization, leading to better transaction throughput: one
transaction can be using the CPU while another is reading from or writing to the disk
o reduced average response time for transactions: short transactions need not wait behind
long ones.
 Concurrency control schemes – mechanisms to achieve isolation, i.e., to control the interaction
among the concurrent transactions in order to prevent them from destroying the consistency of the
database

Shankar Thawkar, Sr. Lect. Dept of IT

Q) What do you understand Serializability of schedules. Explain with some suitable examples.
Q) What do you mean by serializabilty? Discuss the conflict and view serializabilty with the suitable
example. Discuss the testing of Serializability also.

Schedules & Serializable schedules

 Schedules – When the transactions are executed concurrently in interleaved fashion then the order
of execution of transactions is called schedule.

 Serial Schedule -A schedule is said to be serial if, transactions are executed serially. i.e. one after
another. Other wise it is said to be non-Serial.

Example Schedules
 Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A to B. The following is a
serial schedule, in which T1 is followed by T2.

Schedule 1

 Let T1 and T2 be the transactions defined previously. The following schedule is not a serial
schedule, but it is equivalent to Schedule 1, the sum A + B is preserved

Shankar Thawkar, Sr. Lect. Dept of IT

  The following concurrent schedule (Schedule 4) does not preserve the value of the sum A + B.

 Since, when the schedules are executed non-serially, it may produce wrong results. So
serializabilty is used to determine which of the non-serial schedules produce correct results
and which

Serializability of Schedules
Serializable Schedule -A schedule S of n transactions is serializable if it is equivalent to some serial
schedule of the same n transactions.

 Basic Assumption – Each transaction preserves database consistency.

 Thus serial execution of a set of transactions preserves database consistency.
 A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule. Different
forms of schedule equivalence give rise to the notions of:

1. Conflict serializability
2. View serializability

1. Conflict equivalent and Conflict Serializability

 Two Instructions in the schedule are said to conflict (equivalent) if the following three
conditions holds.

i) They belong to different transactions.

ii) They access the same data item.
iii) If one of the instructions is write

 If a schedule S can be transformed into a schedule S´ by a series of swaps of non-conflicting

instructions, we say that S and S´ are conflict equivalent.

Shankar Thawkar, Sr. Lect. Dept of IT

  Schedule 3 below can be transformed into Schedule 1, a serial schedule where T2 follows T1,
by series of swaps of non-conflicting instructions. Therefore Schedule 3 is conflict serializable.

Schedule 3 Schedule 1

 conflict serializable - schedule S is said to be conflict serializable if it is conflict equivalent to

some serial schedule S’

 Example of a schedule that is not conflict serializable:

T1 T2
read(Q)
write(Q)
write(Q)

We are unable to swap instructions in the above schedule to obtain either the serial schedule < T3, T4 >, or
the serial schedule < T4, T3 >.

 Schedule 3 below can be transformed into Schedule 1, a serial schedule where T2 follows T1, by
series of swaps of non-conflicting instructions. Therefore Schedule 3 is conflict serializable.

Shankar Thawkar, Sr. Lect. Dept of IT

 Following algorithm is used to test, whether the given schedule is conflict serializable or not. The
algorithm used the graph G= (V, E), called precedence graph. Where T1, T2…..Tn belongs to V.

Algorithm: (Testing of Serializability)

i) for each transaction create a node
ii) add an edge TiTj if,
a) Ti execute read(X) before Tj execute write(X)
b) Ti execute write(X) before Tj execute read(X)
c) Ti execute write(X) before Tj execute write(X)

iii) The schedule S is serializable if and only if the precedence graph has no cycles.

Example: see class Notes

View equivalent and view Serializabilty

 Let S and S´ be two schedules with the same set of transactions. S and S´ are view equivalent if
the following three conditions are met:
o For each data item Q, if transaction Ti reads the initial value of Q in schedule S, then
transaction Ti must, in schedule S´, also read the initial value of Q.
o For each data item Q if transaction Ti executes read(Q) in schedule S, and that value was
produced by transaction Tj (if any), then transaction Ti must in schedule S´ also read the
value of Q that was produced by transaction Tj .
o For each data item Q, the transaction (if any) that performs the final write (Q) operation in
schedule S must perform the final write (Q) operation in schedule S´.

 view Serializabilty -A schedule S is view serializable it is view equivalent to a serial

schedule.
 Every conflict serializable schedule is also view serializable.
 Consider following schedule — a schedule which is view-serializable but not conflict serializable.

 Since above schedule is view equivalent to serial schedule <T3, T4, T6>, so it is view
serializable.
 Every conflict serializable schedule is view serializable, but not necessary that every view
serializable schedule is conflict serializable.
 Every view serializable schedule that is not conflict serializable has blind writes.
 Transactions that perform write operations without read are called blind writes. (as in above
schedules for transaction T4 and T5)

************************************************************************************

Shankar Thawkar, Sr. Lect. Dept of IT

Q. What is recoverable schedule? Why is recoverability of schedules desirable? Are there any
circumstances under which it would be desirable to allow non-recoverable schedules?

Recoverability

 If a transaction Ti fails we have to undo the effect of Ti , to ensure the atomicity property of the
transaction.

1. Recoverable schedule —A schedule is said to be recoverable, if for each pair of

transactions Ti and Tj , Tj reads a data items previously written by a transaction Ti , the
commit operation of Ti appears before the commit operation of Tj otherwise schedule is
said to be non-recoverable.

T1 T2
read(A)
write(A)
Commit
read(A)
Commit

 Since the above schedule is recoverable, becoz T2 read A that was written by T1 and commit of
T1 appears before the commit of T2.
 The following schedule is not recoverable becoz T2 commits before T1. Also if T1 fails before
commits, we have to rollback T2.

T1 T2
read(A)
write(A)
read(A)
Commit
Commit
Read(B)

2. Cascading rollback – a single transaction failure leads to a series of transaction rollbacks. Consider
the following schedule -

- If T10 fails, T11 and T12 must also be rolled back.Can lead to the undoing of a significant amount of
work

Shankar Thawkar, Sr. Lect. Dept of IT


Cascadeless schedules — A schedule is said to be Cascadeless, if for each pair of transactions Ti
and Tj , such that Tj reads a data items previously written by a transaction Ti , the commit operation
of Ti appears before the read operation of Tj.

Every cascadeless schedule is also recoverable

It is desirable to restrict the schedules to those that are cascadeless

3.Strict Schedule : In this schedule a transaction can neither read nor write an item X until the last
transaction that write X has committed

Other Important Question

Q. Consider the two transactions:

T1: read(A)
read(B)
if A=0 then B=B+1
write (B)

T2: read (B)

Read (A)
If B=0 then A=A+1
Write (A)

Let the consistency requirement the

A=0 V B=0
With A=B=0 the initial values.
i) Show that every serial execution involving these two transactions preserves the consistency
of the database.
ii) Show a concurrent execution of T1 and T2 that produces a non-serializable schedule.
iii) Is there a concurrent execution of T1 and T2 that produces a serializable schedule?

. Q. Explain the distinction between serial schedule and serializable schedule.

Q. List the ACID properties. Explain usefulness of each.
Q. Why do we emphasize conflict Serializability rather than view Serializability.

Q. What are schedules? Define conflict and view serializable schedules. State whether the following
schedules are conflict serializable or not. Justify your answer.
i) r1(X), r3(X), w1(X), r2(X), w3(X);
ii) r1(X), r3(X), w3(X), w1(X), r2(X);
iv) r3(X), r2(X),w3(X), r1(X), w1(X);

Shankar Thawkar, Sr. Lect. Dept of IT

 Recovery System

Q. Discuss different types of failures. What is mean by catastrophic failure?

Types of failures
Failures are generally classified as transaction, system and media failures. The transaction may be fail due
to-

1. A computer failure (System crash): a power failure or other hardware or software failure
causes the system to crash. If the hardware crashes the content of memory may be lost.
2. Disk failure: a R/W head crash or similar disk failure destroys all or part of disk storage.
This may happen during r/w operation of the transaction.
3. A transaction or System error :
- Some operations of transactions may causes to fail the transaction such as integer
overflow, divide by zero or wrong parameters (logical errors).
- A transaction may fail due to system error such as deadlock or user may interrupt
execution of transaction.
4. Concurrency control enforcement: Concurrency control method may decide to abort the
transaction, to start later becoz it violet Serializability or transaction in deadlock state.
5. Physical problems or catastrophes: Transaction may be fail due to power or air
conditioning failure, fire, theft, overwriting disk by mistake. Catastrophic failure is a
sudden and total failure of some systems from which recovery is impossible.

Q. What is log? How it is maintained discuss the silent features of deferred database modifications
and immediate database modification strategies in brief.

Log-Based Recovery

 A structure used to record database modifications is a log.

 The log is a sequence of log records, and maintains a record of update activities on the database.
 When transaction Ti starts, it registers itself by writing a
<Ti start>log record
 Before Ti executes write(X), a log record <Ti, X, V1, V2> is written, where V1 is the value of X
before the write, and V2 is the value to be written to X.
o Log record notes that Ti has performed a write on data item Xj Xj had value V1 before the
write, and will have value V2 after the write.
 When Ti finishes it last statement, the log record <Ti commit> is written.

 Two approaches using logs

o Deferred database modification
o Immediate database modification

1. Deferred Database Modification

 The deferred database modification scheme records all modifications to the log, but
defers all the writes operations of the transaction until the transaction partially commit.
 When the transaction partially commits, information in log is used for executing deferred
writes.

Shankar Thawkar, Sr. Lect. Dept of IT

  If the system crash during execution of transaction then log is ignored.
 Transaction starts by writing <Ti start> record to log.
 A write(X) operation results in a log record <Ti, X, V> being written, where V is the new
value for X
i. Note: old value is not needed for this scheme
 The write is not performed on X at this time, but is deferred.
 When Ti partially commits, <Ti commit> is written to the log
 Finally, the log records are read and used to actually execute the previously deferred writes.
 During recovery after a crash, a transaction needs to be redone if and only if both <Ti
start> and<Ti commit> are there in the log.
 Example transactions T0 and T1 (T0 executes before T1):

T0: read (A) T1 : read (C)

A: - A - 50 C:- C- 100
Write (A) write (C)
read (B)
B:- B + 50
write (B)

 Below we show the log for execution of T0 T1 . Let A=1000, B=2000 and C=700
<T0 Start>
< T0 , 950>
< T0 , 2050>
< T0 , commit>
< T1, start>
< T1 , 600>
< T1, commit>

 The recovery system uses the following procedure to handle any failure
o Redo(Ti) - set values of all data items updated by Ti , to new value

 Redo (Ti) is performed when log contain < T1, start> and < T1, commit>
 Consider the flowing three cases of failure –
Case a: system fail after W(B)
Case b: System fail after W(C)
Case c: System fail after T1 commits.

a) No redo actions need to be taken

b) redo(T0) must be performed since <T0 commit> is present
c) redo(T0) must be performed followed by redo(T1) since <T0 commit> and <Ti commit>
are present

Shankar Thawkar, Sr. Lect. Dept of IT

 2. Immediate Database Modification

 In this scheme database modifications to be written (output) to the database while transaction is in
active state.
 These modifications are called uncommitted transactions.
 When transaction fails, the recovery system uses the log which contains old and new values of data
items to restore the system.
 Example consider the transactions T0 and T1 as shown in above technique.(T0 executes before T1):

Log Record Write to database

<T0 start>
<T0, A, 1000, 950>
<To, B, 2000, 2050>
A = 950
B = 2050
<T0 commit>
<T1 start>
<T1, C, 700, 600>
C = 600
<T1 commit>

 Recovery system uses following procedure to handle any failures :

undo (Ti) - set value of all data items updated by Ti to their old values
redo(Ti)- sets the value of all data items updated by Ti to the new values.
 Both operations must be idempotent. That is, even if the operation is executed multiple times the
effect is the same as if it is executed once
 Transaction Ti needs to be undone if the log contains the record
<Ti start>, but does not 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>.
 Consider the flowing three cases of failure –
Case a: system fail after W(B)
Case b: System fail after W(C)
Case c: System fail after T1 commits.
 Let A=1000, B=2000 and C=700

Recovery actions in each of the above cases are:

(a) undo (T0): B is restored to 2000 and A to 1000.
(b) undo (T1) and redo (T0): C is restored to 700, and then A and B are set to 950 and 2050 respectively.
(c) redo (T0) and redo (T1): A and B are set to 950 and 2050 respectively. Then C is set to 600

Shankar Thawkar, Sr. Lect. Dept of IT

Q. Write a short note on checkpoint.

Checkpoints

 Since when the failure occurs system consults the log to determine which transaction need
to be redone and which to be undone, so the above procedures has following disadvantages-
o searching the entire log is time-consuming
o we might unnecessarily redo transactions which have already output their updates to
the database.
 So checkpoints are used to reduce the above said problems.
 System periodically performs checkpoints.
 During recovery we need to consider only the most recent transaction Ti that started before
the checkpoint and transactions that started after Ti.
 Scan backwards from end of log to find the most recent <checkpoint> record
 Continue scanning backwards till a record <Ti start> is found.
 Need only consider the part of log following above start record. Earlier part of log can be
ignored during recovery, and can be erased whenever desired.
 For all transactions (starting from Ti or later) with no <Ti commit>, execute undo(Ti).
(Done only in case of immediate modification.)
 Scanning forward in the log, for all transactions starting from Ti or later with a <Ti
commit>, execute redo(Ti).

Shankar Thawkar, Sr. Lect. Dept of IT

Q. What are locks? Differentiate Shared Mode and Exclusive mode Locks. How can
serializability be ensured by using lock based protocols. With reference to two phase locking
protocol (2PL), explain how the upgrading and downgrading of locks takes place. Explain
with suitable example.

Lock-Based Protocols

 One of the way to ensure serializability of concurrent execution, is the lock based protocols.
 A lock is a mechanism to control concurrent access to a data item
 Lock: - Lock is a variable that specifies the status of the data item with respect to read or write
operations applied on it.
 Data items can be locked in two modes :
o exclusive (X) mode – If Ti obtain a exclusive mode lock of data item Q, then Ti can read
and write Q.
o shared (S) mode - If Ti obtain a shared mode lock of data item Q, then Ti can read but can
not write Q.
 Lock requests are made to concurrency-control manager. Transaction can proceed only after
request is granted.

Lock-compatibility matrix

i.e. If Ti has a lock on data item Q and if Tj requesting a lock on Q, then lock is granted only if it is
compatible. Since shared mode lock is compatible with shared mode lock i.e. at any time several S-lock
can be granted.
 Lock can be release by unlock procedure.

 Example of a transaction performing locking:

T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
display(A+B)
unlock(B);

 A locking protocol is a set of rules followed by all transactions while requesting and releasing
locks. Locking protocols restrict the set of possible schedules.

 Deadlock is also possible in lock based protocols. Consider the following two transactions:

Shankar Thawkar, Sr. Lect. Dept of IT

 -Since Neither T3 nor T4 can make progress — executing lock-S(B) causes T4 to wait for T3 to release
its lock on B, while executing lock-X(A) causes T3 to wait for T4 to release its lock on A.
-Such a situation is called a deadlock.
 To handle a deadlock one of T3 or T4 must be rolled back and its locks released.

Starvation is also possible in lock based protocols: Suppose T2 has an S-lock on data item. Another
transaction T1 request an X-lock on same data item, then T1 has to wait for T2 to release a lock.
Meanwhile transaction T3 requested a S-lock on same data item then lock is granted to T3, and T1 is still
waiting for T3 to release a lock on data item, this situation is called starvation.

Q. What is two phases locking. Describe with the help of example. Will 2PL result in deadlock?
Justify your answer with help of an example. Discuss the recovery with concurrent
transaction also

Q. With reference to two phase locking protocol (2PL), explain how the upgrading and
downgrading of locks takes place. Explain with suitable example.

The Two-Phase Locking Protocol (2PL)

This is a protocol which ensures conflict-serializable schedules. It works in two phases

Growing Phase – In this phase a transaction may obtain locks but can not release any locks.
Shrinking Phase – In this phase a transaction may release a lock but can not obtain new locks.

Initially transaction in growing phase. Once the transaction releases the lock, it enters in the shrinking
phase and it can not issue request for another locks.
 The protocol assures serializability. It can be proved that the transactions can be serialized in the order
of their lock points (i.e. the point where a transaction acquired its final lock).
 Two-phase locking does not ensure freedom from deadlocks. Consider the flowing schedule, which is
in 2PL but transactions are in deadlock states.

Shankar Thawkar, Sr. Lect. Dept of IT

Cascading roll-back is possible under two-phase locking. Consider the flowing example

T5 T6 T7
LOCK-X(A)
R(A)
W(A)
UNLOCK(A)
LOCK-X(A)
R(A)
W(A)
UNLOCK(A)
LOCK-S(A)
R(A)
Since failure of T5 after read (A) leads to cascading rollback of T6 and T7.

This problem of cascading rollbacks can be voided by modifying 2PL to strict two-phase locking. In
this method a transaction must hold all its exclusive locks till it commits/aborts.

Rigorous two-phase locking is even stricter: here all locks (shared and exclusive) are held by the
transactions till they commit/abort. In this protocol transactions can be serialized in the order in which they
commit.

There can be conflict serializable schedules that cannot be obtained if two-phase locking is used.
However, in the absence of extra information (e.g., ordering of access to data), two-phase locking is
needed for conflict serializability in the following sense:
o Given a transaction Ti that does not follow two-phase locking, we can find a transaction Tj
that uses two-phase locking, and a schedule for Ti and Tj that is not conflict serializable.

Lock Conversions in 2PL : Consider the following example

T1: r(a1) T2: r(a1)

r(a2) r(a2)
r(a3) display(a1+a2)
.
.
r(an)
w1(a1)

– Growing Phase: - Can acquire shared and exclusive locks on data items.
- Convert shared locks to exclusive mode (Upgraded)

– Shrinking Phase: - Can release shared and exclusive locks on data items.
- Convert exclusive locks to shared mode locks (Downgraded)

Since in above example T1 obtain shared mode lock on a1 then before w(a1), lock is upgraded to
exclusive mode.

This protocol assures serializability. But still relies on the programmer to insert the various locking
instructions.

Shankar Thawkar, Sr. Lect. Dept of IT