Transaction:

• A transaction is a set of database operations that performs a particular task.

• A transaction is a logical unit of work that contains one or more SQL
statements. A transaction is an atomic unit.
• The effects of all the SQL statements in a transaction can be either
all committed (applied to the database) or all rolled back (undone from the
database).
• A transaction is a unit of program execution that accesses and possibly updates
various data items. A transaction is an action or series of actions. It is performed
by a single user to perform operations for accessing the contents of the
database.
• Let’s take an example of a simple transaction. Suppose a bank employee
transfers $ 50 from A's account to B's account. This very simple and small
transaction involves several low-level tasks.
A’s Account
Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance - 50
A.balance = New_Balance
Close_Account(A)
B’s Account
Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 50
B.balance = New_Balance
Close_Account(B)

Or
Let Transaction T transfers $50 from Account A to Account B,
Read(A)
A:=A-50
Write(A)
Read(B)
B:= B+50
Write(B)
Operations of Transaction:
Following are the main operations of transaction:
Read(A) or Retrieve A : Read operation is used to read the value of A from the
database and stores it in a buffer in main memory.
Write(A) or Update A: Write operation is used to write the value back to the database
from the buffer.

1
Let's take an example to debit transaction from an account which consists of following
operations:
1. Read(A)
2. A:=A-50
3. Write(A)

Let's assume the value of A before starting of the transaction is 100 and the value of B is
0.
• The first operation reads A's value from database and stores it in a buffer.
• The second operation will decrease the value of A by 50. So buffer will contain
50.
• The third operation will write the buffer's value to the database. So A's final
value will be 50.
But it may be possible that because of the failure of hardware, software or power,
etc. that transaction may fail before finished all the operations in the set. For
example: If in the above transaction, the debit transaction fails after executing
operation 2 then A's value will remain 100 in the database which is not acceptable by
the bank.
To solve this problem, Oracle Database must allow:
 Commit work commits the current transaction; that is, it makes the updates
performed by the transaction become permanent in the database. Or It is used
to save the work done permanently. After the transaction is committed, a new
transaction is automatically started.
 Rollback work causes the current transaction to be rolled back; that is, it
undoes all the updates performed by the SQL statements in the transaction. Or It
is used to undo the work done. Thus, the database state is restored to what it was
before the first statement of the transaction was executed.
.

 A transaction begins with the first executable SQL statement. A transaction ends
when it is committed or rolled back, either explicitly with
a COMMIT or ROLLBACK statement or implicitly when a DDL statement is issued.
 A transaction ends when any of the following occurs:
 A user issues a COMMIT or ROLLBACK statement without
a SAVEPOINT clause.
 A user runs a DDL statement such as CREATE, DROP, RENAME, or ALTER.
 A user disconnects from Oracle Database. The current transaction is
committed.
 A user process terminates abnormally. The current transaction is rolled
back.
 Committing means that a user has explicitly or implicitly requested that the
changes in the transaction be made permanent. An explicit request occurs when
the user issues a COMMIT statement. An implicit request occurs after normal
termination of an application or completion of a data definition language (DDL)
operation. Oracle Database marks the transaction complete.
 Rolling back means undoing any changes to data that have been performed by
SQL statements within an uncommitted transaction. The transaction ends.

2
ACID Properties
A transaction is a very small unit of a program and it may contain several low-level
tasks. A transaction in a database system must
maintain Atomicity, Consistency, Isolation, and Durability − commonly known as ACID
properties − in order to ensure accuracy, completeness, and data integrity.
• Atomicity − This property states that a transaction must be treated as an atomic
unit, that is, either all of its operations are executed or none. There must be no
state in a database where a transaction is left partially completed. States should
be defined either before the execution of the transaction or after the
execution/abortion/failure of the transaction.
• Consistency − The database must remain in a consistent state after any
transaction. No transaction should have any adverse effect on the data residing
in the database. If the database was in a consistent state before the execution of
a transaction, it must remain consistent after the execution of the transaction as
well.
• Durability − The database should be durable enough to hold all its latest
updates even if the system fails or restarts. If a transaction updates a chunk of
data in a database and commits, then the database will hold the modified data. If
a transaction commits but the system fails before the data could be written on
to the disk, then that data will be updated once the system springs back into
action.
• Isolation − In a database system where more than one transaction are being
executed simultaneously and in parallel, the property of isolation states that all
the transactions will be carried out and executed as if it is the only transaction
in the system. No transaction will affect the existence of any other transaction.

