Unit-V

Transaction Concept: Transaction State

Def: A transaction is an execution of a user program and is seen by the DBMS as a

series or list of actions. The actions that can be executed by a transaction includes the
reading and writing of database.
Transaction Operations: Access to the database is accomplished in a transaction by the
following two operations.
1) Read(X): Performs the reading operation of data item X from the database.
Write(X): Perform the writing operation of data item X to the database

Transaction Concept: The concept of transaction is the foundation for concurrent

execution of transactions in a DBMS and recovery from system failure in a DBMS. In
this case, high level language supports DBMS with respect to concurrency control and
recovery of data. It is convenient to execute the user program or transactions (database
object) with the help of read and write operations.

1. To read a database object, the read operation first brought the

database object into main memory from disk.
2. To write a database object, the write operation first modifies the
copy of object in main memory and then writes on disk.
Generally, database objects are the units in which programs reads or writes
information. The units could be pages, records and so on but these executes depends on
the DBMS.

PROPERTIES OF TRANSACTION (ACID): There are four important properties of

transaction that a DBMS must ensure to maintain data in concurrent access of database
and recovery from system failure in DBMS. They are acronym

of ACID.
1. Atomicity. 2. Consistency. 3. Isolation 4. Durability.
1. Atomicity: Atomicity ensures that the transaction either is executed completely or not
at all. It means, users should not have to worry about the effect of incomplete
transactions when a system crash occurs.
Transactions can be incomplete for three kinds of reasons. They are
i) First, a transaction can be aborted or terminated unsuccessfully by the DBMS
because some changes arise during execution. If a transaction is aborted by
the DBMS for some internal reason, it is automatically restarted and executed
as a new transaction.
 ii) Second, the system may crash because the power supply is interrupted, while
one or more transactions are in progress.
iii) Third, a transaction may encounter an unexpected situation such as unable to
access disk due to virus, etc.
2. Consistency: Consistency means, data in the database must always in a consistent
state i.e. available. Execution of transaction in isolation preserves the consistency of the
database.
This property is the authority of the application programmer. It means, if the
programmer wants some data to be consistent then he gives the consistency permission to
that data.
For example, consider a transaction that involves transfer of amount. If amount is debited
from account A and credited to account B, then the two accounts A & B must be
consistent. If one is not available then transaction is aborted. So, this is the responsibility
of application program to ensure consistency. Because, before start the transaction and
after the transaction, the account A & B must be consistent.
3. Isolation: Isolation property ensures that each transaction is unaware (not known) of
other transactions executing concurrently in the system.
For example, suppose multiple transactions are executing concurrently in the system such
as T1 and T2. During the process, the transaction of T1 is unaware of T2 i.e. whether T1 has
started or finished or not but T2 is unaware of T1. It means, T2 doesn’t know the details of
T1 during the transaction.
4.Durability: This property ensures that data remains in a consistent (available) state even after
the failure. This is ensured by loading the modified data into disk. It means, the durability
property guarantees that, once a transaction completes successfully, all the updates that are
carried out on the database even if there is a system failure after the transaction completes
execution
TRANSACTION STATE: A transaction is an execution of a user program and is seen
by the DBMS as a series (list) of actions. These can be established by a simple
transaction model named a s transaction states.
1Active State: This is the initial state of a transaction. The transaction stays in this
state while it is execution.
2Partially committed state: This transaction state occurs after the final (last)
statement of the transaction has been executed.
3.Failed State: This transaction state occurs after the discovery that normal execution
can no longer proceed.
4.Aborted State: This transaction state occurs after the transaction has been rolled
back and the database has been restored to its state prior to the start of the transaction.
5.Committed State: This transaction state occurs after the successful completion of
the transaction. The transaction states diagram corresponding to a transaction is shown in
fig.
 A transaction starts in the active state. When it finishes its final (last) statement, it enters
the partially committed state. At this point, the transaction has completed its execution in
main memory and it is possibility to abort due to hardware failure. In this case, the
transaction which is temporarily resided in main memory will be lost. So the transaction
is restarted.

A transaction may also enters the failed state from the active state or from the
partially committed state due to the hardware failure or logical errors, the transaction can
be restarted. At this state, the system has two operations. Such as
i) Restart the Transaction: It can restart the transaction, but only if the transaction was
aborted as a result of some hardware failure or software error. A restarted transaction is
considered to be a new transaction.
Kill the Transaction: It can kill the transaction because of some internal logical error that
can be corrected only by rewriting the application program, or because the input was bad

CONCURRENT EXECUTION: In transaction processing system, multiple transactions can

be executed concurrently. Concurrent execution of transaction in database is similar to the
multiprogramming approach performed in operating system. However, such execution results
in inconsistency of data. To ensure data consistency during the concurrent execution of
several transactions, an extra effort is required. This problem can be solved by employing
different mechanisms are referred as concurrency control schemes. They are

1. Increase the efficiency/ throughput of system. 2. Decrease the response time and average
time.
1. Increase the efficiency/ throughput of system: A transaction may contain either I/O
activity or CPU activity. Both of these activities can be performed parallel. This
parallelism enables the system to execute multiple transactions simultaneously. Such
mechanism increases the efficiency when more number of transactions is executed at a
time.
2. Decreases the Response Time and Average Time: Transactions can either be short
or long. If both these transactions are executed concurrently, then short transaction need
not wait for the long transaction to complete its execution.

SERIALIZABILITY: Serializability is a widely accepted standard that ensures the

consistency of schedule. A schedule is consistent if and only if it is serializable. A

T1 T2
T1 T2 read(x)
read(x) write(x)
write(x)
schedule is said to be serializable if the interleaved transactions produces the result, which
is equivalent to the result produced by executing individual transactions
fig1 serial schedule fig2 interleaved schedule

