UNIT-V CONCURRENCY CONTROL

Concurrency Control in DBMS

When several transactions execute concurrently without any rules and protocols, various problems arise that may harm
the data integrity of several databases. These problems are known as concurrency control problems. Therefore several
rules are designed, to maintain consistency in the transactions while they are executing concurrently which are known
as concurrency control protocols.
What is concurrency control in DBMS?
A transaction is a single reasonable unit of work that can retrieve or may change the data of a database. Executing each
transaction individually increases the waiting time for the other transactions and the overall execution also gets delayed.
Hence, to increase the throughput and to reduce the waiting time, transactions are executed concurrently.
Example: Suppose, between two railway stations, A and B, 5 trains have to travel, if all the trains are set in a row and
only one train is allowed to move from station A to B and others have to wait for the first train to reach its destination
then it will take a lot of time for all the trains to travel from station A to B. To reduce time all the trains should be
allowed to move concurrently from station A to B ensuring no risk of collision between them.
When several transactions execute simultaneously, then there is a risk of violation of the data integrity of several
databases. Concurrency Control in DBMS is a procedure of managing simultaneous transactions ensuring
their atomicity, isolation, consistency and serializability.
Concurrency Control Problems
Several problems that arise when numerous transactions execute simultaneously in a random manner are referred to as
Concurrency Control Problems.
Dirty Read Problem
The dirty read problem in DBMS occurs when a transaction reads the data that has been updated by another transaction
that is still uncommitted. It arises due to multiple uncommitted transactions executing simultaneously.
Example: Consider two transactions A and B performing read/write operations on a data DT in the database DB. The
current value of DT is 1000: The following table shows the read/write operations in A and B transactions

Transaction A reads the value of data DT as 1000 and modifies it to 1500 which gets stored in the temporary buffer.
The transaction B reads the data DT as 1500 and commits it and the value of DT permanently gets changed to 1500 in
the database DB. Then some server errors occur in transaction A and it wants to get rollback to its initial value, i.e.,
1000 and then the dirty read problem occurs.
Unrepeatable Read Problem
The unrepeatable read problem occurs when two or more different values of the same data are read during the read
operations in the same transaction.
Example: Consider two transactions A and B performing read/write operations on a data DT in the database DB. The
current value of DT is 1000: The following table shows the read/write operations in A and B transactions.

Transaction A and B initially read the value of DT as 1000. Transaction A modifies the value of DT from 1000 to 1500
and then again transaction B reads the value and finds it to be 1500. Transaction B finds two different values of DT in
its two different read operations.

Phantom Read Problem

In the phantom read problem, data is read through two different read operations in the same transaction. In the first
read operation, a value of the data is obtained but in the second operation, an error is obtained saying the data does not
exist.
Example: Consider two transactions A and B performing read/write operations on a data DT in the database DB. The
current value of DT is 1000: The following table shows the read/write operations in A and B transactions.

Transaction B initially reads the value of DT as 1000. Transaction A deletes the data DT from the database DB and
then again transaction B reads the value and finds an error saying the data DT does not exist in the database DB.

Lost Update Problem

The Lost Update problem arises when an update in the data is done over another update but by two different
transactions.
Example: Consider two transactions A and B performing read/write operations on a data DT in the database DB. The
current value of DT is 1000: The following table shows the read/write operations in A and B transactions.
Transaction A initially reads the value of DT as 1000. Transaction A modifies the value of DT from 1000 to
1500 and then again transaction B modifies the value to 1800. Transaction A again reads DT and finds 1800
in DT and therefore the update done by transaction A has been lost.
Concurrency Control Protocols
To avoid concurrency control problems and to maintain consistency and serializability during the execution of
concurrent transactions some rules are made. These rules are known as Concurrency Control Protocols.
Introduction to Lock-Based Protocol
CONCURRENCY CONTROL

Concurrency Control is the working concept that is required for controlling and managing theconcurrent
execution of database operations and thus avoiding the inconsistencies in the database. Thus, for maintaining
the concurrency of the database, we have the concurrency control protocols.

Concurrency Control Protocols

The concurrency control protocols ensure the atomicity, consistency, isolation, durability and serializability of
the concurrent execution of the database transactions. Therefore, these protocols are categorized as:
o Lock Based Concurrency Control Protocol
o Time Stamp Concurrency Control Protocol
o Validation Based Concurrency Control Protocol

Lock-Based Protocol
In this type of protocol, any transaction cannot read or write data until it acquires anappropriate lock on it. There
are two types of lock:

1. Shared lock:
o It is also known as a Read-only lock. In a shared lock, the data item can only read bythe transaction.
o It can be shared between the transactions because when the transaction holds a lock,then it can't update the
data on the data item.

2. Exclusive lock:
o In the exclusive lock, the data item can be both reads as well as written by thetransaction.
o This lock is exclusive, and in this lock, multiple transactions do not modify the samedata simultaneously.

TWO-PHASE LOCKING (2PL)