What is concurrency?
 Concurrency in terms of database means allowing multiple users to access the data
within a database at the same time.
 Concurrent execution of transaction is essential for good DBMS performance.

(1) It improves throughput and resource utilization because it is important to keep

the CPU running by working several transactions concurrently.

(2)It reduces waiting time in a serial processing. A short transaction may have to
wait for a long transaction to complete, in the concurrent execution it reduces average
response time and the average time for a transaction to be completed.

 If the concurrent access is not managed by DBMS, so that simultaneous operations may
interfere with one another; problems can occur when various transactions are working
together interleaved their operations and resulting an inconsistent database.

Concurrency control
• Concurrency control is the process of managing simultaneous execution of transactions
(such as queries, updates, inserts, deletes and so on) in a multiprocessing database
3
 system without having them interfere with one another.
• This property of DBMS allows many transactions to access the same database at the
same time without interfering with each other.
• The primary goal of concurrency is to ensure the atomicity of the execution of
transactions in a multi-user database environment.

Problems of Concurrency Control :

When concurrent transactions are executed in an uncontrolled manner, severalproblems
can occur.
The concurrency control has the following three main problems:
1. Lost update Problem
2. Uncommitted Dependency Problem (Dirty read ).
3. Inconsistent Analysis Problem (Unrepeatable read or inconsistent
retrievals)

1. Lost update problem

o When two transactions that access the same database items contain their
operations in a way that makes the value of some database item incorrect, then
the lost update problem occurs.
o If two transactions T1 and T2 read a record and then update it, then the effect of
updating of the first record will be overwritten by the second update.

Example:

Here,

o At time t2, transaction-X reads A's value.

o At time t3, Transaction-Y reads A's value.
o At time t4, Transactions-X writes A's value on the basis of the value seen at time
t2.
o At time t5, Transactions-Y writes A's value on the basis of the value seen at time
t3.
o So at time T5, the update of Transaction-X is lost because Transaction Y
overwrites it without looking at its current value.
o Such type of problem is known as Lost Update Problem as update made by one
transaction is lost here.
4
2. Uncommitted Dependency Problem ( Dirty Read )

o The dirty read occurs in the case when one transaction updates an item of the
database, and then the transaction fails for some reason. The updated database
item is accessed by another transaction before it is changed back to the original
value.
o A transaction T1 updates a record which is read by T2. If T1 aborts then T2 now
has values which have never formed part of the stable database.

Example:

o At time t2, transaction-Y writes A's value.

o At time t3, Transaction-X reads A's value.
o At time t4, Transactions-Y rollbacks. So, it changes A's value back to that of prior
to t1.
o So, Transaction-X now contains a value which has never become part of the
stable database.
o Such type of problem is known as Dirty Read Problem, as one transaction reads a
dirty value which has not been committed.

3. Inconsistent Analysis Problem (Unrepeatable read or Inconsistent Retrievals

Problem)

o Inconsistent Retrievals Problem is also known as unrepeatable read. When a

transaction calculates some summary function over a set of data while the other
transactions are updating the data, then the Inconsistent Retrievals Problem
occurs.
o A transaction T1 reads a record and then does some other processing during
which the transaction T2 updates the record. Now when the transaction T1 reads
the record, then the new value will be inconsistent with the previous value.

Example:

Suppose two transactions operate on three accounts.

5
 ACC1 ACC2 ACC3
BALANCE=40 BALANCE=50 BALANCE=30

Transaction - X Time Transaction- Y