separately.

The above two schedules produce the same result, these schedules are said to be
serializable. The transaction may be interleaved in any order a nd DBMS doesn’t provide
any guarantee about the order in which they are executed. The two different types of
serializability are
1. Conflict Serializability 2) View Serializability

I. Conflict Serializability: Two schedules are said to be conflict equivalent if all the
conflicting operations in both the schedule get executed in the same order. If a schedule is a
conflict equivalent to its serial schedule then it is called Conflict Serializable Schedule.The
following schedules represents disagree of serializability.
Example for Conflict Serializability –
Let us consider the following transaction schedule and test it for Conflict
Serializability
T1 T2 T3

R(X)

R(X)

W(Y)

W(X)

R(Y)

W(Y)

Now, we will list all the conflicting operations. Further, we will determine
whether the schedule is conflict serializable using Precedence Graph.
Two operations are said to be conflicting if the belong to different
transaction, operate on same data and at least one of them is a write
operation.
1. R3(X) and W2(X) [ T3 -> T2 ]
2. W1(Y) and R3(Y) [ T1 -> T3 ]
3. W1(Y) and W2(Y) [ T1 -> T2 ]
4. R3(Y) and W2(Y) [ T3 -> T2 ]
Constructing the precedence graph, we see there are no cycles in the
graph. Therefore, the schedule is Conflict Serializable.

The serializable schedule is,

T1 -> T3 -> T2
II.
1) Write-Read (WR) Conflict: Reading Uncommitted Data (WR Conflicts) (or) Dirty
Read:
The first source of anomaly is that a transaction T2 will start the execution if T1 transaction
execution is committing (or) not (or) aborted. T1 T2
Consider two transactions T1 and T2. The T1 read(x)
adding amount to the account of x and T2 subtract write(x)
the amount of x. It means, read(x)
 First, T1 transaction is completed in RAM but write(x)
not committed to write on disk. Abort/commit
 Second, the control is switched to start the T2 transaction Abort/commit
and it is aborted/committed
execution immediately after its process is over.
 Thirdly, Now T1 transaction may be committed (or) aborted.

Thus, this causes dirty read because, T2 execution is started before commit/abort of T1
execution

1) Read-Write(RW) Conflict: Unrepeatable Reads

Conflict): The second source of anomaly is that a T1 T2
transaction T2 is committed before commit of T1 read(x)
write(x)
transaction. In this case, the read
read(x)
operation can be read same data but finally appears write(x)
only one data. It means, commit
 First, T1 transaction is completed but not committed. abort
Second, T2 schedule transaction over and it is committed.
 Third, T1 schedule is aborted. It means, it start
its process from beginning.

Thus, first T2 transaction is written on disk and after that T1 schedule transaction is aborted.
It means, T1 restart its transaction but read current data not previous data. This causes un-
repeatable read conflict and dirty write

1) Write-Write(WW) Conflict: Overwriting Uncommitted Data (or) Blind Writes:

The source of anomalies is that a transaction T1 could overwrite the value of an
object which is already modified by a transaction T2 while T1 is still in progress.
This is shown in fig
T1 T2
read(x)
write(x)
read(x)
write(x)
commit
commit

I.
II. VIEW SERIALIZABILITY:
View Serializability
o A schedule will view serializable if it is view equivalent to a serial schedule.
o I;;
o

o f a schedule is conflict serializable, then it will be view serializable.

o The view serializable which does not conflict serializable contains blind writes.

View Equivalent

Two schedules S1 and S2 are said to be view equivalent if they satisfy the following
conditions:

1. Initial Read

An
initial read of both schedules must be the same. Suppose two schedule S1 and S2. In schedule
S1, if a transaction T1 is reading the data item A, then in S2, transaction T1 should also read
A.

Above two schedules are view equivalent because Initial read operation in S1 is done by T1
and in S2 it is also done by T1.

2. Updated Read

In schedule S1, if Ti is reading A which is updated by Tj then in S2 also, Ti should read A

which is updated by Tj.

Above two schedules are not

view equal because, in S1, T3 is reading A updated by T2 and in S2, T3 is reading A updated
by T1.

3. Final Write

A final write must be the same between both the schedules. In schedule S1, if a transaction
T1 updates A at last then in S2, final writes operations should also be done by T2.
 Above two schedules is view equal because Final write operation in S1 is done by T3 and in
S2, the final write operation is also done by T3.

Example:

Schedule S

With 3 transactions, the total number of possible schedule

1. = 3! = 6
2. S1 = <T1 T2 T3>
3. S2 = <T1 T3 T2>
4. S3 = <T2 T3 T1>
5. S4 = <T2 T1 T3>
6. S5 = <T3 T1 T2>
7. S6 = <T3 T2 T1>

Taking first schedule S1:

Schedule S1

Above two schedules are not view equal because, in S1, T3 is reading A updated by T2 and
in S2, T3 is reading A updated by T1.

3. Final Write

A final write must be the same between both the schedules. In schedule S1, if a transaction
T1 updates A at last then in S2, final writes operations should also be done by T1.

Above two schedules is view equal because Final write operation in S1 is done by T3 and in
S2, the final write operation is also done by T3.

Example:
 Schedule S

With 3 transactions, the total number of possible schedule

1. = 3! = 6
2. S1 = <T1 T2 T3>
3. S2 = <T1 T3 T2>
4. S3 = <T2 T3 T1>
5. S4 = <T2 T1 T3>
6. S5 = <T3 T1 T2>
7. S6 = <T3 T2 T1>

Taking first schedule S1:

Step 1: final updation on data items

In both schedules S and S1, there is no read except the initial read that's why we don't need to
check that condition.