o The two-phase locking protocol divides the execution phase of the transaction into three parts.
o In the first part, when the execution of the transaction starts, it seeks permission forthe lock it requires.
o In the second part, the transaction acquires all the locks. The third phase is started assoon as the transaction
releases its first lock.
o In the third phase, the transaction cannot demand any new locks. It only releases theacquired locks.

There are two phases of 2PL:

Growing phase: In the growing phase, a new lock on the data item may be acquired by thetransaction, but none
can be released.
Shrinking phase: In the shrinking phase, existing lock held by the transaction may bereleased, but no new
locks can be acquired.
In the below example, if lock conversion is allowed then the following phase can happen:
1. Upgrading of lock (from S(a) to X (a)) is allowed in growing phase.
2. Downgrading of lock (from X(a) to S(a)) must be done in shrinking phase.

Example:

The following way shows how unlocking and locking work with 2-PL.

Transaction T1:
o Growing phase: from step 1-3
o Shrinking phase: from step 5-7
o Lock point: at 3

Transaction T2:
o Growing phase: from step 2-6
o Shrinking phase: from step 8-9
o Lock point: at 6

4. Strict Two-phase locking (Strict-2PL)

o The first phase of Strict-2PL is similar to 2PL. In the first phase, after acquiring all the locks, the transaction
continues to execute normally.
o The only difference between 2PL and strict 2PL is that Strict-2PL does not release a lock after using it.
o Strict-2PL waits until the whole transaction to commit, and then it releases all the locks at a time.
o Strict-2PL protocol does not have shrinking phase of lock release.
To avoid concurrency control problems and to maintain consistency and serializability during the execution of
concurrent transactions some rules are made. These rules are known as Concurrency Control Protocols.
Introduction to Lock-Based Protocol
We can define a lock-based protocol in DBMS as a mechanism that is responsible for preventing a transaction from
reading or writing data until the necessary lock is obtained. The concurrency problem can be solved by securing or
locking a transaction to a specific user. The lock is a variable that specifies which activities are allowed on a certain
data item.

Types of Locks in DBMS

In DBMS Lock based Protocols, there are two modes for locking and unlocking data items Shared Lock (lock-S) and
Exclusive Lock (lock-X). Let's go through the two types of locks in detail:
Shared Lock(S): The locks which disable the write operations but allow read operations for any data in a transaction
are known as shared locks. They are also known as read-only locks and are represented by 'S'.
Exclusive Lock(X): The locks which allow both the read and write operations for any data in a transaction are known
as exclusive locks. This is a one-time use mode that can't be utilized on the exact data item twice. They are represented
by 'X'.
Lock Compatibility Matrix

The two methods outlined below can be used to convert between the locks:
1. Conversion from a read lock to a write lock is an upgrade.
2. Conversion from a write lock to a read lock is a downgrade.
Types of Lock-Based Protocols
There are basically four lock based protocols in DBMS namely Simplistic Lock Protocol, Pre-claiming Lock
Protocol, Two-phase Locking Protocol, and Strict Two-Phase Locking Protocol. Let's go through each of these
lock-based protocols in detail.
Simplistic Lock Protocol
The simplistic method is defined as the most fundamental method of securing data during a transaction. Simple
lock-based protocols allow all transactions to lock the data before inserting, deleting, or updating it. After the
transaction is completed, the data item will be unlocked.
Pre-Claiming Lock Protocol
Pre-claiming Lock Protocols are known to assess transactions to determine which data elements require locks. Prior
to actually starting the transaction, it asks the Database management system for all of the locks on all of the data
items. The pre-claiming protocol permits the transaction to commence if all of the locks are obtained. Whenever
the transaction is finished, the lock is released. This protocol permits the transaction to roll back if all of the locks
are not granted and then waits until all of the locks are granted.

Two-phase Locking Protocol

If Locking as well as the Unlocking can be performed in 2 phases, a transaction is considered to follow the Two-
Phase Locking protocol. The two phases are known as the growing and shrinking phases.
Growing Phase: In this phase, we can acquire new locks on data items, but none of these locks can be released.
Shrinking Phase: In this phase, the existing locks can be released, but no new locks can be obtained.
Two-phase locking helps to reduce the amount of concurrency in a schedule but just like the two sides of a coin two-
phase locking has a few cons too. The protocol raises transaction processing costs and may have unintended
consequences. The likelihood of establishing deadlocks is one bad result.

Strict Two-Phase Locking Protocol

