1

B.Sc (Computer Science)

Database Management Systems
UNIT - IV

Transaction:-
Ø A transaction is any action that reads from or writes to a database.
Ø Suppose a customer is purchasing a product using credit card then after
purchasing the product customer may be charged from account. So the sales
transactions consists of the following parts:
a) We must write a new customer invoice
b) We must reduce the quantity in the product’s inventory
c) We must update the account transactions
d) We must update the customer balance.
Ø A transaction may consists of a simple SELECT Statement to generate a list of
table contents, it may consists of series of related UPDATE statements to change
the attribute’s values in various tables, it may consist of a series of INSERT
Statements to add rows to one or more table or it may consists of a combination of
SELECT, UPDATE and INSERT Statements.
Ø A transaction is a logical unit of work that must be entirely completed or entirely
aborted.
Ø All of the SQL statements in the transaction must be completed successfully.
Ø If any of the SQL statements fail, the entire transaction is rolled back to the
original database state that existed before the transaction started.
Ø A successful transaction changes the database from one consistent state to
another.
Ø In a consistent database state all data integrity constraints are satisfied.
Ø To ensure consistency of the database, every transaction must begin with the
database in a known consistent state.
Ø If the database is not in a consistent state, the transaction will yield an inconsistent
database that violates its integrity and business rules.

Transaction Properties:-

Ø Each individual transaction must contains the properties like

a) Atomicity
b) Consistency
c) Isolation
d) Durability
e) Serializability

a) Atomicity:-

Ø Atomicity requires that all operations of a transaction be completed. If not the

transaction T1 has four SQL requests, all four requests must be successfully
completed otherwise the entire transaction is aborted.
Ø A transaction is treated as a single, indivisible logic unit of work.

b) Consistency:-
 2

Ø Consistency indicates the permanence of the databases consistent state. A

transaction takes a database from one consistent state to another consistent state.
Ø When a transaction is completed the database must be in a consistent state, if any of
the transaction parts violates an integrity constraint, the entire transaction in
aborted.

c) Isolation:-

Ø Isolation means that the data used during the execution of transaction can not be
used by a second transaction until the first one is completed.
Ø This property is particularly useful in multi- user database environments because
several users can access and update the database at the same time.

d) Durability:-

Ø Durability ensures that once transaction changes are done, they con not be undone
even a system failure occurs.

e) Serializability:-

Ø When execution multiple transactions the DBMS must schedule the concurrent
execution of the transaction’s operations. This property is riffed as serializability.
Ø This property is important in multi- user and distributed databases.

Transaction Management with SQL:-

Ø Transaction support is provided by two SQL statements: COMMIT and

ROLLBACK.
Ø A COMMIT statement is used to make permanent all changes recorded within the
database. The COMMIT statement automatically ends the SQL transaction.
Ø A ROLLBACK statement is used to abort the changes that are made to the
database and the database is rolled back to its previous consistent state.
Ø For example
Update emp set sal=sal+500 where deptno=20;
Update student set cs=80 where rollno=2364;
Commit;
Ø In the above example it is not necessary if the update statement is the last action
in the application and the application terminates normally but good programming
practice is that include the COMMIT statement at the end of transaction.

The transaction log:-

Ø A DBMS uses a transaction log to keep track of all transactions that update the
database.
Ø When a program is abnormally terminated or a system failure occurred such as
network discrepancy or disk crash then ROLLBACK statement is triggered to
recover the information stored in this log is used by DBMS.
Ø The transaction log stores:
a) A record for the beginning of the transaction.
b) For each transaction component (SQL statement) like
 3

i. The type of operation being performed (update,delete,insert)

ii. The names of the objects affected by the transaction (The name of the
table)
iii. The before and after values for the fields being updated.

c) The ending (COMMIT) of the transaction.

Ø Although using a transaction log increase the processing overhead of a DBMS but
it restores a corrupted database.
Ø If a system failure occurs, the DBMS will examine the transaction log for all
uncommitted or incomplete transactions and restore (ROLLBACK) the database
to its previous state on the basis of that information.
Ø When recovery process is completed, the DBMS will write in the log all
committed transactions that were not physically written to the database before the
failure occurred.
Ø Committed transactions are not rolled back.
Ø Therefore the transaction log is a critical pack of the database and it is usually
implemented as one or more files that are managed separately from the actual
database files.

Concurre ncy Control:-