Read ACC1
t1 --
Sum=40
Read ACC2
t2 --
Sum=90
Read ACC3
-- t3 30
Update ACC3
-- t4
3020
Read ACC1
t5
40
Update ACC1
t6
4050
t7 commit

Read ACC3 t8
Sum=110 not 120

o Transaction-X is doing the sum of all balance while transaction-Y is transferring

an amount 10 from Account-3 to Account-1.
o Here, transaction-X produces the result of 110 which is incorrect. If we write this
produced result in the database, the database will become an inconsistent state
because the actual sum is 120.
o Here, transaction-X has seen an inconsistent state of the database.

Locking Methods of Concurrency Control :

In this type of protocol, any transaction cannot read or write data until it acquires an
appropriate lock on it. There are two types of lock:

1. Shared lock: (S – LOCK)

o It is also known as a Read-only lock. In a shared lock, the data item can only read
by the transaction. Whenever transaction wants to read the data it should
acquired shared lock on that data.
o More than one transaction can acquired shared lock at a time on same data but if
any other transaction holds X lock on that data then shared lock cannot be
acquired on that data.
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.
o S-lock is requested using lock-S instruction.
6
2. Exclusive lock: (X- LOCK)

o In the exclusive lock, the data item can be both reads as well as written by the
transaction.
o It is also known as write lock whenever transaction want to write (update, insert,
delete) on data on the database, it should acquired X lock on that data.

o This lock is exclusive, and in this lock, multiple transactions do not modify the
same data simultaneously.
o If any other transaction holds either shared or exclusive lock on that data
exclusive lock will not acquired by this transaction. It will goes into wait state.
o X-lock is requested using lock-X instruction.

Lock Compatibility Matrix –

S X --
S  X 
X X X 
--   --

 A transaction may be granted a lock on an item if the requested lock is compatible

with locks already held on the item by other
transactions.
 Any number of transactions can hold shared locks on an item, but if any
transaction holds an exclusive(X) on the item no other transaction may hold any
lock on the item.
 If a lock cannot be granted, the requesting transaction is made to wait till all
incompatible locks held by other transactions have been released. Then the lock is
granted.

7
Three Concurrency Problems Revisited:

1. Lost Update problem :-

Transaction - X Time Transaction -Y
--- t1 ---
Read (A)
Request S lock
t2 ---
(acquire lock -S)

Read (A)
Request S lock
--- t3
(acquire lock - S)

Update(A)
(Request X lock)
Wait… t4 ---
Wait….

Update(A)
(Request X lock)
--- t5 Wait…
Wait….

 Here transaction X and transaction Y are running concurrently.

 At time t2 trans. X retrieves A’s data then it will send the request for S -
lock to the DBMS, it’s request will be granted and it acquired lock - S on A’s
Data.
 At time t3 trans. Y also retrieves A’s data. it also sends the request and it’s
request will also granted by DBMS and it also acquires lock - S.
 At time t4 trans. X wants to update A’ data, then it will send the request of X
- lock . And It is not accepted because this request conflict with the S –lock
already held by Tran. Y So Tran. X goes into wait state.
 At time t5 ,trans. Y also request for X- lock and it will also goes into wait
state. Now both the transactions are unable to proceed.
 This wait state is continues for both transaction until either of them release
their locks. [Roll back].
 So there is no question of any update being lost. The lost update problem is
solved here but there is a new problem occurs called “deadlock”.

8
2. Uncommitted Dependency Problem:

Transaction - X Time Transaction - Y

--- t1 ---
Update A
Request X lock
--- t2
(acquire lock -X)

Read A
Request S lock
Wait… t3 ---
Wait…

Rollback
--- t4
(Release lock on A)
Resume: Read A
Request S lock
(acquire lock -S) t5 ---

 Here transaction X and transaction Y are running concurrently.

 At time t2 trans. Y updates A’s data then it will send the request for X - lock to
the DBMS, it’s request will be granted and it acquired lock - X on A’s Data.
 At time t3 trans. X also retrieves A’s data, then it will send the request of S -
