Transaction characteristics in SQL

The three characteristics of a transaction in SQL are,

i) Access mode
ii) Diagnostics size
iii) Isolation level
Access mode
• This specifies the access a user can have on the data. If the access mode is READ ONLY, then it allows the user
only to read the data. He cannot perform any data manipulation operations like insert, delete, update, create etc.
• If the access mode is READ WRITE, then the user can read and perform various data manipulation operations.
If access mode is READ ONLY, then exclusive locks are not required and hence increase concurrency.
Diagnostics Size
• It is the total number of errors.
Isolation Level
• Transaction isolation levels are,
• i) Read Uncommitted
• ii) Read committed
• iii) Repeatable Read
• iv) Serializable
Read Uncommitted
• A transaction can read the modifications made by an uncommitted transaction. Thus, it becomes vulnerable
to phantom problem. An uncommitted transaction never obtains a shred lock before reading and it needs to
have READ-ONLY access mode. As it cannot write, it does not need exclusive lock as well.
Read Committed
• A transaction reads the values only from committed transaction. It also does not allow other transactions to
modify a value written by T. However, the value T reads may be modified by some other transaction,hence
prone to phantom problem.Unlike READ UNCOMMITTED, a transaction obtains an exclusive lock before
writing and a shared lock before reading objects.
Repeatable Read
• A transaction ‘Y’ reads only from a committed transaction. No other transaction is allowed to change a
value, read or written by the transaction ‘Y’. It sets locks same as a SERIALILZABLE transaction
except index locking.
Serializable
• A Serializable transaction enjoys the highest degree of isolation. A Serializable transaction, ‘T’ reads
only from a committed transaction and a value read or written by ‘T’ is not changed by other
transactions until a T commits. T totally avoid phantom phenomenon. It is the safest of all isolations.
Introduction to Crash Recovery
A transaction may fail because of hardware or a software failure. It is the responsibility of
the recovery manager to handle such failure and ensure ‘atomicity’ and ‘durability’. It
attains atomicity by undoing the uncommitted transactions. It also attains durability by
retaining the committed transaction results even after system crashes.
Under normal execution, transaction manger takes care of serializability by providing
locks when requested. It writes the data to the disk o\in order to avoid loss of data after
the system crash.
Stealing Frames and forcing Pages
• Steal Approach: The changes mode on an object ‘0’ by a transaction is written onto the
disk even before the transaction is committed. This is because another transaction wants
a page to be loaded and buffer manger finds replacing frame with object ‘0’ as optimal.
Force Approach: All the objects in buffer pool are forced to disk after the transaction is
committed.
• The simplistic implementation of recovery management is to
use no-steal-force approach. With no steal, the data will not
be written until a transaction is committed; hence there is no
need of an undo operation. And force approach enables us to
write data to the disk after committing; hence we need no
perform redo operation.
Through these approaches are simple, they have certain
disadvantages.
• i) No steal approach requires a large buffer pool.
• ii) Force approach involves expensive I/O costs.
• System/transaction failures
• 1. Logical Error: The transaction can no longer continue with its normal
execution with some internal conditions such as bad input, data not found,
overflow or resource limits exceeded.
• 2. System Error: The system has entered an undesirable state (example:
deadlock), as a result of which a transaction cannot continue with its normal
execution. This transaction can be re-executed at a later time.
• 3. System Crash: There is a hardware failure or an error in the database software
or the operating system, the causes the loss of the content of temporary storage
and brings transaction processing to a halt. The content of permanent storage
remains same and is not corrupted.
• 4. Disk Failure: A disk block loses its content as result of either a head crash or
failure brings a data transfer operating. Copies of the data on other disks, or
backups on tapes, are used to recover from the failure.
ARIES

• ARIES is an algorithm for recovering from crash, that uses no-force,

steal approach.
ARIES algorithm has three phases:
Analyses Phase: If analyses the buffer pool to identify the active
transactions and dirty pages.
Undo Phase: If the modified data is loaded into disk before a transaction
commits, then it must undo the modification in case of crash.
Redo Phase: It must restore the data which it was before the crash. This
is done if the data modified by committed transaction is not loaded onto
the disk.
• If a steal policy is in effect, the change made to an object in
the buffer pool by a transaction can be written to disk before
the transaction commits. This might be because some other
transaction might “steal” the buffer page presently occupied
by an uncommitted transaction.
• If no-force policy is in effect, when a transaction commits,
we need not ensure that all the changes it has made to objects
in the buffer pool are immediately forced to disk
 CONCURRENCY CONTROL AND CRASH RECOVERY