Step 2: Initial Read

 The initial read operation in S is done by T1 and in S1, it is also done by T1.

Step 3: Final Write

The final write operation in S is done by T3 and in S1, it is also done by T3. So, S and S1 are
view Equivalent.

The first schedule S1 satisfies all three conditions, so we don't need to check another
schedule.

Hence, view equivalent serial schedule is:

1. T1 → T2 → T3

Schedule S1

Consider the following schedules that are view equivalent.

Schedule S1 Schedule S2
T1 T2 T1 T2
read(x) read(x)
x:=x-10 x:=x-10
write(x) write(x)
read(x) read(y)
x:=x*20 y:=y+10
write(x) write(y)
read(y) read(x)
y:=y+10 x:=x*20
write(y) write(x)
read(y) read(y)
y:=y/20 y:=y/20
write(y) write(y)

Thus, every conflict serializable schedule is view serializable but every view serializable
schedule is not conflict serializable.

Testing for Serializability

Precedence Graph or Serialization Graph is used commonly to test Serializability of a

schedule

The Algorithm can be written as:

1. Create a node T in the graph for each participating transaction in the schedule.
2. For the conflicting operation read_item(X) and write_item(X) – If a Transaction
Tj executes a read_item (X) after T i executes a write_item (X), draw an edge from T i to
Tj in the graph.
3. For the conflicting operation write_item(X) and read_item(X) – If a Transaction
Tj executes a write_item (X) after T i executes a read_item (X), draw an edge from T i to
Tj in the graph.
4. For the conflicting operation write_item(X) and write_item(X) – If a Transaction
Tj executes a write_item (X) after T i executes a write_item (X), draw an edge from T i to
Tj in the graph.
5. The Schedule S is serializable if there is no cycle in the precedence graph.

S : r1(x) r1(y) w2(x) w1(x) r2(y)

Creating Precedence graph:

1. Make two nodes corresponding to Transaction T 1 and T2.

2. For the conflicting pair r1(x) w2(x), where r1(x) happens before w2(x), draw an edge

from T1 to T2.
3. For the conflicting pair w2(x) w1(x), where w2(x) happens before w1(x), draw an edge

from T2 to T1.
Since the graph is cyclic, we can conclude that it is not serializable to any schedule serial
schedule.

S1: r1(x) r3(y) w1(x) w2(y) r3(x) w2(x)

The graph for this schedule is :

Since the graph is acyclic, the schedule is serializable

Here are the steps to construct a precedence graph:

1. Draw a node for each transaction in the schedule.

2. For each pair of conflicting operations (i.e., operations on the same data item by
different transactions), draw an edge from the transaction that performed the first
operation to the transaction that performed the second operation. The edge represents a
dependency between the two transactions.
3. If there are multiple conflicting operations between two transactions, draw multiple
edges between the corresponding nodes.
4. If there are no conflicting operations between two transactions, do not draw an edge
between them.
5. Once all the edges have been added to the graph, check if the graph contains any cycles.
If the graph contains cycles, then the schedule is not serializable. Otherwise, the
schedule is serializable.

Lock-Based Protocols
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:

o It is also known as a Read-only lock. In a shared lock, the data item

can only read by the 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 the transaction.
o This lock is exclusive, and in this lock, multiple transactions do not
modify the same data simultaneously.

Lock Based Protocols

1. Simplistic lock protocol

It is the simplest way of locking the data while transaction. Simplistic lock-
based protocols allow all the transactions to get the lock on the data
before insert or delete or update on it. It will unlock the data item after
completing the transaction.

Pre-claiming Lock Protocol

o Pre-claiming Lock Protocols evaluate the transaction to list all the data
items on which they need locks.
o Before initiating an execution of the transaction, it requests DBMS for all
the lock on all those data items.
 o If all the locks are granted then this protocol allows the transaction to
begin. When the transaction is completed then it releases all the lock.
o If all the locks are not granted then this protocol allows the transaction to
rolls back and waits until all the locks are granted.

3. 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 for the lock it requires.
o In the second part, the transaction acquires all the locks. The third phase
is started as soon as the transaction releases its first lock.
o In the third phase, the transaction cannot demand any new locks. It only
releases the acquired locks.
There are two phases of 2PL:

Growing phase: In the growing phase, a new lock on the data item may
be acquired by the transaction, but none can be released.

Shrinking phase: In the shrinking phase, existing lock held by the

transaction may be released, but no new locks can be acquired.

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.
It does not have cascading abort as 2PL does.

Lock conversion
Changing the mode of a lock that is already held is called lock conversion.
Lock conversion occurs when a process accesses a data object on which it already
holds a lock, and the access mode requires a more restrictive lock than the one already
held.
A process can hold only one lock on a data object at any given time, although it can
request a lock on the same data object many times indirectly through a query.
Some lock modes apply only to tables, others only to rows, blocks, or data partitions. For
rows or blocks, conversion usually occurs if an X lock is needed and an S or U lock is
held.

Recoverability is a property of database systems that ensures that, in the event of a failure
or error, the system can recover the database to a consistent state. Recoverability guarantees
that all committed transactions are durable and that their effects are permanently stored in
the database, while the effects of uncommitted transactions are undone to maintain data
consistency.
The recoverability property is enforced through the use of transaction logs, which record all
changes made to the database during transaction processing. When a failure occurs, the
system uses the log to recover the database to a consistent state, which involves either
undoing the effects of uncommitted transactions or redoing the effects of committed
transactions.