lock which is not accepted. Because it is implicit request for an S on A and this
request conflict with lock- X already held by transaction Y. So Tran. X goes into
wait state.
 Tran X remains in that wait state until Tran Y reaches its termination (Rollback).
 At time t4 Tran Y’s lock is released then Tran. X is proceed. And it resume their
operation and sees committed value of A.
 So here Tran X is no longer dependent on an uncommitted dependency

9
 3. Inconsistent Analysis Problem (Unrepeatable read or
Inconsistent Retrievals Problem)

ACC1 ACC2 ACC3

BALANCE=40 BALANCE=50 BALANCE=30
Transaction - X Time Transaction- Y
Read ACC1
Request S lock
t1 --
(acquire lock –S on ACC1)

Read ACC2
Request S lock
t2 --
(acquire lock –S on ACC2)

Read ACC3
Request S lock
-- t3
(acquire lock –S on ACC3)

Update ACC3
Request X lock
-- t4
(acquire lock -X)

Read ACC1
Request S lock
t5
(acquire lock –S on ACC1)

Update ACC1
Request X lock
t6 Wait …
Wait…

Read ACC3
Request S lock on ACC3
Wait.. t7
Wait..

 Here transaction X and transaction Y are running concurrently.

 At time t1 trans. X retrieves ACC1’s data then it will send the request for S -
lock to the DBMS, it’s request will be granted and it acquired lock - S on A’s
Data.
 At time t2 trans. X retrieves ACC2’s data then it will send the request for S -
lock to the DBMS, it’s request will be granted and it acquired lock - S on A’s
Data.
10
  At time t3 trans. Y retrieves ACC3’s data then it will send the request for S -
lock to the DBMS, it’s request will be granted and it acquired lock - S on A’s
Data.
 At time t4 trans. Y updates ACC4’s data then it will send the request for X - lock
to the DBMS, it’s request will be granted and it acquired lock -X on A’s Data.
 At time t5 trans. Y retrieves ACC1’s data then it will send the request for S -
lock to the DBMS, it’s request will be granted and it acquired lock - S on A’s
Data.
 At time t6 trans. Y’s update on ACC1 is not accepted. Because it is an implicit
request for lock –X on ACC1 which conflicts with the S lock already held by tran
X . So tran Y goes into wait state.
 At time t7 tran X retrieves ACC3 data which is also not accepted because it is
implicit request for an S lock on ACC3 and such a request conflicts with the X lock
held by tran Y on ACC3 at time t4.So Tran X also goes into wait state. Here the
inconsistent Retrieval problem is solved.

Deadlock in DBMS
 In a database, a deadlock is an unwanted situation in which 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 it brings
the whole system to a Halt.
 Example – let us understand the concept of Deadlock with an example:
Suppose, Transaction T1 holds a lock on some rows in the Students table
and needs to update some rows in the Grades table. Simultaneously,
Transaction T2 holds locks on those very rows (Which T1 needs to update) in the
Grades table but needs to update the rows in the Student table held by
Transaction T1.

 Now, the main problem arises. Transaction T1 will wait for transaction T2 to
release (give up) lock, and similarly transaction T2 will wait for transaction T1
to release (give up) lock. As a consequence, All activity comes to a halt and
remains at a standstill forever unless the DBMS detects the deadlock and
aborts one of the transactions.


11
  Deadlock Detection –
When a transaction waits indefinitely to obtain a lock, The database management
system should detect whether the transaction is involved in a deadlock or not.
 Wait-for-graph is one of the methods for detecting the deadlock situation. This
method is suitable for smaller database. In this method a graph is drawn based
on the transaction and their lock on the resource. If the graph created has a
closed loop or a cycle, then there is a deadlock.
For the above mentioned scenario the Wait-For graph is drawn below

Deadlock Avoidance –
When a database is stuck in a deadlock, It is always better to avoid the deadlock rather
than restarting or aborting the database.

 Deadlock avoidance method is suitable for smaller database whereas deadlock

prevention method is suitable for larger database.
 The method of avoiding deadlock is using application consistent logic. In the
