5.

TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

5.1 TRANSACTION:
A transaction is an event which occurs on the database. Collection of operations that form a single
logical unit of work are called transaction.

A transaction is one or more SQL statements that make up a unit of work performed against the
database, and either all the statements in a transaction are committed as a unit or all the statements
are rolled back as a unit.

This unit of work typically satisfies a user request and ensures data integrity. For example, when you
use a computer to transfer money from one bank account to another, the request involves a
transaction: updating values stored in the database for both accounts.

Transaction management is an important part of RDBMS-oriented enterprise application to ensure

data integrity and consistency.

Transaction access data using two operations:

Generally a transaction reads a value from the database or writes a value to the database. A read
operation does not change the image of the database in any way. But a write operation, whether
erformed with the intention of inserting, updating or deleting data from the database, changes the
image of the database. Say for example, we have two accounts A and B, each containing Rs 1000/-.
We now start a transaction to deposit Rs 100/- from account A to Account B.

T1: Read A;
A = A – 100;
Write A;
Read B;
B = B + 100;
Write B;

The Four Properties of Transactions every transaction, for whatever purposes it is being used ,has
the following four properties. Taking the initial letters of these four properties we collectively call
them the ACID Properties.

i)Atomicity= all changes are made (commit), or none (rollback).

ii) Consistency = transaction won't violate declared system integrity constraints

iii) Isolation= results independent of concurrent transactions.

iv)Durability= committed changes survive various classes of hardware failure

5.2 PROPERTIES OF TRANSACTION:

1) 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.

1|Page
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

Eg: Suppose before execution of transaction Ti the values of accounts A & B are 1000$ and 2000$
respectively. Now suppose during execution of transaction Ti, a failure occurs. Consider a failure
occurs after write(A) operation but before write(B), then the values reflected in the database are
950$ and 2000$. Thus,the sum A+B no longer preserved. To avoid this, atomicity should be ensured.
To ensure atomicity database system keeps track of the old values of any data on which a
transaction performs a write. If the transaction does not complete its execution, the database
restores the old values. Atomicity is handled by transaction management component.

2) 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.

Eg: Transaction T1 transfers $100 from Account A to Account B. Both Account A and Account B
contains $500 each before the transaction.

Transaction T1
Read (A)
A=A-100
Write (A)
Read (B)
B=B+100
Write (B)
Consistency Constraint:
Before Transaction execution Sum = A + B Sum = 500 + 500 Sum = 1000
After Transaction execution Sum = A + B Sum = 400 + 600 Sum = 1000
Before the execution of transaction and after the execution of transaction SUM must be equal.

3) 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.

Eg: The database is said to be temporarily inconsistent while the transaction of transfer funds from A
to B is executing and at the same time second concurrently running transaction reads at this
intermediate point and computes A+B it will observe an inconsistent value which results in
inconsistent state even after both transactions have completed. To avoid this problem of concurrent
execution, transactions should be executed in isolation. The isolation property of a transaction
ensures that the concurrent execution of transaction results in a system state that could have been
obtained if transactions are executed serially i.e one after the other.

4) DURABILITY:Durability ensures that any transaction committed to the database will not be
lost.Durability is ensured through the use of database backups and transaction logs that facilitate the
restoration of committed transactions in spite of any subsequent software or hardware failures. 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

2|Page
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

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.

TRANSACTION STATE DIAGRAM:

The following are the different states in transaction processing in a Database System.

i) Active ii) Partially Committed iii) Failed iv) Aborted v) Committed

1. Active: This is the initial state. The transaction stay in this state while it is executing.

2. Partially Committed: This is the state after the final statement of the transaction is executed.

3. Failed: After the discovery that normal execution can no longer proceed.

5. Aborted: The state 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: The state after successful completion of the transaction. We cannot abort or rollback
a committed transaction.

5.3 TRANSACTION LOG:

Log is the most widely used structure for recording database modifications. The log is a sequence of
log records, recording all the update activities in the database. It has following four fields :

1) Transaction identifier : is the unique identifier of the transaction that performs the write
operation.
2) Data item identifier: is the unique identifier of the data item written.
3) Old value : is the value of the data item prior to the write.
4) New value : is the value of the data item that it will have after the write.

It is represented as :
<Ti start> : Transaction Ti is started
<Ti, Xj, V1, V2> : Transaction Ti has performed a write on data item Xj, Xj had value V1 before the
write and will have value V2 after the write.
<Ti commit> : Transaction Ti has committed
<Ti abort> : Transaction Ti has aborted