There are several levels of recoverability that can be supported by a database system:
No-undo logging: This level of recoverability only guarantees that committed transactions
are durable, but does not provide the ability to undo the effects of uncommitted
transactions.
Undo logging: This level of recoverability provides the ability to undo the effects of
uncommitted transactions but may result in the loss of updates made by committed
transactions that occur after the failed transaction.
Redo logging: This level of recoverability provides the ability to redo the effects of
committed transactions, ensuring that all committed updates are durable and can be
recovered in the event of failure.
Undo-redo logging: This level of recoverability provides both undo and redo capabilities,
ensuring that the system can recover to a consistent state regardless of whether a transaction
has been committed or not.

Implementation of Isolation

Among the four properties (Atomicity, Consistency, Isolation, and Durability) Isolation
determines how transaction integrity is visible to other users and systems. It means that a
transaction should take place in a system in such a way that it is the only transaction that is
accessing the resources in a database system.
Isolation levels define the degree to which a transaction must be isolated from the data
modifications made by any other transaction in the database system. A transaction isolation
level is defined by the following phenomena:
 Dirty Read – A Dirty read is a situation when a transaction reads data that has not yet
been committed. For example, Let’s say transaction 1 updates a row and leaves it
uncommitted, meanwhile, Transaction 2 reads the updated row. If transaction 1 rolls
back the change, transaction 2 will have read data that is considered never to have
existed.
 Non Repeatable read – Non Repeatable read occurs when a transaction reads the same
row twice and gets a different value each time. For example, suppose transaction T1
reads data. Due to concurrency, another transaction T2 updates the same data and
commit, Now if transaction T1 rereads the same data, it will retrieve a different value.
 Phantom Read – Phantom Read occurs when two same queries are executed, but the
rows retrieved by the two, are different. For example, suppose transaction T1 retrieves a
set of rows that satisfy some search criteria. Now, Transaction T2 generates some new
rows that match the search criteria for transaction T1. If transaction T1 re-executes the
statement that reads the rows, it gets a different set of rows this time.
Based on these phenomena, The SQL standard defines four isolation levels:
1. Read Uncommitted – Read Uncommitted is the lowest isolation level. In this level, one
transaction may read not yet committed changes made by other transactions, thereby
allowing dirty reads. At this level, transactions are not isolated from each other.
2. Read Committed – This isolation level guarantees that any data read is committed at the
moment it is read. Thus it does not allow dirty read. The transaction holds a read or write
lock on the current row, and thus prevents other transactions from reading, updating, or
deleting it.
3. Repeatable Read – This is the most restrictive isolation level. The transaction holds read
locks on all rows it references and writes locks on referenced rows for update and delete
actions. Since other transactions cannot read, update or delete these rows, consequently it
avoids non-repeatable read.
4. Serializable – This is the highest isolation level. A serializable execution is guaranteed to
be serializable. Serializable execution is defined to be an execution of operations in which
concurrently executing transactions appears to be serially executing.
The Table given below clearly depicts the relationship between isolation levels, read
phenomena, and locks:
 Failure classification:
There are various types of failure that may occur in a system.
1) Transaction failure
There are two types of error that may cause transaction to fail.
Logical error: Logical error occurs because of some internal condition, such as
bad input data not found, overflow or resource limit exceeded. When logic error
occurs, transaction cannot continue with its normal execution.
System error: Example of system error is deadlock. When system error occurs,
the system enters in an undesirable state, and as a result, transaction cannot continue
with its normal execution.
2) System crash:
There is a hard wave malfunction, or a bug in the database software or in the operating
system, that causes the loss of the content of volatile storage and brings transaction
processing to a halt. The content of nonvolatile storage remains intact and is not
corrupted.
is not corrupted.
3)Disk Failure:
A Disc block loses its content as a result of either head crash or failure during data
transfer operations.Copies of the data on other disks or archival backups on tertiary
media ,such as tapes are used to recover from the failure.

Storage
A database system provides an ultimate view of the stored data.

Types of Data Storage

For storing the data, there are different types of storage options available. These storage types
differ from one another as per the speed and accessibility. There are the following types of
storage devices used for storing the data:

o Primary Storage
o Secondary Storage
o Tertiary Storage
Primary Storage

It is the primary area that offers quick access to the stored data. We also know the primary
storage as volatile storage. It is because this type of memory does not permanently store the
data. As soon as the system leads to a power cut or a crash, the data also get lost. Main
memory and cache are the types of primary storage.

o Main Memory: It is the one that is responsible for operating the data that is available
by the storage medium. The main memory handles each instruction of a computer
machine. This type of memory can store gigabytes of data on a system but is small
enough to carry the entire database. At last, the main memory loses the whole content
if the system shuts down because of power failure or other reasons.

1. Cache: It is one of the costly storage media. On the other hand, it is the fastest one. A
cache is a tiny storage media which is maintained by the computer hardware usually.
While designing the algorithms and query processors for the data structures, the
designers keep concern on the cache effects.

Secondary Storage

Secondary storage is also called as Online storage. It is the storage area that allows the user to
save and store data permanently. This type of memory does not lose the data due to any
power failure or system crash. That's why we also call it non-volatile storage.

There are some commonly described secondary storage media which are available in almost
every type of computer system:
 o Flash Memory: A flash memory stores data in USB (Universal Serial Bus) keys
which are further plugged into the USB slots of a computer system. These USB keys
help transfer data to a computer system, but it varies in size limits. Unlike the main
memory, it is possible to get back the stored data which may be lost due to a power
cut or other reasons. This type of memory storage is most commonly used in the
server systems for caching the frequently used data. This leads the systems towards
high performance and is capable of storing large amounts of databases than the main
memory.
o Magnetic Disk Storage: This type of storage media is also known as online storage
media. A magnetic disk is used for storing the data for a long time. It is capable of
storing an entire database. It is the responsibility of the computer system to make
availability of the data from a disk to the main memory for further accessing. Also, if
the system performs any operation over the data, the modified data should be written
back to the disk. The tremendous capability of a magnetic disk is that it does not
affect the data due to a system crash or failure, but a disk failure can easily ruin as
well as destroy the stored data.