above given example, Transactions that access Students and Grades should
always access the tables in the same order. In this way, in the scenario described
above, Transaction T1 simply waits for transaction T2 to release the lock
on Grades before it begins. When transaction T2 releases the lock, Transaction
T1 can proceed freely.

Deadlock prevention –

For large database, deadlock prevention method is suitable. A deadlock can be

prevented if the resources are allocated in such a way that deadlock never occur. The
DBMS analyzes the operations whether they can create deadlock situation or not, If they
do, that transaction is never allowed to be executed.

Deadlock prevention mechanism proposes two schemes:

 Wait-Die Scheme –

 In this scheme, If a transaction request for a resource that is locked by other

transaction, then the DBMS simply checks the timestamp of both transactions
12
 and allows the older transaction to wait until the resource is available for
execution.

 Suppose, there are two transactions T1 and T2 and Let timestamp of any
transaction T be TS (T).
 Now, If there is a lock on T2 by some other transaction and T1 is requesting for
resources held by T2, then

 DBMS performs following actions:

Checks if TS (T1) < TS (T2) – if T1 is the older transaction and T2 has held some
resource, then it allows T1 to wait until resource is available for execution.
 That means if a younger transaction has locked some resource and older
transaction is waiting for it, then older transaction is allowed wait for it till it is
available.
 If T1 is older transaction and has held some resource with it and if T2 is waiting
for it, then T2 is killed and restarted latter with random delay but with the same
timestamp. i
This scheme allows the older transaction to wait but kills the younger one.

 Wound Wait Scheme –

 In this scheme, if an older transaction requests for a resource held by younger

transaction, then older transaction forces younger transaction to kill the
transaction and release the resource. The younger transaction is restarted with
minute delay but with same timestamp.
 If the younger transaction is requesting a resource which is held by older one,
then younger transaction is asked to wait till older releases it.

13
Database Recovery

 Database recovery is the process of restoring the database to a correct

(consistent) state in the event of a failure.
 In other words, it is the process of restoring the database to the most recent
consistent state that existed shortly before the time of system failure.
 The failure may be the result of a system crash due to hardware or software
errors, a media failure such as head crash, or a software error in the application
such as a logical error in the program that is accessing the database.
 Recovery restores a database form a given state, usually inconsistent, to a
previously consistent state.

Failure: A failure is a situation that makes the database in inconsistent state. Failure
may be local or global.

Types of Failures :
Two types: Local Failure and Global Failure
1. Local Failure: A Local Failure affects only the transaction in which failure has
actually occurred Like:
Transaction failure :
 Logical errors: transaction cannot complete due to some internal error
condition
 System errors: the database system must terminate an active
transaction due to an error condition (e.g., deadlock)
2. Global Failure: A global failure affects all the transactions in progress at the
time of the failure and hence a significant system wide implications. The global
failure can be divided into two categories.
 System failure which affect all transactions currently in progress but do
not damage physically the database. It is known as soft crash. A power
failure causes the system to crash.
 Media failure ( Disk failure) Which do cause the damage the database or
to some portion of it and affect at least the transactions currently using
the portion. A Media failure is called hard crash. A head crash or similar
disk failure destroys all or part of disk storage
Recovery Concepts:
[1] System Recovery :-

 The key point of system failure is that the contents of main memory are lost so
the state of transaction which was in progress at the time of failure is therefore
no longer known. Such transaction can never be successfully completed. So must
be undone – rollback when the system restarts.
 It might be necessary to redo the certain transactions at restart time that did
successfully complete prior to the failure but did not manage their updates from
buffer to physical database.
 So How does the system know at restart time which transactions to undo and
whch to redo?

14
  The answer is: - the system automatically takes a checkpoint which shows the
transaction entries written in log.
 Taking a checkpoint involves
 Physically writing contents of the database buffers out to physical database.
 Physically writing special checkpoint record to physical log.
 The checkpoint record gives a list of all transactions that were in progress at the
time checkpoint was taken.
 Following is the example with five transactions categories recover with system
recovery.

