Transaction Management,

Concurrency Control
Technique, Backup and
Recovery
Kuribachew Gizaw(PhD)

Dec2023
Introduction
 Transaction processing systems are systems with large
databases and hundreds of concurrent users executing database transactions.
 Examples of such systems include airline reservations, banking, credit card processing,
online retail purchasing, stock markets, supermarket checkouts, and many other
applications.
 A transaction is an executing program that forms a logical unit of database
processing.
 A transaction includes one or more database access operations—these can
include insertion, deletion, modification, or retrieval operations.
 One way of specifying the transaction boundaries is by specifying explicit begin
transaction and end transaction statements in an application program.
Read-Write transaction
 If the database operations in a transaction do not update the database but
only retrieve data, the transaction is called a read-only transaction;
otherwise it is known as a read-write transaction.
 read_item(X). Reads a database item named X into a program variable. To simplify
our notation,we assume that the program variable is also named X.
 write_item(X). Writes the value of program variable X into the database item named
X.
Concurrency Control
 Concurrency control and recovery mechanisms are mainly concerned with the
database commands in a transaction.
 Transactions submitted by the various users may execute concurrently and
may access and update the same database items. If this concurrent execution
is uncontrolled, it may lead to problems, such as an inconsistent database.
 Why concurrency control is needed?
 The Lost Update Problem: This problem occurs when two transactions that
access the same database items have their operations interleaved in a way that
makes the value of some database items incorrect. Then changes the updated
value resulting from one of the transaction is lost.
Why concurrency control is
needed?...
 The Temporary Update (or Dirty Read) Problem: This problem occurs when
one transaction updates a database item and then the transaction fails for some
reason. Meanwhile, the updated item is accessed (read) by another transaction
before it is changed back to its original value.
 The Incorrect Summary Problem: If one transaction is calculating an
aggregate summary function on a number of database items while other
transactions are updating some of these items, the aggregate function may
calculate some values before they are updated and others after they are
updated.
 The Unrepeatable Read Problem: Another problem that may occur is called
unrepeatable read, where a transaction T reads the same item twice and the
item is changed by another transaction T between the two reads.
Transaction States
 A transaction is an atomic unit of work that should either be completed in its entirety or
not done at all. For recovery purposes, the system needs to keep track of when each
transaction starts, terminates, and commits or aborts.
 BEGIN_TRANSACTION. This marks the beginning of transaction execution.
 READ or WRITE. These specify read or write operations on the database items that are executed
as part of a transaction.
 END_TRANSACTION. This specifies that READ and WRITE transaction operations have ended and
marks the end of transaction execution.
 However, at this point it may be necessary to check whether the changes introduced by
the transaction can be permanently applied to the database (committed) or whether the
transaction has to be aborted because it violates serializability or for some other reason.
 COMMIT_TRANSACTION. This signals a successful end of the transaction so that any changes
(updates) executed by the transaction can be safely committed to the database and will not be
undone.
 ROLLBACK (or ABORT). This signals that the transaction has ended unsuccessfully, so that any
changes or effects that the transaction may have applied to the database must be undone.
Transaction States
The System Log
In these entries, T refers to a unique transaction-id that is generated automatically
by the system for each transaction and that is used to identify each transaction:
1. [start_transaction,T]. Indicates that transaction T has started execution.
2. [write_item, T, X, old_value, new_value]. Indicates that transaction T has
changed the value of database item X from old_value to new_value.
3. [read_item,T,X].Indicates that transaction T has read the value of database item
X.
4. [commit, T]. Indicates that transaction T has completed successfully, and affirms
that its effect can be committed (recorded permanently) to the database.
5. [abort,T].Indicates that transaction T has been aborted.
A transaction T reaches its commit point when all its operations that access the
database have been executed successfully and the effect of all the transaction
operations on the database have been recorded in the log. Beyond the commit
point, the transaction is said to be committed, and its effect must be permanently
recorded in the database.
Desirable properties of Transaction
 Transactions should possess several properties, often called the ACID
properties; they should be enforced by the concurrency control and recovery
methods of the DBMS. The following are the ACID properties:
 Atomicity. A transaction is an atomic unit of processing; it should either be
performed in its entirety or not performed at all.
 Consistency preservation. A transaction should be consistency preserving,
meaning that if it is completely executed from beginning to end without interference
from other transactions, it should take the database from one consistent state to
another.
 Isolation. A transaction should appear as though it is being executed in isolation