3|Page
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

5.4 TRANSACTION MANAGEMENT WITH SQL USING COMMIT, ROLLBACK

&SAVEPOINT:

Transaction control commands manage changes made by DML commands. The following describes
the nature of transactions:
 All transactions have a beginning and an end.
 A transaction can be saved or undone.
 If a transaction fails in the middle, no part of the transaction can be saved to the database.
Transactional control is the ability to manage various transactions that may occur within a relational
database management system. There are three commands used to control transactions :
i) Commit ii)Rollback iii)Savepoint

1) COMMIT : The commit command saves all transactions to the database since the last
COMMIT or ROLLBACK command happens.
Syntax : commit[work];
The keyword commit is the only mandatory part of the syntax. Keyword work is optional.
Eg: SQL> delete from emp
Where emp_age>60;
This deletes the record of those employee whose age is above 60years. Though the changes
are reflected on database they are not actually saved in database, rather they are stored in
temporary area. To store changes permanently in the database commit command is used.
SQL>commit work;
The above command will made changes permanently in database, since last commit or
rollback command was issued.
2) ROLLBACK:The rollback command is the transactional control command used to undo
transactions that have not already been saved to the database. The rollback command can
only be used to undone the transactions since the last COMMIT or ROLLBACK command was
issued.
Syntax : rollback[work];
The keyword rollback is the only mandatory part of the syntax. Keyword work is optional.
Eg: SQL> delete from emp
Where emp_age>60;
This deletes the record of those employee whose age is above 60years. Though the changes
are reflected on database they are not actually saved in database, rather they are stored in
temporary area. To discard changes permanently in the database commit command is used.
SQL>rollback work;
The above command will discard changes made on database, since last commit or rollback
command was issued.
3) SAVEPOINT:Savepoints offer a mechanism to rollback portions of transactions.
General eg :Consider that a person walking and after passing some distance the road got split
into two tracks. The person is not sure to choose which track, so before randomly selecting
one track he will make a signal flag, so that if the track was not the right one he can rollback
to signal flag and select the right track. In this example the signal flag becomes the savepoint.
Syntax :savepointname_of_savepoint;

4|Page
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

Eg: Before deleting the records of employee we should create a savepoint and then use
delete command to delete employee records.
SQL>savepointDeleteEmp;
SQL>delete from emp
Where emp_age>60;
After some time, if manager orders to not delete employer’s record the changes can undone
by using the rollback to savepoint command.
SQL>rollback to DeleteEmp;
It willrollback the changes made to Emp table.

5.5 CONCURRENCY CONTROL FOR LOST UPDATES, UNCOMMITTED DATA,

INCONSISTENT RETRIEVALS AND THE SCHEDULER :

Concurrent execution have following problems:

 Lost updates
 Uncommited data/ Dirty read
 Inconsistent retrieval/ Unrepeatable read
1) LOST UPDATES: The update of one transaction is overwritten by another transaction.
Eg: Suppose T1 credits 100$ to account A and T2 debits 50$ from account A. The initial value
of A=500$. If credit and debit happens correctly the final value is 550$. But, if we run T1 &
T2 concurently as follows:
T1(Credit) T2(Debit)
Read(A) {A=500} Read(A) {A=500}

A:A+100 {A=600} A:A-50 {A=450}

Write(A) {A=600} Write(A) {A=450}

Commit

Final value of A=450. The credit of T1 is missing (lost update) from the account.

2) UNCOMMITED DATA/DIRTY READ: Reading of a non-existent value of A by T2. If T1 updates

A which is after read by T2, then if at sudden T1 aborts then the value which is read by T2 will
never be existed.
Eg: Let T1 modified A=600. But T1 failed and the update value 600 is removed from the
database then A will get stored to its initial old value 500. Hence the value read by T2 i.e
A=600 is an non-existent value( reading dirty data and no commit command).

5|Page
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

T1(Credit) T2(Debit)
Read(A) {A=500}

A:A+100 {A=600}

Write(A) {A=600}
T1 failed to complete Read(A) {A=500}

A:A+100 {A=600}

Write(A) {A=600}

3) UNREPEATABLE READ/ INCONSISTENT RETRIEVAL:If T2 reads A, which is then altered by T1

and T1 commits now when T2 re-read A it will find a different value of A in the second read.
T1(Credit) T2(Debit)
Read(A) {A=500} Read(A) {A=500}

A:A+100 {A=600} A:A-50 {A=450}