In DBMS, Cascaded rollbacks are avoided with the concept of a Strict Two-Phase Locking Protocol. This protocol
necessitates not only two-phase locking but also the retention of all exclusive locks until the transaction commits or
aborts. The two-phase is with deadlock.
It is responsible for assuring that if 1 transaction modifies data, there can be no other transaction that will be able to
read it until the first transaction commits. The majority of database systems use a strict two-phase locking protocol.
Starvation and Deadlock
When a transaction must wait an unlimited period for a lock, it is referred to as starvation. The following are the causes
of starvation:
When the locked item waiting scheme is not correctly controlled.
When a resource leak occurs.
The same transaction is repeatedly chosen as a victim.
Let's know how starvation can be prevented. Random process selection for resource or processor allocation should be
avoided since it encourages hunger. The resource allocation priority scheme should contain ideas like aging, in which
a process' priority rises as it waits longer. This prevents starvation.
Deadlock: In a circular chain, a deadlock situation occurs when two or more processes are expecting each other to
release a resource or when more than 2 processes are waiting for the resource.
Introduction to Validation Based Protocol in DBMS
Validation based protocol in DBM is a type of concurrency control techniques that works on the validation rules and
time-stamps. It is also known as the optimistic concurrency control technique. The protocol associated with three phases
for managing concurrent transactions such as read phase, validation phase, and write phase. The optimistic approach
of the protocol assumes less interference among concurrent transactions, hence there is no checking process happening
while the transactions are executed. This protocol is preferable for short transactions. It uses the local copy of the data
for the rollback mechanism that is used to manage rare conflict scenarios and avoids cascading rollbacks.
How Validation Based Protocol works in DBMS?
The Validation based protocol works based upon the following three phases
 Read and Execution Phase: Read phases involve read and execute an operation for Transaction T1. The
values of the multiple data items are being read in this phase and the protocol writes the data in a temporary
variable. The temporary variable is a local variable that holds the data item instead of writing it to the database.
 Validation Phase: The validation phase is an important phase of the concurrency protocol. It involves
validating the temporary value with the actual values in the database and to check the view serializability
condition.
 Write Phase: The write phase ensures valid data to be written to the database that is validated in the validation
phase. The protocol performs the rollback operation in case of an invalid scenario of the validation phase.
Various Timestamps Associated
Next, we will discuss various timestamps associated with each phase of the validation protocol. There are three
timestamps that control the serializability of the validation based protocol in the database management system, such
as.
Start (Timestamp): The start timestamp is the initial timestamp when the data item being read and executed in the
read phase of the validation protocol.
Validation (Timestamp): The validation timestamp is the timestamp when T1 completed the read phase and started
with the validation phase.
Finish (Timestamp): The finish timestamp is the timestamp when T1 completes the writing process in the writing
phase.
To manage the concurrency between transactions T1 and T2, the validation test process for T1 should validate all the
T1 operations should follow TS(T1) < TS(T2) where TS is the timestamp and one of the following condition should
be satisfying.
Finish T1 < Start T2
 In this condition, T1 completes all the execution processes before the T2 starts the operations.
 It regulates maintaining the serializability.
Start (T2) <Finish (T1) <Validate (T2)
 The validation phase of T2 should occur after the finish phase of T1. This scenario is useful for concurrent
transaction serializability.
 The Transactions are able to access the mutually exclusive database resource at a particular timestamp while
validating the protocol conditions.
The validation based protocol relies on the timestamp to achieve serializability. The validation phase is the deciding
phase for the transaction to be committed or rollback in the database. It works on the equation TS (T1) =Validation
(T1) where TS is the time stamp and T1 is the transaction.
How does the Validation Protocol Work?
We will discuss an example scenario to demonstrate how the validation protocol works

The transaction table is shown in the example associated with transaction T1 and transaction T2. It represents the
schedule produced using validation protocol.
The concurrent transaction process starts with T1 with a reading operation as Read (A) where A is the numeric data
element in the database. In the next step, the transaction T2 also reads the same data variable A after some time.
Transaction T2 performs an arithmetic operation by subtracting constant value 40 from the variable A. It is represented
as A=A-40 in the transaction table. The next step is a read operation on transaction T2 where it’s reading another
numerical value of variable B as the Read (B). After the read operation completed, the transaction T2 immediately
performs an arithmetic operation on the variable B. It uses the addition operator ‘+’ for adding a constant value as 80
to variable B. The addition operation is represented as B=B+80 in the transaction table.
In the next step of the concurrent transaction, T1 reads the variable B with operation Read (B). Now the validation
based protocol comes into the action in the transaction T1 that validates the time stamp of the start phase of T2 lesser
than the finishing phase time stamp of Transaction T1 and that is a lesser timestamp as the validate phase of Transaction
T2.
Similarly, in the Transaction T2, the validation based protocol validates the timestamps. In the example shown in the
table indicates both the validation based protocol is provided with a valid result based on the timestamp condition. And,
as the conclusive operations write operations are performed by the transaction T2 using Write (A) and Write (B)
statements.

Timestamp Ordering Protocol-

What is Timestamp Ordering Protocol?
 Timestamp ordering protocol maintains the order of transaction based on their timestamps.
 A timestamp is a unique identifier that is being created by the DBMS when a transaction enters into the
system. This timestamp can be based on the system clock or a logical counter maintained in the system.
  Timestamp helps identifying the older transactions (transactions that are waiting in line to be executed) and