from other transactions, even though many transactions are executing.
 Durability or permanency. The changes applied to the database by a
committed transaction must persist in the database. These changes must not be lost
because of any failure.
Schedules
 A schedule (or history) S of n transactions T1,T2,...,Tn is an ordering of the
operations of the transactions.
 Two operations in a schedule are said to be conflict if they satisfy all three of the
following conditions:
(1) they belong to different transactions;
(2) they access the same item X; and
(3) at least one of the operations is a write_item(X).

complete schedule is if the following conditions hold:

1. The operations in S are exactly those operations in T1,T2,...,Tn, including a
commit or abort operation as the last operation for each transaction in the schedule.
2. For any pair of operations from the same transaction Ti, their relative order
of appearance in S is the same as their order of appearance in Ti.
3. For any two conflicting operations, one of the two must occur before the
other in the schedule.
Characterizing Schedules Based on
Recoverability
 recoverable schedule is A schedule S is recoverable if no transaction T in S
commits until all transactions T that have written some item X that T reads have
committed.
 In a recoverable schedule, no committed transaction ever needs to be rolled back,
and so the definition of committed transaction as durable is not violated.
 However, it is possible for a phenomenon known as cascading rollback (or
cascading abort) to occur in some recoverable schedules, where an uncommitted
transaction has to be rolled back because it read an item from a transaction that
failed.
 A schedule is said to be cascadeless, or to avoid cascading rollback, if every
transaction in the schedule reads only items that were written by committed
transactions.
 a strict schedule, in which transactions can neither read nor write an item X
until the last transaction that wrote X has committed (or aborted). Strict
schedules simplify the recovery process.
Characterizing Schedules Based on Serializability
 schedules that are always considered to be correct when concurrent
transactions are executing are known as serializable schedules.
 If no interleaving of operations is permitted, there are only two
possible outcomes:
1. Execute all the operations of transaction T1 (in sequence) followed by all the
operations of transaction T2 (in sequence).
2. Execute all the operations of transaction T2 (in sequence) followed by all the
operations of transaction T1 (in sequence).
 The concept of serializability of schedules is used to identify which schedules
are correct when transaction executions have interleaving of their operations
in the schedules.
 Serial, Non-serial, and Conflict-
Serializable Schedules
 Serial , When the operations of each transaction are executed
consecutively, without any interleaved operations from the other
transaction.
 Non-serial when each sequence interleaves operations from the two
transactions.
 A schedule S of n transactions is serializable if it is equivalent to some
serial schedule of the same n transactions.
 Two schedules are called result equivalent if they produce the same final state
of the database.
 Two schedules are said to be conflict equivalent if the order of any two
conflicting operations is the same in both schedules.
Transaction Support in SQL
 With SQL, there is no explicit Begin Transaction statement. Transaction
initiation is done implicitly when particular SQL statements are encountered.
 However, every transaction must have an explicit end statement, which is
either a COMMIT or a ROLLBACK.
 Every transaction has certain characteristics attributed to it. These
characteristics are specified by a SET TRANSACTION statement in SQL. The
characteristics are the access mode, the diagnostic area size, and the isolation
level.
 The access mode can be specified as READ ONLY or READ WRITE. The
default is READ WRITE, unless the isolation level of READ UNCOMMITTED is
specified (see below), in which case READ ONLY is assumed.
 A mode of READ WRITE allows select, update, insert, delete, and create commands
to be executed.
 A mode of READ ONLY, as the name implies, is simply for data retrieval
 Continued…
 The diagnostic area size option, DIAGNOSTIC SIZE n, specifies an integer
value n, which indicates the number of conditions that can be held
simultaneously in the diagnostic area.
 The isolation level option is specified using the statement ISOLATION
LEVEL , where the value for can be READ UNCOMMITTED, READ
COMMITTED, REPEATABLE READ, or SERIALIZABLE.
 If a transaction executes at a lower isolation level than SERIALIZABLE, then
one or more of the following three violations may occur:
 Dirty read. A transaction T1 may read the update of a transaction T2, which has
not yet committed. If T2 fails and is aborted, then T1 would have read a value
that does not exist and is incorrect.
 Continued…

2. Non-repeatable read. A transaction T1 may read a given value from a table.