Tertiary Storage

It is the storage type that is external from the computer system. It has the slowest speed. But
it is capable of storing a large amount of data. It is also known as Offline storage. Tertiary
storage is generally used for data backup. There are following tertiary storage devices
available:

o Optical Storage: An optical storage can store megabytes or gigabytes of data. A

Compact Disk (CD) can store 700 megabytes of data with a playtime of around 80
minutes. On the other hand, a Digital Video Disk or a DVD can store 4.7 or 8.5
gigabytes of data on each side of the disk.
o Tape Storage: It is the cheapest storage medium than disks. Generally, tapes are used
for archiving or backing up the data. It provides slow access to data as it accesses data
sequentially from the start. Thus, tape storage is also known as sequential-access
storage. Disk storage is known as direct-access storage as we can directly access the
data from any location on disk.

Storage Hierarchy

Besides the above, various other storage devices reside in the computer system. These storage
media are organized on the basis of data accessing speed, cost per unit of data to buy the
medium, and by medium's reliability. Thus, we can create a hierarchy of storage media on the
basis of its cost and speed.
Thus, on arranging the above-described storage media in a hierarchy according to its speed
and cost, we conclude the below-described image:

In the image, the higher levels are expensive but fast. On moving down, the cost per bit is
decreasing, and the access time is increasing. Also, the storage media from the main memory
to up represents the volatile nature, and below the main memory, all are non-volatile devices.

Recovery and Atomicity

The recovery procedures in DBMS ensure the database's atomicity and durability. If a system
crashes in the middle of a transaction and all of its data is lost, it is not regarded as durable. If
just a portion of the data is updated during the transaction, it is not considered atomic. Data
recovery procedures in DBMS make sure that the data is always recoverable to protect the
durability property and that its state is retained to protect the atomic property. The procedures
listed below are used to recover data from a DBMS,

o Recovery based on logs.

o Recovery through Deferred Update
o Immediate Recovery via Immediate Update
The atomicity attribute of DBMS safeguards the data state. If a data modification is
performed, the operation must be completed entirely, or the data's state must be maintained as
if the manipulation never occurred. This characteristic may be impacted by DBMS failure
brought on by transactions, but DBMS recovery methods will protect it.

Log-Based Recovery
o The structure [start transaction, T] represents the start of transaction T execution.
o [write the item, T, X, old value, new value] indicates that the transaction T changes
the value of the variable X from the old value to the new value.
o [read item, T, X] indicates that the transaction T reads the value of X.
o [commit, T] signifies that the modifications to the data have been committed to the
database and cannot be updated further by the transaction. There will be no errors
after the database has been committed.
o [abort, T] indicates that the transaction, T, has been cancelled.

We may utilize these logs to see how the state of the data changes during a transaction and
recover it to the prior or new state.

An undo operation can be used to inspect the [write item, T, X, old value, new value]
operation and restore the data state to old data. The only way to restore the previous state of
data to the new state that was lost due to a system failure is to do the [commit, T] action.

Deferred and an Immediate Update?

Database recovery methods used in DBMS to preserve the transaction log files include
deferred updates and rapid updates.

With a deferred update, the database's state of the data is not altered right away once a
transaction is completed; instead, the changes are recorded in the log file, and the database's
state is updated as soon as the commit is complete.

The database is directly updated at every transaction in the immediate update, and a log file
detailing the old and new values is also preserved.

Deferred Update Immediate Update

Changes to data are not instantly applied As soon as the transaction occurs, a modification is
during a transaction. made in the database.
 The log file contains the changes that The log file contains the changes as well as the new and
will be made. old values.

This approach employs buffering and Shadow paging is used in this technique.
caching.

When a system fails, it takes longer to During the transaction, a huge number of I/O activities
restore the data. are conducted to manage the logs.

Recovery using Checkpoints

The Checkpoint is used to declare a point before which the DBMS was in a consistent state,
and all transactions were committed. During transaction execution, such checkpoints are
traced. After execution, transaction log files will be created. Upon reaching the
savepoint/checkpoint, the log file is destroyed by saving its update to the database. Then a
new log is created with upcoming execution operations of the transaction and it will be
updated until the next checkpoint and the process continues.
Why do We Need Checkpoints?
Whenever transaction logs are created in a real-time environment, it eats up lots of storage
space. Also keeping track of every update and its maintenance may increase the physical
space of the system. Eventually, the transaction log file may not be handled as the size
keeps growing. This can be addressed with checkpoints. The methodology utilized for
removing all previous transaction logs and storing them in permanent storage is called a
Checkpoint.

Transaction 1 (T1) Transaction 2 (T2) Transaction 3 (T3) Transaction 4 (T4)

START

START
 Transaction 1 (T1) Transaction 2 (T2) Transaction 3 (T3) Transaction 4 (T4)

COMMIT

START

COMMIT

START

FAILURE

 The recovery system reads the logs backward from the end to the last checkpoint i.e.
from T4 to T1.
 It will keep track of two lists – Undo and Redo.
 Whenever there is a log with instructions <Tn, start>and <Tn, commit> or only <Tn,
commit> then it will put that transaction in Redo List. T2 and T3 contain <Tn, Start>
and <Tn, Commit> whereas T1 will have only <Tn, Commit>. Here, T1, T2, and T3 are
in the redo list.
 Whenever a log record with no instruction of commit or abort is found, that transaction