gives them higher priority compared to the newer transactions. This make sure that none of the transactions
are pending for a longer period of time.
 This protocol also maintains the timestamps for the last read and last write on a data.
 For example, let’s say an old transaction T1 timestamp is TS (T1) and a new transaction T2 enters into the
system, timestamp assigned to T2 is TS (T2). Here TS (T1) < TS (T2) so the T1 has the higher priority
because its timestamp is less than timestamp of T2. T1 would be given the higher priority than T2. This is
how timestamp based protocol maintains the serializability order.
How a Timestamp ordering protocol works?
Let’s see how a timestamp ordering protocol works in a DBMS system. Let’s say there is data item A in the database.
W_TS (A) is the largest timestamp of a transaction that executed the operation write (A) successfully.
R_TS (A) is the largest timestamp of a transaction that executed the operation read (A) successfully.
1. Whenever a Transaction Tn issues a Write(A) operation, this protocol checks the following conditions:
 If R_TS(A) > TS(Tn) or if W_TS(A) > TS(Tn), then abort and rollback the transaction Tn and reject
the write (A) operation.
 If R_TS(A) <= TS(Tn) or if W_TS(A) <= TS(Tn) then execute Write(A) operation of Tn and
set W_TS(A) to TS(Tn).
2. Whenever a Transaction Tn issues a Read(A) operation, this protocol checks the following conditions:
 If W_TS(A) > TS(Tn), then abort and reject Tn and reject the Read(A) operation.
 If W_TS(A) <= TS(Tn), then execute the Read(A) operation of Tn and update the
timestamp R_TS(A).
Advantages of Timestamp based protocol
 Schedules managed using timestamp based protocol are serializable just like the two phase protocols
 Since older transactions are given priority which means no transaction has to wait for longer period of time
that makes this protocol free from deadlock.

Explain Log based recovery method.

Log based recovery
Deadlock in DBMS

A deadlock is a condition where two or more transactions are waiting indefinitely for one another to give
up locks. Deadlock is said to be one of the most feared complications in DBMS as no task ever gets
finished and is in waiting state forever.

For example: In the student table, transaction T1 holds a lock on some rows and needs to update some
rows in the grade table. Simultaneously, transaction T2 holds locks on some rows in the grade table and
needs to update the rows in the Student table held by Transaction T1.

Now, the main problem arises. Now Transaction T1 is waiting for T2 to release its lock and similarly,
transaction T2 is waiting for T1 to release its lock. All activities come to a halt state and remain at a
standstill. It will remain in a standstill until the DBMS detects the deadlock and aborts one of the
transactions.

DEADLOCK HANDLING in DBMS:-

1. Deadlock Avoidance

o When a database is stuck in a deadlock state, then it is better to avoid the database rather than
aborting or restating the database. This is a waste of time and resource.
o Deadlock avoidance mechanism is used to detect any deadlock situation in advance. A method
like "wait for graph" is used for detecting the deadlock situation but this method is suitable only
for the smaller database. For the larger database, deadlock prevention method can be used.
2. Deadlock Detection

In a database, when a transaction waits indefinitely to obtain a lock, then the DBMS should detect
whether the transaction is involved in a deadlock or not. The lock manager maintains a Wait for the
graph to detect the deadlock cycle in the database.

Wait for Graph

o This is the suitable method for deadlock detection. In this method, a graph is created based on
the transaction and their lock. If the created graph has a cycle or closed loop, then there is a
deadlock.
o The wait for the graph is maintained by the system for every transaction which is waiting for
some data held by the others. The system keeps checking the graph if there is any cycle in the
graph.

The wait for a graph for the above scenario is shown below:

3. Deadlock Prevention

o Deadlock prevention method is suitable for a large database. If the resources are allocated in such
a way that deadlock never occurs, then the deadlock can be prevented.
o The Database management system analyzes the operations of the transaction whether they can
create a deadlock situation or not. If they do, then the DBMS never allowed that transaction to
be executed.
Wait-Die scheme

In this scheme, if a transaction requests for a resource which is already held with a conflicting lock by
another transaction then the DBMS simply checks the timestamp of both transactions. It allows the older
transaction to wait until the resource is available for execution.

Let's assume there are two transactions Ti and Tj and let TS(T) is a timestamp of any transaction T. If
T2 holds a lock by some other transaction and T1 is requesting for resources held by T2 then the
following actions are performed by DBMS:

1. Check if TS(Ti) < TS(Tj) - If Ti is the older transaction and Tj has held some resource, then Ti is
allowed to wait until the data-item is available for execution. That means if the older transaction
is waiting for a resource which is locked by the younger transaction, then the older transaction is
allowed to wait for resource until it is available.
2. Check if TS(Ti) < TS(Tj) - If Ti is older transaction and has held some resource and if Tj is
waiting for it, then Tj is killed and restarted later with the random delay but with the same
timestamp.

Wound wait scheme