Ø The coordination of the simultaneous execution of transactions in a multi user
database system is known as concurrency control.
Ø The objective of concurrency control is to ensure the serializability of transaction
in a multi- user database environment.
Ø Concurrency control is important because the simultaneous execution of
transactions over a shared database can several data integrity and consistency
problems.
Ø The three main problems are
a) Lost updates
b) Uncommitted data
c) Inconsistent data

a) Lost updates:-
Ø The Lost Updates problem occurs when two concurrent transactions T1 and T2
are updating the same data element and one of the updates is lost.

b) Uncommitted data:-
Ø Uncommitted data occurs when two transactions T1 and T2 are executed
concurrently and the first transaction (T1) is rolled back after the second
transaction (T2) has already accessed the uncommitted data. Thus it is violating
Isolation property of transactions.

c) Inconsistent retrievals:-

Ø Inconsistent retrievals occur when a transaction access data before and after
another transactions finish working with such data.
 4

The Scheduler:-

Ø The database consistency can be ensured only before and after the execution of
transactions.
Ø The Scheduler is a special DBMS process that establishes the order in shish the
operations with in concurrent transactions are executed.
Ø The scheduler interleaves the execution of database operations to ensure
serializability and isolation of transactions.
Ø To determine the appropriate order the scheduler bases its actions on concurrency
control algorithms such as locking methods or time stamping methods.
Ø The scheduler’s main job is to create a serializable schedule of a transaction’s
operations.
Ø The DBMS determines what transactions are serializable and proceeds to
interleave the execution of the transaction’s operations.
Ø So the scheduler makes sure that the computer’s CPU and Storage System are
used efficiently.
Ø When transactions are not serializable then they are executed on first come, first
served basis by the DBMS.
The problem with this approach is processing time of CPU is wasted.
Ø The scheduler also facilitates data isolation to insure that two transactions do not
update the same data element at the same time.

Concurre ncy Control with Locking Methods:-

Ø A transaction acquires a lock prior to data access, the lock is released (Unlocked)
when the transaction is completed, so that another transaction can lock the data
item.
Ø Transaction T2 does not have access to a data item that is currently being used by
transaction T1.
Ø Most multi- user DBMS automatically initiate and enforce locking procedures.
Ø All lock information is managed by a lock manager, which is responsible for
assigning and policing the locks used by the transactions.

Lock Granularity :- (or) Locking Level

Ø Lock granularity indicates the level of lock use. Locking can take place at the
following level.
a) Database level
b) Table level
c) Page level
d) Row level
e) Field (attribute level)

a) Database level:-

Ø In database level lock the entire database is locked. So if transaction T1 is

accessing that database, then transaction T2 can not access it.
 5

Ø This level of locking is good for batch processes but it is unsuitable for multi user
DBMS. Because thousands of transactions had to wait for the previous transaction
to be completed before the next one could reserve the entire database. So the data
access would be slow.

Table level:-
Ø In table level lock the entire table is locked that means if transaction T1 is
accessing a table then transaction T2 can not access the same table.
Ø If a transaction requires access to several tables, each table may be locked.
Ø Table level locks are less restrictive than database level locks.
Ø Table level locks are not suitable for multi- user DBMS.
Ø The draw back of table level lock is suppose transaction T1 and T2 can not access
the same table even when they try to use different rows; T2 must wait until T1
unlocks the table.

Page level:-
Ø In a page level lock, the DBMS will lock on entire disk page.
Ø A disk page or page is also referred as a disk block, which is described as a
section of a disk.
Ø A page has a fixed size such as 4k, 8k or 16k.
Ø A table can span several pages, and a page can contain several rows of one or
more tables.
Ø Page level locks are currently frequently used multi- user DBMS locking method.
Ø Page level lock is shown in the following fig.

Payroll Database

T1 is accessing Page1

Page2 T2 is accessing

Ø In the above fig. T1 and T2 access the same table while locking different disk
pages.
Ø If T2 requires the use of a row located on a page that is locked by T1, T2 must
wait until the page is unlocked.

Row level:-
Ø A row level lock is mush less restrictive than the other locks. The DBMS allows
concurrent transactions to access different rows of the same table even the rows
are located on the same pages.
Ø The row level locking approach improves the availability of data.
Ø But row level locking management requires high overhead because a lock exist
for each row in a table of the database. So it involves a conflicting transaction.

Field level:-
 6

Ø The field level lock allows concurrent transactions to access the same row as long
as they require the use of different fields (attributes) with in that row.
Ø Although field level locking clearly yields the most flexible multi user data
access, but it is rarely implemented in a DBMS because it requires an extreme
High Level computer overhead.

Lock Types:-
Ø The DBMS use different lock types like
a) Binary Locks
b) Shared/Exclusive Locks.