According to the example:-

(1) A system failure has occurred at time tf.
(2) The most recent checkpoint prior to time tf was taken at time tc.
(3) Transaction T1 completed successfully prior to time tc.
(4) Transaction T2 started prior to time tc and completed successfully after time tc
and before time tf.
(5) Transaction T3 also started prior to time tc but did not complete by time tf.
(6) Transaction T4 started after time tc and completed successfully before time tf.
(7) Finally Transaction T5 also started after time tc but did not complete by time tf .
 It should be clear that, when system is restarted the transactions T3 and T5 must be
undone and the transactions T2 and T4 must be redone. And the transaction T1 does
not enter in the restart process because their update work force to the database at
time tc as part of the checkpoint process.
 At restart time the system first goes through the following procedure in order to
identify all transactions T2- T5.
1. Start with two lists of transactions: the UNDO list and the REDO list. Set
the UNDO list equal to the list of all transactions given in the most recent
checkpoint record. Set the REDO list empty.
2. Search forward through the log starting from the checkpoint record.

15
 3. If a BEGIN TRANSACTION log entry is found for transaction T, add T to the
UNDO list.
4. If a COMMIT log entry is found for transaction T, move T from the UNDO
list to the REDO list.
5. When the end of the log is reached the UNDO and REDO lists identify
respectively, transaction of types T3 and T5 and transaction of types T2
and T4
Now the system works backward through the log. Undoing in the transaction in the
UNDO list then it works forward again Redoing in the transaction in the REDO list.

 Restoring the database to a consistent state by undoing work is sometimes

called backward recovery.
 Similarly, restoring the database to a consistent state by redoing work is
sometimes called forward recovery.
 Finally when all such recovery activity is complete then the system is ready to
accept new work.

[2] Media Recovery :-

 A media failure is a failure such as disk had crash or disk controller failure in
which some portion of the database has been physically destroyed or damaged.
 Recovery from such a failure involves reloading the database from a backup copy
or dump and then using the log both active and achieve portion. In general to
redo all the Transactions that completed since the backup copy was taken. There
is no need to undo Transactions that were still in progress at the time of failure
because all updates of such transactions have been actually lost.

Two Phase Commit :-

 Two phase commit is important whenever a given transaction can interact with several
independent “resource managers” each managing its own set of recoverable resources
and maintaining its own recovery log.
 for ex :- If a transaction running on an IBM mainframe that updates two database(oracle
and db2) then if the transaction completes successfully then all of its updates to both
Oracle data and db2 data must be committed but if it fails then all of its updates must
be rollback. In other words it is not possible for oracle to commit the update and db2
rolled back or vice versa. Otherwise the transaction would no longer be atomic.
 If the system crashes both two situations (one is committing and other is roll back) then
it is very critical and database will be inconsistent. Therefore the transaction issue a
single system wide COMMIT (or ROLLBACK). That global COMMIT or ROLLBACK is
handled by system component called coordinator, whose task is to guarantee that both
resource managers (oracle and db2 ) commit or rollback the updates they are

16
 Responsible for in unison and it also provide guarantee even if system fails in
the middle of the process.
 It is the Two Phase Commit protocol that enables the coordinator to provide
such a guarantee. The working of protocol is: Assume a transaction has
completed its database processing successfully so that the system wide
instruction it issue is COMMIT, not ROLLBACK. On receiving that COMMIT
request the coordinator goes through the following two-phase process:
1. It instructs all the resource manages to get ready to “go either way “ on
the transaction. That means each participant in the process must force
all log entries for local resources used by the transaction out to its
physical log. Assuming the force writ is successful; the resource
manager replies “OK” to the coordinator otherwise it replies”NOT OK”.
2. When the coordinator has received replies from all participants, it
forces an entry to its own physical log, recording the decision
regarding the transaction. If all replies were “OK” that decision is
“COMMIT”, if any reply was “NOT OK” the decision is ROLLBACK. In
either way the coordinator informs each participants must commit or
rollback the transaction locally as instructed by coordinator.

17