o In wound wait scheme, if the older transaction requests for a resource which is held by the
younger transaction, then older transaction forces younger one to kill the transaction and release
the resource. After the minute delay, the younger transaction is restarted but with the same
timestamp.
o If the older transaction has held a resource which is requested by the Younger transaction, then
the younger transaction is asked to wait until older releases it.

Recovery from Deadlock

1. Selection of a victim

 Selection of victim determine which transaction has to be rollback to break the deadlock.
 That transaction should be rollback which occurs at minimum cost.
2. Rollback
Rollback determine how far this transaction should be roll back.
 Total Rollback
 Partial Rollback
3. Starvation
Some transaction never complete its designated work- thus there is a starvation.
What is deadlock? Explain wait-for-graph. When it occurs?
OR
Define deadlock. Explain wait-for-graph. Explain different conditions that lead
to deadlock.
Deadlock-A deadlock is a condition when two or more transactions are executing and each transaction is
waiting for the other to finish but none of them are ever finished. So all the transactions will wait for infinite
time and not a single transaction is completed.

Wait-for-graph

Table 1
Held by Wait for

Transaction 1 Transaction 2

Wait for Hold by

Table 2
In the above figure there are two transactions 1 and 2 and two table’s as table1 and table 2.
Transaction 1 hold table 1 and wait for table 2. Transaction 2 hold table 2 and wait for table 1.
Now the table 1 is wanted by transaction 2 and that is hold by transaction 1 and same way table 2 is wanted
by transaction 1 and that is hold by transaction 2. Until any one can’t get this table they can’t precede further
so this is called wait for graph. Because both of these transaction have to wait for some resources.
When dead lock occurs
A deadlock occurs when two separate processes struggle for resources are held by one another.
Deadlocks can occur in any concurrent system where processes wait for each other and a cyclic chain can
arise with each process waiting for the next one in the chain.
Deadlock can occur in any system that satisfies the four conditions:
1. Mutual Exclusion Condition: only one process at a time can use a resource or each
resource assigned to 1 process or is available.
2. Hold and Wait Condition: processes already holding resources may request new
resources.
3. No Preemption Condition: only a process holding a resource can release it voluntarily
after that process has completed its task or previously granted resources cannot forcibly
taken away from any process.
4. Circular Wait Condition: two or more processes forms circular chain where each process
requests a resource that the next process in the chain holds.
Explain deadlock detection and recovery.
Resource-Allocation Graph
A set of vertices V and a set of edges E.
 V is partitioned into two types:
1. P = {P1, P2, …, Pn}, the set consisting of all the processes in the system.
 2. R = {R1, R2, …, Rm}, the set consisting of all resource types in the
system.

Request edge – directed edge Pi → Rj assignment edge – directed edge Rj → Pi

Process -
Resource
Process Pi requests resource Rj –
Process Pi is holding resource Rj
If graph contains no cycles then no deadlock. If graph contains cycles then deadlock.

R1 R3 R1 R3

P1 P2 P3 P1 P2 P3

R2 R4 R2 R4

No cycle (circular chain) Cycle (circular chain) created (P2, R3, P3, R4, P2) So
created So no deadlock deadlock

When a deadlock is detected, the system must recover from the deadlock.
The most common solution is to roll back one or more transactions to break the deadlock. Choosing which
transaction to abort is known as Victim Selection.
In the above wait-for graph transactions R3 and R4 are deadlocked.
In order to remove deadlock one of the transaction out of these two (R3, R4) transactions must be roll backed.
We should rollback those transactions that will incur the minimum cost.
When a deadlock is detected, the choice of which transaction to abort can be made using following criteria:
The transaction which have the fewest locks the transaction that has done the least work the transaction that
is farthest from completion
Explain deadlock prevention methods.
OR
Explain methods to prevent deadlock.
Deadlock prevention
A protocols ensure that the system will never enter into a deadlock state. Some prevention
strategies :
 Require that each transaction locks all its data items before it begins
execution (predeclaration).
 Impose partial ordering of all data items and require that a transaction
canlock data items only in the order specified by the partial.
 Following schemes use transaction timestamps for the sake of deadlock
prevention alone.
1. Wait-die scheme — non-preemptive
• If an older transaction is requesting a resource which is held by younger
transaction, then older transaction is allowed to wait for it till it is available.
• If an younger transaction is requesting a resource which is held by older
transaction, then younger transaction is killed.
2. Wound-wait scheme — preemptive
• If an older transaction is requesting a resource which is held by younger
transaction, then older transaction forces younger transaction to kill the
transaction and release the resource.
• If an younger transaction is requesting a resource which is held by older
transaction, then younger transaction is allowed to wait till older
transaction will releases it.
3. Timeout-Based Schemes :
• A transaction waits for a lock only for a specified amount of time. After
that, the wait times out and the transaction is rolled back. So deadlocks
never occur.
• Simple to implement; but difficult to determine good value of the timeout
interval.
Database Failure/ Failure classification in DBMS

Failure in terms of a database can be defined as its inability to execute the specified
transaction or loss of data from the database.