a) Binary Locks :-
Ø A binary lock has two states:
a) Locked
b) Unlocked
Ø In an object is locked by a transaction no other transaction can use that object.
The object may be a database, table, page or row.
Ø If an object is unlocked, any transaction can lock the object for its use.
Ø Every database operation requires that the affected object be locked.
Ø A transaction must unlock the object after its termination. Therefore every
transaction requires a lock and unlocks operation for each data item that is
accessed.
Ø Such operations are automatically managed and scheduled by the DBMS.
Ø Every DBMS has a default locking mechanism. If the end user wants to override
the default, the LOCK TABLE and other SQL commands are available.
Ø Using binary locks the lost update problem is eliminated in concurrency control
because the lock released until the WRITE statement is completed.
Ø But binary locks are how considered too restrictive to yield optional concurrency
conditions
For example the DBMS will not allow two transactions to read the same database
object even though neither transaction updates the database.
Shared/Exclusive Locks:-
Ø A shared lock exists when concurrent transactions are granted read access on the
basic of a common lock. A shared lock produces no conflict as long as all the
concurrent transactions are read only.
Ø An exclusive lock exists when access is reserved specifically for the transaction
that locked the object. The exclusive lock must be used when conflicts exists lock
one transaction is READ and other is WRITE.
Ø So a shared lock is issued when a transaction wants to read data from the data
base and an exclusive lock is issued when a transaction wants to update (WRITE)
a data item.
Ø Using Shared/Exclusive locking concept a lock can have 3 states
a) Unlocked
b) Shared (read)
c) Exclusive (write)
 7

Example for shared lock:

Ø If transaction T1 has shared lock on data item X and transaction T2 wants to read
data item X. So T2 may also obtain a shared lock on data item X.\
Example for Shared/Exclusive lock:
Ø If transaction T1 has Shared/Exclusive lock on data item X and transaction T2
wants an exclusive lock to update data item X. But an exclusive lock can not be
granted to transaction T2 and it must wait till T1 is saved. So “The exclusive lock
is granted if and only if no other are held on the data item”.
Ø Shared/Exclusive locks are more efficient but these increase the lock manager’s
overhead because of the following reasons.
a) The type of the lock must be held before a lock is granted.
b) First lock type has to check, then lock is issued and then release the lock.
Ø Shared/Exclusive locks can lead to two major problems:
a) The resulting transaction schedule might not be serializable.
b) The schedule might create deadlock.

Two Phase Locking to ensure Serializability:-

Ø Two phase locking defines how transactions acquire locks.
Ø Two phase locking guarantees Serializability but it does not prevent dead locks.
Ø The two phases are
a) A growing phase in which a transaction acquires all required locks with out
unlocking any data. Once all locks have been acquired the transaction is in its
locked point.
b) A shrinking phase, in which a transaction releases all locks and can not obtain
any new lock.
Ø In two phase locking protocol the transaction acquires all the locks until it reaches
its locked point. When the locked point is reached, the data are modified to
conform to the transaction requirements. Finally the transaction is completed, and
then it releases all the locks which are acquired.
Ø The two phase locking increase the transaction processing cost but the drawback
is it might create deadlocks.

Dead Locks:-
Ø A dead lock occurs when two transactions wait indefinitely for each other to
unlock data
For example a dead lock occurs when two transactions, T1 and T2 exist in the
following mode.
T1: access data items X and Y.
T2: access data items Y and X.
Ø T1 and T2 transactions are executing simultaneously so, T1 has locked data item
X and T2 has locked data item Y. Now transaction T1 is waiting to lock data item
Y but it is already locked by T2. Simultaneous T2 is waiting to lock X but it is
already locked by T1. So both transactions are waiting to access other items. Thus
condition is referred as “Dead Lock”.
 8

Ø So in real world DBMS, many transactions can be executed simultaneously, there

by increasing the probability of generating dead Locks.
Ø The 3 basic techniques to control dead locks are

a) Dead Lock Prevention:-

Ø A transaction requesting a new lock is aborted when there is the possibility that a
dead lock can occur. If the transaction is aborted, all changes made by this
transaction are rolled back, and all locks obtained by the transaction are released.
Ø This method is used when there is existing high probability of dead lock.

b) Dead Lock Detection:-

Ø The DBMS tests the database for dead locks. If a dead lock is found, one of the
transactions is aborted and the other transaction continues.
Ø This method is used when there is un probability of dead locks.

c) Dead Lock Avoidance:-

Ø The transaction must obtain all of the locks if needs before it can be executed.
This technique avoids the rollback of conflicting transactions.