is put to Undo List <Here, T4 has <Tn, Start> but no <Tn, commit> as it is an ongoing
transaction. T4 will be put on the undo list.
All the transactions in the redo list are deleted with their previous logs and then redone
before saving their logs. All the transactions in the undo list are undone and their logs are
deleted.

Atomicity
UNIT-5

Recovery and Atomicity – Log – Based Recovery – Recovery with Concurrent Transactions
– Check Points - Buffer Management – Failure with loss of nonvolatile storage-Advance
Recovery systems- ARIES Algorithm, Remote Backup systems. File organization – various
kinds of indexes - B+ Trees- Query Processing – Relational Query Optimization.

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 or
damaged accidentally.
 Atomicity is must whether is transaction is over or not it should reflect in the database
permanently 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 ensure
the atomicity of the transaction in this case.
 It should check whether the transaction can be completed now or it needs to be
rolled back.
 No transactions would be allowed to leave the DBMS in an inconsistent state.

A set of ideas used to ensure the integrity of database transactions is known as the ACID
model, which stands for Atomicity, Consistency, Isolation, and Durability in database
management systems.

Atomicity is achieved mostly by complex processes such as journaling or logging or through

operating-system calls.

In a database management system, an atomic transaction is defined as an indivisible and

irreducible series of database actions in which either everything or nothing happens.

A guarantee of atomicity prevents incomplete database alterations, which might cause more
problems than simply rejecting the entire series

Atomicity Examples:

Example1: Atomicity in Online Ticket Booking Systems:

Using an online ticket booking system as an example, a booking may consist of two separate
acts that combine to form a transaction: the first is the payment for the ticket, and the second
is to reserve the seat for the person who just paid. According to business logic, these two
distinct and separate actions must occur concurrently. If one develops without the other,
problems may arise. The system might reserve the same seat for two separate consumers, for
instance.

Example 2: Transactions that occur in a bank (Credit or Debit of Money).

If Marino has a $50 account named A and wants to pay $20 to Amanda, who has an account
named B. A balance of $200 already exists in account B. When you deposit $20 into account
B, the total is $220.

Two procedures have now been arranged. The first is that the $20 Marino desires to send will
be debited from his account A and credited to account B, i.e., Amanda's account. The initial
debit transaction succeeds, but the subsequent crediting process fails.

As a result, the value of Marino's account A drops to $30 while Amanda's account's worth
stays the same at $200. This is not an atomic transaction as a result
Recovery Algorithm
Undo/Redo is a database transaction log for handling transaction crash recovery. This
algorithm stores all the values and changes made during transactions in a separate memory in
case of failure or crash. It utilizes the stored value to restore the loss due to failure.
This algorithm is a combination of two approaches
UNDO: It stands for undone and restores the data value items that are updated by any
transaction to their previous value.
REDO: It stands for re-done and it set the value of all the data updated by the transaction to
the new value.
Read(X)
Read(Y)
Update X=X+Y
Write(X)
Commit
Update Y=Y-100
Write(Y)
Commit

Now, if, during the transaction execution, the statement “Update X+Y” suffers from failure,
then the UNDO operation will perform, and it restores the value of “X” and then starts the
transaction again.
Suppose the statement “commit” fails during the transaction execution. In that case, the
REDO operation will be performed, which again tries to execute the statement commit and
reset the new value of X.
The UNDO/REDO recovery algorithm is a very flexible algorithm but the only disadvantage
it faces is that it requires more storage to store both old as well as newly updated values.

ARIES Recovery Algorithm

ARIES

Algorithms for Recovery and Isolation Exploiting Semantics, or ARIES is a recovery

algorithm designed to work with a no-force, steal database approach; it is used by IBM
Db2, Microsoft SQL Server and many other database systems.

ARIES starts by finding log records for operations that were not written to disk on crash and

then replays all of them. This even includes transactions that need to rolled back. It brings the

database to the same state as it was before crash. This process is called “repeating history”.

ARIES is a three phase algorithm:

1. Analysis phase: This phase reads the last checkpoint record in the log to figure out active
transactions and dirty pages at point of crash/restart. A page is considered dirty if it was
 modified in memory but was not written to disk. This information is used by next two
phases.

2. REDO phase: In this phase operations in log are reapplied to bring the state of the
database to current.

3. UNDO phase: This phase proceeds from the end of log reverting back operations for
uncommitted transactions. This has impact of rolling them back.

B+tree

A B+ Tree is a more advanced self-balancing tree. In this, all the values are present at
the leaf level. B+ Tree in the data structure is a B Tree enhancement that enables faster
insertion, deletion, and search operations.

A balanced binary search tree is the B+ Tree. It uses a multilevel indexing system. Leaf
nodes in the B plus tree represent actual data references. The B plus tree keeps all of the
leaf nodes at the same height. A link list is used to connect the leaf nodes in the B+ Tree.
As a result, a B+ Tree can allow both random and sequential access.
The structure of the internal nodes of a B+ tree of order ‘a’ is as follows:
1. Each internal node is of the form: <P 1, K1, P2, K2, ….., Pc-1, Kc-1, Pc> where c <= a and
each Pi is a tree pointer (i.e points to another node of the tree) and, each Ki is a key-
value (see diagram-I for reference).
2. Every internal node has : K 1 < K2 < …. < Kc-1
3. For each search field values ‘X’ in the sub-tree pointed at by P i, the following condition
holds : Ki-1 < X <= Ki, for 1 < i < c and, K i-1 < X, for i = c (See diagram I for reference)
4. Each internal node has at most ‘a’ tree pointers.
5. The root node has, at least two tree pointers, while the other internal nodes have at
least \ceil(a/2) tree pointers each.
6. If an internal node has ‘c’ pointers, c <= a, then it has ‘c – 1’ key values.
 Diagram-I The structure of the leaf nodes of a B+ tree of order ‘b’ is as follows:

B+ Tree Structure

 Every leaf node in the B+ Tree is at the same distance from the root node. The B+
Tree has an order of n, with n being the same for all B plus trees.
 It has a leaf node and an internal node.

Comparison between a B-tree and a B+ Tree

B-tree

B+ tree

The data pointers are present only at the leaf nodes on a B+ tree whereas the data pointers are
present in the internal, leaf or root nodes on a B-tree.

The leaves are not connected with each other on a B-tree whereas they are connected on a B+
tree.

Operations on a B+ tree are faster than on a B-tree.

Note:
 Except for root, each node can have a max of m children and a min of m/2 children.

 A max of m – 1 keys and a min of m/2 – 1 keys can be stored in each node.

Searching Records in B+ Tree

Suppose that we need to find 55 in the B+ Tree structure below. We’ll start by fetching for
the intermediary node, which will lead to the leaf node, which may have a record of 55.

So we’ll identify a branch between 50 to 75 nodes in the intermediary node. Then we’ll be
redirected to the 3rd leaf node at the conclusion. In this case, the DBMS will use a sequential
search to locate 55.

Insertion in B+ Tree

Step 1: Insert the new node as a leaf node

Step 2: If the leaf doesn't have required space, split the node and copy the middle node to the
next index node.

Step 3: If the index node doesn't have required space, split the node and copy the middle
element to the next index page.

Example :

Insert the value 195 into the B+ tree of order 5 shown in the following figure.

195 will be inserted in the right sub-tree of 120 after 190. Insert it at the desired position.
 The node contains greater than the maximum number of elements i.e. 4, therefore split it and
place the median node up to the parent.

Now, the index node contains 6 children and 5 keys which violates the B+ tree properties,
therefore we need to split it, shown as follows.

Deletion from a B+ Tree

Deleting an element on a B+ tree consists of three main events: searching the node where the
key to be deleted exists, deleting the key and balancing the tree if required.Underflow is a
situation when there is less number of keys in a node than the minimum number of keys it
should hold

1. A node can have a maximum of m children. (i.e. 3)

2. A node can contain a maximum of m - 1 keys. (i.e. 2)

3. A node should have a minimum of ⌈m/2⌉ children. (i.e. 2)
4. A node (except root node) should contain a minimum of ⌈m/2⌉ - 1 keys. (i.e. 1)
 While deleting a key, we have to take care of the keys present in the internal nodes (i.e.
indexes) as well because the values are redundant in a B+ tree. Search the key to be deleted
then follow the following steps.

Case I

The key to be deleted is present only at the leaf node not in the indexes (or internal nodes).
There are two cases for it:

1. There is more than the minimum number of keys in the node. Simply delete the key.

Deleting 40 from
B-tree

2. There is an exact minimum number of keys in the node. Delete the key and borrow a key
from the immediate sibling. Add the median key of the sibling node to the parent.
 Deleting 5 from
B-tree

Case II

The key to be deleted is present in the internal nodes as well. Then we have to remove them
from the internal nodes as well. There are the following cases for this situation.

1. If there is more than the minimum number of keys in the node, simply delete the key from the
leaf node and delete the key from the internal node as well.
 Fill the empty space in the internal node with the inorder successor.

Deleting 45 from B-
tree
2. If there is an exact minimum number of keys in the node, then delete the key and borrow a
key from its immediate sibling (through the parent).
 Fill the empty space created in the index (internal node) with the borrowed key.

Deleting 35 from B-tree

3. This case is similar to Case II(1) but here, empty space is generated above the immediate
parent node.
After deleting the key, merge the empty space with its sibling.
Fill the empty space in the grandparent node with the inorder successor.
Case III

In this case, the height of the tree gets shrinked. It is a little complicated.Deleting 55 from the
tree below leads to this condition. It can be understood in the illustrations below.
Deleting 55 from B-tree
Sequential File Organization

It is one of the simple methods of file organization. Here each file/records are stored one after
the other in a sequential manner. This can be achieved in two ways:
  Records are stored one after the other as they are inserted into the tables. This method
is called pile file method. When a new record is inserted, it is placed at the end of the
file. In the case of any modification or deletion of record, the record will be searched
in the memory blocks. Once it is found, it will be marked for deleting and new block
of record is entered

Inser
ting a new record:

In the diagram above, R1, R2, R3 etc are the records. They contain all the attribute of a row.
i.e.; when we say student record, it will have his id, name, address, course, DOB etc.
Similarly R1, R2, R3 etc can be considered as one full set of attributes.

In the second method, records are sorted (either ascending or descending) each time they are
inserted into the system. This method is called sorted file method. Sorting of records may be
based on the primary key or on any other columns. Whenever a new record is inserted, it will
be inserted at the end of the file and then it will sort – ascending or descending based on key
value and placed at the correct position. In the case of update, it will update the record and
then sort the file to place the updated record in the right place. Same is the case with delete.
Inserting a new record:

Hash File Organization

In this method of file organization, hash function is used to calculate the address of the block
to store the records. The hash function can be any simple or complex mathematical function.
The hash function is applied on some columns/attributes – either key or non-key columns to
get the block address. Hence each record is stored randomly irrespective of the order they
come. Hence this method is also known as Direct or Random file organization. If the hash
function is generated on key column, then that column is called hash key, and if hash function
is generated on non-key column, then the column is hash column.
These types of file organizations are useful in online transaction systems, where retrieval or
insertion/updation should be faster.

Heap File Organization