• Each transaction, on its own, preserves database consistency i.e. serial execution of
transactions preserves database consistency. A (possibly concurrent) schedule is
serializable if it is equivalent to a serial schedule
Different forms of schedule equivalence give rise to the notions of conflict
serializability and view serializability
Conflict Serializability
Instructions li and lj of transactions Ti and Tj respectively, conflict if and only if there
exists some item Q accessed by both li and lj, and at least one of these instructions wrote Q.
• 1. li = read(Q), lj = read(Q). li and lj don’t conflict.
• 2. li = read(Q), lj = write(Q). They conflict.
• 3. li = write(Q), lj = read(Q). They conflict
• 4. li = write(Q), lj = write(Q). They conflict
View Serializability

• Let S and S´ be two schedules with the same set of transactions. S and S´ are view
equivalent if the following three conditions are met, where Q is a data item and Ti
is a transaction:
• 1. If Ti reads the initial value of Q in schedule S, then Ti must, in schedule S´, also
read the initial value of Q
• 2. If Ti executes read(Q) in schedule S, and that value was produced by transaction
Tj (if any), then transaction Ti must in schedule S´ also read the value of Q that
was produced by transaction Tj
• 3. The transaction (if any) that performs the final write(Q) operation in schedule S
(for any data item Q) must perform the final write(Q) operation in schedule S´
Testing for Serializability
• Consider some schedule of a set of transactions T1, T2, ..., Tn
• Precedence graph: a directed graph where the vertices are transaction names • We draw an arc from Ti to Tj
if the two transaction conflict, and Ti accessed the data item before Tj
• We may label the arc by the item that was accessed \• Example:
• Example Schedule and Precedence Graph
 Lock Management
• The data items must be accessed in a mutually exclusive manner in order to ensure serializability i.e.,
a data item can be accessed by only one transaction at a time. This can be accomplished by allowing
the transaction to access a dataitem only if it is holding a lock o that data item.
• • A lock manager is a component of the DBMS that keeps track of the locks issued to the
transactions. It maintains a hash tables with the data object identifier as a key called Lock Table.
• • It also maintains a unique entry for each transaction in a transaction table (TT) and each entry
contains a pointer to a series of locks held by the transaction.
• A Lock Table Entry: While can either be a page or a record for an object contains the following
information:
• i) The number of transactions which holds a lock on the object currently which can be more than one
in shared mode.
• ii) The nature of the lock which can either be shared or exclusive and
• iii) A pointer to a queue holding lock requests
• Locking Modes
• i) Shared: A transaction T-I can read the dataitem P but
cannot write it, if it is holding a shared, mode lock. It is
denoted by S.
• ii) Exclusive: A transaction T-I can both read and write the
dataitem P if it is holding an exclusive-mode lock. It is
denoted by X.
Dealing with Deadlocks

• Deadlock definition: Deadlock is a situation where one transaction is

waiting for another transaction to release locks before it can proceed.
• Example: Suppose a transaction T1 holds an exclusive lock on some
dataitem P and transaction T2 holds an exclusive lock on data item Q.
Now, T1 requests an exclusive lock on Q and T2 requests for an
exclusive lock on P and are queued.So, T1 is waiting for T-2 to release
its lock and T2 is waiting for T1 to release its lock leading to a situation
called deadlock where neither of the two transactions can proceed.
Deadlock Prevention

• Wait-Die: Wait- Die is a non preemptive scheme. As the

name specifies, the transaction either waits for the lock or
dies. The decision on whether to wait or die is made based on
the time stamp
• Wound – Wait: It is a preemptive scheme wherein if a
transaction Ti requests a dataitem which is currently under
the control of transaction Tj, it is allowed to wait if its time
stamp value is greater than that of Tj, else Tj is rolled back.
• Advantages of wait-die Scheme
• i) No occurrence of deadlock, because lower priority transactions need not have to
wait for higher priority transactions.
• ii) It avoids starvation (i.e, no transaction is allowed to progress and rolled back
repeatedly).
• Disadvantage: Unnecessary rollbacks may occur
• Advantages of Wound-wait scheme
• 1. Deadlock never occurs because higher priority transactions needn’t have to wait
for lower priority transaction.
• 2. It also avoids starvation.
• Disadvantage: Unnecessary rollbacks may occur.