Write(A) {A=600} Commit

Write(A) {A=600}

Eg: Here T1 and T2 reads A=500. Now, T1 modifies A to 600 when, T2 reads it gets value of
600 this should not be the case because T2 in the same execution should get only one value
of A (500 or 600 but not both) which is happening after the commit.

SCHEDULAR:
When multiple transactions are executing concurrently, then the order of execution of operations
from the various transactions is known as schedule.
1) Serial Schedule 2) Non-Serial Schedule
Serial Schedule: Transactions are executed one by one without any interleaved operations from
other transactions.
Non-Serial Schedule: A schedule where the operations from a set of concurrent transactions are
interleaved.

SERIALIZABILITY:
What is Serializability?
A given non serial schedule of n transactions is serializable,if it is equivalent to some serial schedule.
i.e. this non serial schedule produce the same result as of the serial schedule. Then the given non
serial schedule is said to be serializable. A schedule that is not serializable is called a non-serializable.

Non-Serial Schedule Classification: Serializable,NotSerializable,Recoverable,Non Recoverable.

Serializable Schedule Classification:Conflict Serializable,ViewSerializable.

6|Page
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

i)Conflict SerializableSchedule:If a schedule S can be transformed into a schedule S’ by a series of

swaps of non conflicting instruction then we say that S and S’ are conflict equivalent. A schedule S is
called conflict serializable if it is conflict equivalent to a serial schedule.
ii)View SerializableSchedule:All conflict serializable schedule are view serializable. But there are
view serializable schedule that are not conflict serializable. A schedule S is a view serializable if it is
view equivalent to a serial schedule.
iii) Recoverable Schedule Classification: Cascade and Cascadeless.
To recover from the failure of a transaction Ti, we may have to rollback several transactions. This
phenomenon in which a single transaction failure leads to a series of transaction is called cascading
roll back. Avoid cascading roll back by not allowing reading uncommitted data.But this lead to a
serial schedule.

5.6 CONCURRENCY CONTROL WITH LOCKING METHODS:

In a multiprogramming environment where multiple transactions can be executed simultaneously, it
is highly important to control the concurrency of transactions. We have concurrency control
protocols to ensure atomicity, isolation, and serializability of concurrent transactions.
Different types of protocols/schemes used to control concurrent execution of transactions are:

 Lock based protocol

 Timestamp based protocol
 Validation based protocol
 Multiple granularity

1) LOCK BASED PROTOCOL:

Database systems equipped with lock-based protocols by which any transaction cannot read
or write data until it acquires an appropriate lock on it. Locks are of two kinds:
 Binary Locks: A lock on a data item can be in two states; it is either locked or
unlocked.
 Shared/exclusive Locks: This type of locking mechanism differentiates the locks
based on their uses. If a lock is acquired on a data item to perform a write as well as
read operation, it is an exclusive lock.
Read locks are shared because no data value is being changed.
There are four types of lock protocols available:
i)Simplistic Lock Protocol :Simplistic lock-based protocols allow transactions to obtain a lock
on every object before a 'write' operation is performed. Transactions may unlock the data
item after completing the ‘write’ operation.
ii) Pre-claiming Lock Protocol:Pre-claiming protocols evaluate their operations and create a
list of data items on which they need locks. Before initiating an execution, the transaction
requests the system for all the locks it needs beforehand. If all the locks are granted, the
transaction executes and releases all the locks when all its operations are over. If all the
locks are not granted, the transaction rolls back and waits until all the locks are granted.
iii) Two-Phase Locking – 2PL: This locking protocol divides the execution phase of a
transaction into three parts. In the first part, when the transaction starts executing, it seeks
permission for the locks it requires. The second part is where the transaction acquires all the

7|Page
5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

locks. As soon as the transaction releases its first lock, the third phase starts. In this phase,
the transaction cannot demand any new locks; it only releases the acquired locks.
Eg : lock X(B);
Read B;
B: = B – 100;
Write B;
lock X(A);
Read A;
A: = A + 100;
Write A;
unlock(B);
unlock(A);
Two-phase locking has two phases: one is growing, where all the locks are being acquired
by thetransaction; and the second phase is shrinking, where the locks held by the
transaction are being released. To claim an exclusive (write) lock, a transaction must first
acquire a shared (read) lock and then upgrade it to an exclusive lock.
iv)Strict Two-Phase Locking:The first phase of Strict-2PL is same as 2PL. After acquiring all
the locks in the first phase, the transaction continues to execute normally. But in contrast to
2PL, Strict-2PL does not release a lock after using it. Strict-2PL holds all the locks until the
commit point and releases all the locks at a time.Strict-2PL does not have cascading abort as
2PL does.