A DBMS is vulnerable to several kinds of failures and each of these failures needs to be
managed differently.

There are many reasons that can cause database failures such as network failure, system
crash, natural disasters, carelessness, sabotage(corrupting the data intentionally), software
errors, etc.

To find that where the problem has occurred, we generalize a failure into the following
categories:

1. Transaction failure
2. System crash
3. Disk failure/Data Transfer Failure
1. Transaction failure

The transaction failure occurs when it fails to execute or when it reaches a point from
where it can't go any further. If a few transaction or process is hurt, then this is called
as transaction failure.

Reasons for a transaction failure could be -

1. Logical errors: If a transaction cannot complete due to some code error or an

internal error condition, then the logical error occurs.
2. Syntax error: It occurs where the DBMS itself terminates an active transaction
because the database system is not able to execute it. For example, The system
aborts an active transaction, in case of deadlock or resource unavailability.

2. System Crash
o System failure can occur due to power failure or other hardware or software
failure. Example: Operating system error.

Fail-stop assumption: In the system crash, non-volatile storage is assumed not

to be corrupted.

3. Disk Failure/Data Transfer Failure

o It occurs where hard-disk drives or storage drives used to fail frequently. It was
a common problem in the early days of technology evolution.
o Disk failure occurs due to the formation of bad sectors, disk head crash, and
unreachability to the disk or any other failure, which destroy all or part of disk
storage.
Recovery from Deadlock:
When a detection algorithm determines that a deadlock exists, the system must recover from the deadlock. The
most common solution is to roll back one or more transactions to break the
deadlock. Three actions need to be taken:
1. Selection of a victim. Given a set of deadlocked transactions, we must determine which transaction (or
transactions) to roll back to break the deadlock. We should roll back those transactions that will incur the
minimum cost. Unfortunately, the term minimum cost is not a precise one. Many factors may determine the cost
of a rollback, including
a. How long the transaction has computed, and how much longer the transaction will compute before it
completes its designated task.
b. How many data items the transaction has used.
c. How many more data items the transaction needs for it to complete.
d. How many transactions will be involved in the rollback.
2. Rollback. Once we have decided that a particular transaction must be rolled back, we must determine how
far this transaction should be rolled back. The simplest solution is a total rollback: Abort the transaction and
then restart it. However, it is more effective to roll back the transaction only as far as necessary to break the
deadlock. Such partial rollback requires the system to maintain additional information about the state of all the
running transactions. Specially, the sequence of lock requests/grants and updates performed by the transaction
needs to be recorded. The deadlock detection mechanism should decide which locks the selected transaction
needs to release in order to break the deadlock. The selected transaction must be rolled back to the point where
it obtained the conflict of these locks, undoing all actions it took after that point. The recovery mechanism must
be capable of performing such partial rollbacks. Furthermore, the transactions must be capable of resuming
execution after a partial rollback. See the bibliographical notes for relevant references.
3. Starvation. In a system where the selection of victims is based primarily on cost factors, it may happen that
the same transaction is always picked as a victim. As a result, this transaction never completes its designated
task, thus there is starvation. We must ensure that transaction can be picked as a victim only a (small) number
of times. The most common solution is to include the number of rollbacks in the cost factor.
 Recovery and Atomicity:

When a system crashes, it may have several transactions being executed and various files opened for them to
modify the data items.
But according to ACID properties of DBMS, atomicity of transactions as a whole must be maintained, that is,
either all the operations are executed or none.
Database recovery means recovering the data when it get deleted, hacked ordamaged accidentally.
Atomicity is must whether is transaction is over or not it should reflect in the databasepermanently or it should
not effect the database at all.

When a DBMS recovers from a crash, it should maintain the following −

 It should check the states of all the transactions, which were being executed.

 A transaction may be in the middle of some operation; the DBMS must ensurethe atomicity of the transaction
in this case.
 It should check whether the transaction can be completed now or it needs to berolled back.
 No transactions would be allowed to leave the DBMS in an inconsistent state.

There are two types of techniques, which can help a DBMS in recovering as well as maintaining the
atomicity of a transaction −
Maintaining the logs of each transaction, and writing them onto some stable storagebefore actually modifying
the database.
Maintaining shadow paging, where the changes are done on a volatile memory, and later, the actual database
is updated.
Log-Based Recovery
  Schedules managed using timestamp based protocol are serializable just like the two phase protocols
 Since older transactions are given priority which means no transaction has to wait for longer period of time
that makes this protocol free from deadlock.

Explain Log based recovery method.

Log based recovery
The most widely used structure for recording database modification is the log.
The log is a sequence of log records, recording all the update activities in the database.
In short Transaction log is a journal or simply a data file, which contains history of all
transaction performed and maintained on stable storage.
Since the log contains a complete record of all database activity, the volume of data stored
in the log may become unreasonable large.
For log records to be useful for recovery from system and disk failures, the log must reside
on stable storage.
Log contains
1. Start oftransaction
2. Transaction-id
3. Record-id
4. Type of operation (insert, update, delete)
 5. Old value, new value