This is the simplest form of file organization. Here records are inserted at the end of the file
as and when they are inserted. There is no sorting or ordering of the records. Once the data
block is full, the next record is stored in the new block. This new block need not be the very
next block. This method can select any block in the memory to store the new records. It is
similar to pile file in the sequential method, but here data blocks are not selected sequentially.
They can be any data blocks in the memory. It is the responsibility of the DBMS to store the
records and manage them
When a record has to be retrieved from the database, in this method, we need to traverse from
the beginning of the file till we get the requested record. Hence fetching the records in very
huge tables, it is time consuming. This is because there is no sorting or ordering of the
records. We need to check all the data.

Similarly if we want to delete or update a record, first we need to search for the record.
Again, searching a record is similar to retrieving it- start from the beginning of the file till the
record is fetched. If it is a small file, it can be fetched quickly. But larger the file, greater
amount of time needs to be spent in fetching.

In addition, while deleting a record, the record will be deleted from the data block. But it will
not be freed and it cannot be re-used. Hence as the number of record increases, the memory
size also increases and hence the efficiency. For the database to perform better, DBA has to
free this unused memory periodically.

Indexing
An index is any method that that takes as input a property of records – typically the
value of one or more fields, and finds the records with that property “quickly”

Indexing is a way to optimize performance of a database by minimizing the number of

disk accesses required when a query is processed.

An index or database index is a data structure which is used to quickly locate and access
the data in a database table.

Indexes are created using some database columns.

 The first column is the Search key that contains a copy of the primary key or
candidate key of the table. These values are stored in sorted order so that the
corresponding data can be accessed quickly (Note that the data may or may not
be stored in sorted order).

 The second column is the Data Reference which contains a set of pointers
holding the address of the disk block where that particular key value can be
found.

The notion of index

value
value
?
Any index organization is based on the value of one or more predetermined fields of the
records of the relation we are interested in, which form the so-called search key.

Any subset of the fields of a relation can be taken as the search key for the index
– Note: the notion of search key is different from the one of key of the relation (a key is a
minimal set of fields uniquely identifying the records of the relation)
Obviously, it may happen that the search key coincides with the key of the relation.

Properties of an index
1.Organization of the index
2.Structure of data entries
3.Clustering/non clustering
4.Primary/secondary
5.Dense/sparse
6.Simple key/Composite key
7.Single level/multi level

Organization of the index

Sorted index
The index is a sorted file
• Tree-based
The index is a tree
• Hash-based
The index is a function from search key values to record addresses

Possible structures of a data entry

There are three main alternative techniques for storing a data entry whose search key value is
k (such a data entry is denoted with k*):

1. k* is a data record (with search key equal k)

This is an extreme case, because it does not really correspond to having data entries
separated by data records (the hashed file is anexample of this case)
2. k* is a pair (k,r), where r is a reference (for example the record
identifier) to a data record with search key equal k.The index file is independent from the
data file
3. k* is a pair (k,r-list), where r-list is a list of references (for example, a
list of record identifiers) to data records with search key equal k
the index file is independent from the data file
better use of space, at the cost of variable-length data entries
Clustering/non-clustering

An index (for data file F) is clustering (also called clustered) when its data entries are stored
according to an order that is coherent with (or, identical to) the order of data records in the
data file F. Otherwise, the index is non-clustering (or, unclustered).
Primary and secondary indexes

A primary key index (or simply primary index) is an index on a relation R whose search key
includes the primary key of R. If an index is not a primary key index, then is
called non-primary key index (also called secondary
index).
• In some text, the term “primary index” is used with the same meaning that we assign to the
term “clustering index”, and the term “secondary index” is used with the
same meaning that we assign to the term “non-clustering index”

A primary index cannot contain duplicates

→Typically, a secondary index contains duplicates
→A secondary index is called unique if its search key contains a (non-primary) key. Note
that a unique secondary index does not contain duplicates

Sparse vs. Dense indexes

An index is dense if every value of the search key that appears in the data file
appears also in at least one data entry of the index. An index that is not dense is
sparse (typically, a dense index keeps a search key value for each data block)
Single vs composite key indexes

A search key is called simple if it is constituted by a single field, otherwise is called

composite.
• If the search key is composite, then a query based on the equality predicate (called equality
query) is a query where the value of each field is fixed, while a query that
fixes only some of the fields is actually a range query
• A composite index supports a greater number of queries.With a composite index, a single
query is able to extract more information. For example, we can even avoid
accessing the data records, i.e., we can carry out an index-only evaluation (in particular, when
all the fields that are relevant in the query are part of the search key)
• On the other hand, a composite index is generally more
subject to update than a simple one.

Single level vs multi level indexes

 A single level index is an index where we simply have a single index structure
(i.e., a single index file) and the indexed data file
  A multi level index is an index organization where an index is built on a structure that
is in turn an index file (for a data file or, recursively,
for another index structure).
Comparison of File organizations
SQL Performance Tuning using Indexes

Effective indexes are one of the best ways to improve performance in a database application.

Building The Best Index

Short Keys
Having short index is beneficial for two reasons. First, database work is inherently disk
intensive. Larger index keys will cause the database to perform more disk reads, which limits
throughput. Secondly, since index entries are often involved in comparisons, smaller entries
are easier to compare.
Distinct Keys

The most effective indexes are the indexes with a small percentage of duplicated values. As
an analogy, think of a phone book for a town where almost everyone has the last name of
Smith. A phone book in this town is not very useful if sorted in order of last name, because
you can only discount a small number of records when you are looking for a Smith.

An index with a high percentage of unique values is a selective index. Obviously, a unique
index is highly selective since there are no duplicate entries. Many databases will track
statistics about each index so they know how selective each index is. The database uses these
statistics when generating an execution plan for a query

Clustered Indexes

Always it is better to choose clustered Indexes which may improve the performance.