2) TIMESTAMP BASED PROTOCOL :

The most commonly used concurrency protocol is the timestamp based protocol. This
protocol uses either system time or logical counter as a timestamp. Every transaction has a
timestamp associated with it, and the ordering is determined by the age of the transaction.
A transaction created at 0002 clock time would be older than all other transactions that
come after it. For example, any transaction 'y' entering the system at 0004 is two seconds
younger and the priority would be given to the older one. In addition, every data item is
given the latest read and write-timestamp. This lets the system know when the last ‘read
and write’ operation was performed on the data item.

Timestamp Ordering Protocol :

The timestamp-ordering protocol ensures serializability among transactions in their
conflicting read and write operations. This is the responsibility of the protocol system that
the conflicting pair of tasks should be executed according to the timestamp values of the
transactions.
 The timestamp of transaction Ti is denoted as TS(Ti).
 Read timestamp of data-item X is denoted by R-timestamp(X).
 Write timestamp of data-item X is denoted by W-timestamp(X).

8|Page
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

Timestamp ordering protocol works as follows:

i)If a transaction Ti issues a read(X) operation:

 If TS(Ti) < W-timestamp(X) Operation rejected.

 If TS(Ti) >= W-timestamp(X) Operation executed.

ii)If a transaction Ti issues a write(X) operation:

 If TS(Ti) < R-timestamp(X) Operation rejected.

 If TS(Ti) < W-timestamp(X) Operation rejected and Ti rolled back.

Thomas' Write Rule: This rule states if TS(Ti) < W-timestamp(X), then the operation is rejected
and Ti is rolled back. Timestamp ordering rules can be modified to make the schedule view
serializable. Instead of making Ti rolled back, the 'write' operation itself is ignored.

3) VALIDATION BASED PROTOCOL:

Execution of transaction Ti is done in three phases.
1. Read and execution phase: Transaction Ti writes only to temporary local variables
2. Validation phase: Transaction Ti performs a ``validation test'' to determine if local
variables can be written without violating
serializability.
3. Write phase: If Ti is validated, the updates are applied to the
database; otherwise, Ti is rolled back.
Also called as optimistic concurrency control since transaction executes fully in the hope
that all will go well during validation.
Each transaction Ti has 3 timestamps
 Start(Ti) : the time when Ti started its execution
 Validation(Ti): the time when Ti entered its validation phase
 Finish(Ti) : the time when Ti finished its write phase
4) MULTIPLE GRANUALARITY:

Allow data items to be of various sizes and define a hierarchy of data granularities, where
the small granularities are nested within larger ones.Can be represented graphically as a tree
(but don't confuse with tree-locking protocol).When a transaction locks a node in the tree
explicitly, it implicitly locks all the node's descendents in the same mode.

Granularity of locking (level in tree where locking is done):

i)fine granularity (lower in tree): high concurrency, high locking overhead.
ii) coarse granularity (higher in tree): low locking overhead, low concurrency

The levels, starting from the coarsest (top) level aredatabase,area,file and record.

9|Page
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

5.7. DEADLOCKS:
In a multi-process system, deadlock is an unwanted situation that arises in a shared resource
environment, where a process indefinitely waits for a resource that is held by another process.

For example, assume a set of transactions {T0, T1, T2, ...,Tn}. T0 needs a resource X to complete its
task. Resource X is held by T1, and T1 is waiting for a resource Y, which is held by T2. T2 is waiting for
resource Z, which is held by T0. Thus, all the processes wait for each other to release resources. In
this situation, none of the processes can finish their task. This situation is known as a deadlock.
Deadlocks are not healthy for a system. In case a system is stuck in a deadlock, the transactions
involved in the deadlock are either rolled back or restarted.

5.8 CONCURRENCY CONTROL WITH TIME STAMP ORDERING:

Deadlock Prevention:
To prevent any deadlock situation in the system, the DBMS aggressively inspects all the operations,
where transactions are about to execute. The DBMS inspects the operations and analyzes if they can
create a deadlock situation. If it finds that a deadlock situation might occur, then that transaction is
never allowed to be executed.

There are deadlock prevention schemes that use timestamp ordering mechanism of transactions in
order to predetermine a deadlock situation.