6. End of transaction that is committed or aborted.
All such files are maintained by DBMS itself. Normally these are sequential files.
Recovery has two factors Rollback (Undo) and Roll forward (Redo).
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.
 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 are used in log based recovery
1. Deferred database modification
2. Immediate database modification
Log based Recovery Techniques
Once a failure occurs, DBMS retrieves the database using the back-up of database and
transaction log. Various log based recovery techniques used by DBMS are as per below:
1. Deferred Database Modification
2. Immediate Database Modification
Both of the techniques use transaction logs. These techniques are explained in following
sub-sections.
Explain Deferred Database Modification log based recovery method.
Concept
Updates (changes) to the database are deferred (or postponed) until the transaction
commits.
During the execution of transaction, updates are recorded only in the transaction log and
in buffers. After the transaction commits, these updates are recorded in the database.
When failure occurs
If transaction has not committed, then it has not affected the database. And so, no need to
do any undoing operations. Just restart the transaction.
If transaction has committed, then, still, it may not have modified the database. And so,
redo the updates of the transaction.
Transaction Log
In this technique, transaction log is used in following ways:
Transaction T starts by writing <T start> to the log.
Any update is recorded as <T, X, V>, where V indicates new value for data item X. Here,
no need to preserve old value of the changed data item. Also, V is not written to the X in
database, but it is deferred.
Transaction T commits by writing <T commit> to the log. Once this is entered in log, actual
updates are recorded to the database.
If a transaction T aborts, the transaction log record is ignored, and no any updates are
recorded to the database.
Example
Consider the following two transactions, T0 and T1 given in figure, where T0 executes
before T1. Also consider that initial values for A, B and C are 500, 600 and 700
respectively.
Transaction – T0 Transaction – T1
Read (A) Read
A =A - (C)
100 C=C-
200
Write (A) Write (C)
Read (B)
B =B+
100
Write (B)
 The following figure shows the transaction log for above two transactions at three
different instances of time.
Time Instance (a) Time Instance (b) Time Instance (c)
<T0 start> < T0 start> < T0 start>
< T0, A, 400> < T0, A, 400> < T0, A, 400>
< T0, B, 700> < T0, B, 700> < T0, B, 700>
< T0 commit> < T0 commit>
<T1 start> < T1 start>
<T1, C, 500> < T1, C, 500>
< T1 commit>
If failure occurs in case of
1. No any REDO actions are required.
2. As Transaction T0 has already committed, it must be redone.
3. As Transactions T0 and T1 have already committed, they must be redone.
Explain Immediate Database Modification log based recovery method.
Concept
Updates (changes) to the database are applied immediately as they occur without waiting
to reach to the commit point.
Also, these updates are recorded in the transaction log.
It is possible here that updates of the uncommitted transaction are also written to the
database. And, other transactions can access these updated values.
When failure occurs
If transaction has not committed, then it may have modified the database. And so, undo the
updates of the transaction.
If transaction has committed, then still it may not have modified the database. And so, redo
the updates of the transaction.
Transaction Log
In this technique, transaction log is used in following ways:
Transaction T starts by writing <T start> to the log.
Any update is recorded as <T, X, Vold, Vnew > where Vold indicates the original value
of data item X and Vnew indicates new value for X. Here, as undo operation is required, it
requires preserving old value of the changed data item.
Transaction T commits by writing <T commit> to the log.
If a transaction T aborts, the transaction log record is consulted, and required undo
operations are performed.
Example
Again, consider the two transactions, T0 and T1, given in figure, where T0 executes
before T1.
Also consider that initial values for A, B and C are 500, 600 and 700 respectively.
 The following figure shows the transaction log for above two transactions at three different
instances of time. Note that, here, transaction log contains original values also along with
new updated values for data items.
If failure occurs in case of -
Undo the transaction T0 as it has not committed, and restore A and B to 500 and 600
respectively.
Undo the transaction T1, restore C to 700; and, Redo the Transaction T0 set A and B to
400 and 700 respectively.
Redo the Transaction T0 and Transaction T0; and, set A and B to 400 and 700
respectively, while set C to 500.
Time Instance (a) Time Instance (b) Time Instance (c)
<T0 start> < T0 start> < T0 start>
< T0, A, 500, 400> < T0, A, 500, 400> < T0, A, 500, 400>
< T0, B, 600, 700> < T0, B, 600, 700> < T0, B, 600, 700>
< T0 commit> < T0 commit>
<T1 start> < T1 start>
<T1, C, 700, 500> < T1, C, 700, 500>
< T1 commit>
 Recovery with Concurrent Transactions

Concurrency control means that multiple transactions can be executed at the same time and then the interleaved
logs occur. But there may be changes in transaction results so maintain the order of execution of those
transactions.
During recovery, it would be very difficult for the recovery system to backtrack all the logs and then start
recovering.
Recovery with concurrent transactions can be done in the following four ways.

1. Interaction with concurrency control