Concurre ncy Control with Time Stamping Methods :-

Ø Time stamping methods are used to manage concurrency transaction execution.
Ø In time stamping approach, for each transaction unique time stamp assigned.
Ø Time stamps must have two properties.
a) Uniqueness: It specifies unique time stamp value exist, that means no equal
time stamp values can exist.
b) Monotonicity: It specifies that time stamp values always increase.
Ø The disadvantage of time stamping approach is that each values stored in the
database requires two additional time stamp fields. They are
a) One field is for the last time the field was read
b) Another field is for the last update.
Ø So time stamping increases memory needs and the database’s processing
overhead.

Wait/die and Wound/wait Schemes:-

Ø The wait/die and wound/wait scheme are used in time stamping method.
Example:
Ø Assume that we have two conflicting transactions:
T1 and T2, each with a unique time stamp.
Ø Suppose T1 has time stamp of 11548789 and T2 has a time stamp of 19562545.
So T1 is the order transaction and T2 is newer (younger) transaction.
Using the wait/die scheme:-
a) If the transaction requesting the lock is the order of the two transactions, it
will wait until the other transactions is completed, and the locks are relapsed.
 9

b) If the transaction requesting the lock is the younger of the two transactions, it
will die (rollback) and is rescheduled using the same time stamp.
Ø That means in wait/die scheme, the order transaction waits for the younger to
complete and release its locks.
Using the wound/wait scheme:-
a) If the transaction requesting the lock is the older of the two transactions, it
will preempt (wound) the younger transaction (by rolling it back). The
younger transaction is rescheduled using the same time stamp.
b) If the transaction requesting the lock is the younger of the two transactions, it
will wait until the other transaction is completed and the locks are released.
Ø That means in the wound/wait scheme, the older transaction rolls back the
younger transaction and reschedules it.

Concurre ncy Control with Optimistic methods:-

Ø The optimistic approach is based on the assumption that the majority of the
database operations do not conflict.
The optimistic approach requires neither locking nor time stamping techniques.
Ø Using an optimistic approach, each transaction moves through three phases. They
are
a) Read Phase
b) Validation Phase
c) Write Phase.
Ø During the read phase, the transaction reads the database, executes the needed
computations, and makes the updates to a private copy of the data base values. All
the update operations of the transaction are recorded in a temporary update file,
which is not accessed by the remaining transactions.
Ø During the validation phase the transaction is validated to ensure that the changes
made will not affect the integrity and consistency of the database. If the validation
test is positive, the transaction goes to the write phase. If the validation test is
negative, the transaction is restarted and the changes are discarded.

Database Recovery Management:-

Ø Database recovery restores a database from an inconsistent to a previous
consistent state.
Ø If, for some reason any transaction operation can not be completed, the
transaction must be rolled back.
That means transaction recovery reverses all of the changes that the transaction
made to the database before the transaction was aborted.
Ø Recovery techniques also apply to the database and to the system after some type
of critical error has occurred.
Ø Examples of critical events are:
a) Hardware/Software failures:-
Ø Failure of this type could be a hard disk failure, a bad capacitor on a mother board
or a failing memory.
b) Human Caused incidents:-
 10

Ø This type of events can be categorized as unintentional and intentional.

Ø An unintentional failure is caused by carelessness by end users. Such errors
include deleting the wrong rows from a table, pressing wrong key on the keyboard
or shutting down the main database server by accident.
Ø Intentional events are securing threats caused by hackers trying to gain
unauthorized access to data resources and virus attacks.

c) Natural disasters:-
Ø This category includes fires, earthquakes, floods etc.
Ø A critical error can render the database in an inconsistent state.

Transaction Recovery:-
Ø Database transaction recovery uses data in the transaction log to recover a
database from an inconsistent state to a consistent state.
Ø Database recovery process involves bringing the database to a consistent state
after a failure.
Ø Transaction recovery procedures generally make use of differed-write and write-
through techniques.
Ø When the recovery procedure uses a differed-write technique, the transaction
operations do not immediately update the physical database. Only the transaction
log is updated. The database is physically updated only after the transaction
reaches its commit point, using information from the transaction log. If the
transaction aborts before it reaches its commit point, no changes need to be made
to the database because the database was never updated.
Ø When the recovery procedure uses a write-through technique, the database is
immediately updated by transaction operations during the transactions execution,
even before the transaction reaches its commit point. If the transaction aborts before it
reaches its commit point, a ROLLBACK or undo operation needs to be done to
restore the database to a consistent state. In this case the ROLLBACK operation will
use transaction log before values.