i)Wait-Die Scheme: In this scheme, if a transaction requests to lock a resource (data item), which is
already held with a conflicting lock by another transaction, then one of the two possibilities may
occur:

 If TS(Ti) < TS(Tj) — that is Ti, which is requesting a conflicting lock, is older than Tj — then Ti
is allowed to wait until the data-item is available.
 If TS(Ti) > TS(tj) — that is Ti is younger than Tj — then Ti dies. Ti is restarted later with a
random delay but with the same timestamp. This scheme allows the older transaction to
wait but kills the younger one.

ii)Wound-Wait Scheme: In this scheme, if a transaction requests to lock a resource (data item),
which is already held with conflicting lock by another transaction, one of the two possibilities may
occur:

 If TS(Ti) < TS(Tj), then Ti forces Tj to be rolled back — that is Ti wounds Tj. Tj is restarted
later with a random delay but with the same timestamp.
 If TS(Ti) > TS(Tj), then Ti is forced to wait until the resource is available. This scheme allows
the younger transaction to wait; but when an older transaction requests an item held by a
younger one, the older transaction forces the younger one to abort and release the item. In
both the cases, the transaction that enters the system at a later stage is aborted.

10 | P a g e
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

Deadlock Avoidance:
Aborting a transaction is not always a practical approach. Instead, deadlock avoidance mechanisms
can be used to detect any deadlock situation in advance. Methods like "wait-for graph" are available
but they are suitable for only those systems where transactions are lightweight having fewer
instances of resource. In a bulky system, deadlock prevention techniques may work well.

Wait-for Graph:This is a simple method available to track if any deadlock situation may arise. For
each transaction entering into the system, a node is created. When a transaction Ti requests for a
lock on an item, say X, which is held by some other transaction Tj, a directed edge is created from Ti
to Tj. If Tj releases item X, the edge between them is dropped and Ti locks the data item. The system
maintains this wait-for graph for every transaction waiting for some data items held by others. The
system keeps checking if there's any cycle in the graph.

T1 T2

Here, we can use any of the two following approaches:

 First, do not allow any request for an item, which is already locked by another
transaction. This is not always feasible and may cause starvation, where a
transaction indefinitely waits for a data item and can never acquire it.
 The second option is to roll back one of the transactions. It is not always feasible to
roll back the younger transaction, as it may be important than the older one. With
the help of some relative algorithm, a transaction is chosen, which is to be aborted.
This transaction is known as the victim and the process is known as victim selection.

5.9. DATABASE RECOVERY MANAGEMENT: TRANSACTION RECOVERY :

FAILURE CLASSIFICATION:

1) 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) System crash: a power failure or other hardware or software failure causes the system to crash.

Fail-stop assumption: non-volatile storage contents are assumed to not be corrupted by system
crash. Database systems have numerous integrity checks to prevent corruption of disk data

3) Disk failure: a head crash or similar disk failure destroys all or part of disk storage

Destruction is assumed to be detectable: disk drives use checksums to detect failures

11 | P a g e
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

To ensure atomicity despite failures, we first output information describing the modifications to
stable storage without modifying the database itself. We study two approaches:

1) log-based recovery 2) shadow-paging

1) LOG BASED RECOVERY :

We assume (initially) that transactions run serially, that are, one after the other. A log is kept
on stable storage. The log is a sequence of log records, and maintains a record of update
activities on the database. Each and every log record is given a unique id called log sequence
number.
A log record is written for each of the following actions:
 Updating a page
 Commit
 Abort
 End
 Undoing an update

Two approaches using logs :

i) Deferred database modification

ii)Immediate database modification
 The deferred database modification scheme records all modifications to the log, but defers
all the writes to after partial commit.
Assume that transactions execute serially.Transaction starts by writing <Tistart>record to
log.
i) A write(X) operation results in a log record <Ti, X, V>being written, where V is the new value
for X
l Note: old value is not needed for this scheme
ii) The write is not performed on X at this time, but is deferred.
iii) When Tipartially commits, <Ticommit> is written to the log
iv) Finally, the log records are read and used to actually execute the previously deferred writes.
 The immediate database modification scheme allows database updates of an uncommitted
transaction to be made as the writes are issued.since undoing may be needed, update logs
must have both old value and new value.
i)Update log record must be written before database item is written
a. We assume that the log record is output directly to stable storage
b. Can be extended to postpone log record output, so long as prior to execution of
an output(B) operation for a data block B, all log records corresponding to items
B must be flushed to stable storage
ii) Output of updated blocks can take place at any time before or after transaction
commit
iii) Order in which blocks are output can be different from the order in which they are
written.
2) SHADOW PAGING :
Shadow paging is an alternative to log-based recovery; this scheme is useful if transactions
execute serially