2. Transaction rollback
3. Checkpoints
4. Restart recovery

Interaction with concurrency control:

In this scheme, the recovery scheme depends greatly on the concurrency control scheme that is used. So, to
rollback a failed transaction, we must undo the updates performed by thetransaction.

Transaction rollback :
 In this scheme, we rollback a failed transaction by using the log.
 The system scans the log backward a failed transaction, for every log record found inthe log the system
restores the data item.

Checkpoints :
 A checkpoint is a process of saving a snapshot of the applications state so that it canrestart from that point in
case of failure.
 Checkpoint is a point of time at which a record is written onto the database form thebuffers.
 Checkpoint shortens the recovery process.
 When it reaches the checkpoint, then the transaction will be updated into the database, and till that point, the
entire log file will be removed from the file. Then the log file is updated with the new step of transaction till the
next checkpoint and so on.
 The checkpoint is used to declare the point before which the DBMS was in the consistent state, and all the
transactions were committed.

Restart recovery:
 When the system recovers from a crash, it constructs two lists.
 The undo-list consists of transactions to be undone, and the redo-list consists oftransaction to be redone.
 The system constructs the two lists as follows: Initially, they are both empty. Thesystem scans the log
backward, examining each record, until it finds the first
<checkpoint> record.

Check Points:
 Checkpoints are a process of saving a snapshot of the applications state so that it canrestart from that point in
case of failure.
 Checkpoint is a point of time at which a record is written onto the database form the buffers.
 Checkpoint shortens the recovery process.
 When it reaches the checkpoint, then the transaction will be updated into the database, and till that point, the
entire log file will be removed from the file. Then the log file is updated with the new step of transaction till the
next checkpoint and so on.
The checkpoint is used to declare the point before which the DBMS was in the consistent state, and all the
transactions were committed.
Explain system recovery procedure with Checkpoint record concept.

Problems with Deferred & Immediate Updates

Searching the entire log is time-consuming.
It is possible to redo transactions that have already been stored their updates to the
database.
Checkpoint
 A point of synchronization between database and transaction log file.
 Specifies that any operations executed before this point are done correctly and
storedsafely.
 At this point, all the buffers are force-fully writtento the secondary storage.
Checkpoints are scheduled at predetermined time intervals
 Used to limit -
1. The size of transaction log file
2. Amount of searching, and
3. Subsequent processing that is required to carry out on the transaction log file.
When failure occurs
 Find out the nearest checkpoint.
 If transaction has already committed before this checkpoint, ignore it.
 If transaction is active at this point or after this point and has committed before
failure,redo that transaction.
 If transaction is active at this point or after this point and has not committed, undo that
 transaction.
Example
Consider the transactions given in following figure. Here, Tc indicates checkpoint, while
Tf indicates failure time.
Here, at failure time -
1. Ignore the transaction T1 as it has already been committed before checkpoint.
2. Redo transaction T2 and T3 as they are active at/after checkpoint, but have
committed before failure.
3. Undo transaction T4 as it is active after checkpoint and has not committed.

Time Tc Tf

T1
T2

T3

T4

Checkpoint Time Failure

Explain Shadow Paging Technique.

Concept
Shadow paging is an alternative to transaction-log based recovery techniques.
Here, database is considered as made up of fixed size disk blocks, called pages. These
pages are mapped to physical storage using a table, called page table.
The page table is indexed by a page number of the database. The information about
physical pages, in which database pages are stored, is kept in this page table.
This technique is similar to paging technique used by Operating Systems to allocate
memory, particularly to manage virtual memory.
The following figure depicts the concept of shadow paging.
Execution of Transaction
During the execution of the transaction, two page tables are maintained.
1. Current Page Table: Used to access data items during transaction execution.
2. Shadow Page Table: Original page table, and will not get modified during
transaction execution.
Whenever any page is about to be written for the first time
1. A copy of this page is made onto an free page,
2. The current page table is made to point to the copy,
3. The update is made on this copy.
What is Shadow Paging?

Shadow Paging is recovery technique that is used to recover database. In this recovery
technique, database is considered as made up of fixed size of logical units of storage which
are referred as pages.

pages are mapped into physical blocks of storage, with help of the page table which allow
one entry for each logical page of database.

This method uses two page tables named current page table and shadow page table.

The entries which are present in current page table are used to point to most recent database
pages on disk.

Another table i.e., Shadow page table is used when the transaction starts which is copying
current page table.

After this, shadow page table gets saved on disk and current page table is going to be used
for transaction.

Entries present in current page table may be changed during execution but in shadow page
table it never get changed. After transaction, both tables become identical.

This technique is also known as Cut-of-Place updating.

Advantages
No overhead of maintaining transaction log. Recovery is quite faster, as there is no any redo or
undo operations required.
Disadvantages
Copying the entire page table very expensive. Data are scattered or fragmented. After each
transaction, free pages need to be collected by garbage collector. Difficult to extend this
technique to allow concurrent transaction