If another transaction T2 later updates that value and T1 reads that value again,
T1 will see a different value.
3. Phantoms. A transaction T1 may read a set of rows from a table, perhaps
based on some condition specified in the SQL WHERE-clause. Now suppose that
a transaction T2 inserts a new row that also satisfies the WHERE-clause
condition used in T1, into the table used by T1. If T1 is repeated, then T1 will see
a phantom, a row that previously did not exist.
Sample SQL Transaction
EXEC SQL WHENEVER SQLERROR GOTO UNDO;
EXEC SQL SET TRANSACTION
READ WRITE
DIAGNOSTIC SIZE 5
ISOLATION LEVEL SERIALIZABLE;
EXEC SQL INSERT INTO EMPLOYEE (Fname, Lname, Ssn, Dno, Salary)
VALUES ('Robert', 'Smith', '991004321', 2, 35000);
EXEC SQL UPDATE EMPLOYEE SET Salary = Salary * 1.1 WHERE Dno = 2;
EXEC SQL COMMIT;
GOTO THE_END;
UNDO: EXEC SQL ROLLBACK;
THE_END:
Concurrency Control Techniques
1. Locking: This technique involves placing locks on the resources such as
rows and tables that are being accessed by a transaction to prevent other
transaction modifying them at the same time.
2. Optimistic Concurrency Control: This technique assumes that conflicts
between transactions are rare and allows multiple transaction to read and
write to the same resource without acquiring locks. Before committing
changes, the system checks whether any conflict occurred and rolls back if
necessary.
3. Multi-version Concurrency Control: This technique creates multiple
version of a resource to allow multiple transactions to read and write to it
concurrently. Each transaction sees a consistent snapshot of the database
at the start of the transaction, which eliminates the need for locking.
4. Time Stamp ordering: this technique assigns a unique timestamp to
each transaction and orders them based on their start times. Transactions
are then executed in this order, ensuring that no conflict occurs.
 Why Recovery Is Needed
 Types of Failures. Failures are generally classified as transaction, system, and
media failures.
 There are several possible reasons for a transaction to fail in the middle of
execution:
1. A computer failure (system crash). A hardware, software, or network error occurs in
the computer system during transaction execution. Hardware crashes are usually media
failures—for example, main memory failure.
2. A transaction or system error. Some operation in the transaction may cause it to fail,
such as integer overflow or division by zero. Transaction failure may also occur because of
erroneous parameter values or because of a logical programming error. Additionally, the user
may interrupt the transaction during its execution.
3. Local errors or exception conditions detected by the transaction. During
transaction execution, certain conditions may occur that necessitate cancellation of the
transaction. For example, data for the transaction may not be found. An exception condition,
Such as insufficient account balance in a banking database, may cause a transaction,
such as a fund withdrawal, to be canceled. This exception could be programmed in the
transaction itself, and in such a case would not be considered as a transaction failure.
Why Recovery Is Needed
4. Concurrency control enforcement. The concurrency control method may
decide to abort a transaction because it violates serializability, or it may abort
one or more transactions to resolve a state of deadlock among several
transactions. Transactions aborted because of serializability violations or
deadlocks are typically restarted automatically at a later time.
5. Disk failure. Some disk blocks may lose their data because of a read or
write malfunction or because of a disk read/write head crash. This may
happen during a read or a write operation of the transaction.
6. Physical problems and catastrophes. This refers to an endless list of
problems that includes power or air-conditioning failure, fire, theft, sabotage,
overwriting disks or tapes by mistake, and mounting of a wrong tape by the
operator.
Recovery Techniques
1. Backup and Restore: Making regular backups of the database and
then restoring it in a case of any data loss.
SQL commands to create a full backup of a database
BACKUP DATABASE <Database_Name> To Disk=<‘backup_path’>WITH INIT
SQL commands to restore a database
RESTORE DATABASE <database_name> from DISK=<back up_path>WITH REPLACE

2. Redo logs: are set of files that records all changes made to the
database during transaction. In case of loss these files can replay
transaction.
Implemented by Oracle DB

3. Pont-in-a time Recovery: Rollback to a savepoint

SAVEPOINT savepoint_name (in the middle of the transaction after stating)
Rollback to Savepoint_name
Recovery Techniques…

4. Rollback Segments: Temporary areas that holds

transaction progress information and used to do
undo changes in case of failure.
5. Cluster Failover: For clustered database to
automatically shift from a failed cluster to the
working one
6. Database Replication: Is saving copies of the
database on different server.
Thank you!