12 | P a g e
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

Idea: maintain two page tables during the lifetime of a transaction –the current page table,
and the shadow page table. Store the shadow page table in nonvolatile storage, such that
state of the database prior to transaction execution may be recovered. Shadow page table is
never modified during execution
To start with, both the page tables are identical. Only current page table is used for data
item accesses during execution of the transaction. Whenever any page is about to be written
for the first time
 A copy of this page is made onto an unused page.
 The current page table is then made to point to the copy
 The update is performed on the copy
Advantages of shadow-paging over log-based schemes:
o no overhead of writing log records
o recovery is trivial

CHECKPOINT:

Keeping and maintaining logs in real time and in real environment may fill out all the memory space
available in the system. As time passes, the log file may grow too big to be handled at all. Checkpoint
is a mechanism where all the previous logs are removed from the system and stored permanently in
a storage disk. Checkpoint declares a point before which the DBMS was in consistent state, and all
the transactions were committed.

When a system with concurrent transactions crashes and recovers, it behaves in the following
manner:

 The recovery system reads the logs backwards from the end to the last checkpoint.
 It maintains two lists, an undo-list and a redo-list.
 If the recovery system sees a log with <Tn, Start> and <Tn, Commit> or just <Tn, Commit>, it
puts the transaction in the redo-list.
 If the recovery system sees a log with <Tn, Start> but no commit or abort log found, it puts
the transaction in the undo-list. All the transactions in the undo-list are then undone and
their logs are removed. All the transactions in the redo-list and their previous logs are
removed and then redone before saving their logs.

REMOTE BACKUP:

Remote backup provides a sense of security in case the primary location where the database is
located gets destroyed. Remote backup can be offline or realtime or online. In case it is offline, it is
maintained manually.

13 | P a g e
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

Online backup systems are more real-time and lifesavers for database administrators and
investors. An online backup system is a mechanism where every bit of the real-time data is
backed up simultaneously at two distant places. One of them is directly connected to the
system and the other one is kept at a remote place as backup.
As soon as the primary database storage fails, the backup system senses the failure and
switches the user system to the remote storage. Sometimes this is so instant that the users
can’t even realize a failure.

ARIES:
 ARIES is a state of the art recovery method
i)Incorporates numerous optimizations to reduce overheads during normal processing
and to speed up recovery
ii)Unlike the advanced recovery algorithm, ARIES
Uses log sequence number (LSN) to identify log records
 Stores LSNs in pages to identify what updates have already been applied to a
database page.
 Physiological redo.
 Dirty page table to avoid unnecessary redos during recovery

ARIES RECOVERY ALGORITHM:

ARIES recovery involves three passes
1) Analysis pass: Determines
 Which transactions to undo
 Which pages were dirty (disk version not up to date) at time of crash
 RedoLSN: LSN from which redo should start
2) Redo pass:
 Repeats history, redoing all actions from RedoLSN
 RecLSN and PageLSNs are used to avoid redoing actions already reflected on page
3) Undo pass:
 Rolls back all incomplete transactions.
 Transactions whose abort was complete earlier are not undone
 Key idea: no need to undo these transactions: earlier undo actions were logged, and are
redone as required.
5.10. SQL CONSTRUCTS THAT GRANT ACCESS OR REVOKE ACCESS FROM USER
OR USER GROUPS:
Data Control Language (DCL) statements is used to create roles, permissions, and referential
integrity as well it is used to control access to database by securing it.
DCL Commands:           Grant, Revoke

GRANT - gives user's access privileges to database

REVOKE - withdraw access privileges given with the GRANT command.
CREATING A USER
SQL>CONNECT SYSTEM/MANAGER;
SQL>CREATE USER "USERNAME" IDENTIFIED BY "PASSWORD"
SQL>GRANT DBA TO "USERNAME"

14 | P a g e
 5. TRANSACTION MANAGEMENT & CONCURRENCY CONTROL

SQL>CONNECT "USERNAME"/"PASSWORD";
EXAMPLE:
CREATING A USER
SQL>CONNECT SYSTEM/MANAGER;
SQL>CREATE USER CSE2 IDENTIFIED BY CSECSE;
SQL>GRANT DBA TO CSE2;
SQL>CONNECT CSE2/CSECSE;
SQL>REVOKE DBA FROM CSE2;

15 | P a g e