DFC 20123:

DATABASE DESIGN

CHAPTER 5:
DATABASE TRANSACTION
MANAGEMENT
DEMONSTRATE DATABASE TRANSACTION MANAGEMENT

5.1.1 Describe transaction system

5.1.2 Identify the transaction processing systems category:
a. Batch transaction processing system
b. On-line transaction processing system (OLTP)
c. Real time transaction processing system
5.1.3 Describe the properties of database transaction: Atomicity, Consistency, Isolation, Durability
5.1.4 Perform transaction of a given database using SQL statements
5.1.5 Use START TRANSACTION and COMMIT statements
5.1.6 State the purpose of concurrency control
5.1.7 Describe the problems of concurrency control:
a. Lost update
b. Uncommitted data
c. Inconsistent retrieval
5.1.8 Define the Concurrency control with locking methods:
a. Lock Granularity
b. Lock Types
c. Two Phase Locking to ensure serializability
d. Deadlocks
5.1.9 Explain database recovery management:
a. Database recovery
b. Transaction recovery
c. Database back-up
 DESCRIBE TRANSACTION SYSTEM

Database Transaction : A database

transaction is a logical unit of database
operations which are executed as a whole
to process user requests for retrieving
data or updating the database.
TRANSACTION PROCESSING SYSTEMS

 A type of information system that collects, stores, modifies and retrieves the data
transactions of an enterprise.
 Transaction processing systems also attempt to provide predictable response
times to requests, although this is not as critical as for real-time systems.
 Rather than allowing the user to run arbitrary programs as time-sharing,
transaction processing allows only predefined, structured transactions.
 Each transaction is usually short duration and the processing activity for each
transaction is programmed in advance.
VALUE OF TPS
 The following features are considered important in evaluating transaction
processing systems.
 Performance - Fast performance with a rapid response time is critical. Transaction
processing systems are usually measured by the number of transactions they can
process in a given period of time.
 Continuous availability - The system must be available during the time period when
the users are entering transactions. Many organizations rely heavily on their TPS; a
breakdown will disrupt operations or even stop the business.
 Data integrity - The system must be able to handle hardware or software problems
without corrupting data. Multiple users must be protected from attempting to change the
same piece of data at the same time, for example two operators cannot sell the same seat
on an airplane.
 Ease of use - Often users of transaction processing systems are casual users. The
system should be simple for them to understand, protect them from data-entry errors as
much as possible, and allow them to easily correct their errors.
 Modular growth - The system should be capable of growth at incremental costs, rather
than requiring a complete replacement. It should be possible to add, replace, or update
BATCH TRANSACTION PROCESSING

 Relies on accumulating transaction data over a period of time and then

processing the entire batch at once.
 Batch processing is usually cyclic: daily, weekly, or monthly run cycle
is
established depending on the nature of the transactions
 Cheaper than on-line processing
 Easier to control than on-line processing
 Database is constantly out of date
 Batch processing is now being captured using disk files
ON-LINE TRANSACTION PROCESSING SYSTEM
(OLTP)

 Each transaction is completely processed immediately upon

entry.
 OLAP is the most common mode of used today
 More costly than batch processing
 Database is always up to date
 Require the use of fast secondary storage such as magnetic
disks
REAL-TIME TRANSACTION PROCESSING

 (i) enforcing time constraints of transactions, i.e., meet time constraints on

invocation and completion, and
 (ii) ensuring temporal consistency of data, i.e., data should be valid/fresh at the
time of usage.
 The successful integration of time-cognizant behavior and transaction processing
into a database system is generally referred to as a real-time database system
(RTDB).
 also referred to as online transaction processing, or OLTP. In this case, the
records in the system always reflect the current status.
 BATCH VS. REAL-TIME

Batch Processing Real-time Processing

 also called online
 transaction data are
accumulated  immediately processed
 processed periodically  Syncronization issues
 used to be necessary  What if two people order the
because of synchronization same product at the same
problems extact time, but there is only
one product left?
PROPERTIES OF DATABASE
TRANSACTION

The properties of database transaction (ACID):

 Atomic - all or nothing
 All of the tasks of a database transaction must be completed;
 If incomplete due to any possible reasons, the database
transaction must be aborted.
 Consistent
 The database must be in a consistent before and after the
database transaction. It means that a database transaction must
not break the database integrity constraints.
PROPERTIES OF DATABASE
TRANSACTION
Isolated
 Data used during the execution of a database
transaction must not be used by another database
transaction until the execution is completed.
Durable
 Database changes are permanent after the
transaction completes.
START TRANSACTION AND COMMIT
START TRANSACTION statement :
begins a new transaction
COMMIT: commits the current
transaction, making its changes
permanent.
ROLLBACK: rolls back the current
transaction, canceling its changes.
START TRANSACTION AND COMMIT
PURPOSE OF CONCURRENCY CONTROL

The purpose of concurrency control is to

prevent two different users (or two different
connections by the same user) from trying to
update the same data at the same time.
PURPOSE OF CONCURRENCY CONTROL
 The following examples explain why concurrency control is needed. For both examples,
suppose that your checking account contains $1,000. During the day you deposit $300 and
spend $200 from that account. At the end of the day your account should have $1,100.
 Example 1: No concurrency control
 At 11:00 AM, bank teller #1 looks up your account and sees that you have $1,000. The teller
subtracts the $200 check, but is not able to save the updated account balance ($800)
immediately.
 At 11:01 AM, another teller #2 looks up your account and still sees the $1,000 balance. Teller #2
then adds your $300 deposit and saves your new account balance as $1,300.
 At 11:09 AM, bank teller #1 returns to the terminal, finishes entering and saving the updated
value that is calculated to be $800. That $800 value writes over the $1300.
 At the end of the day, your account has $800 when it should have had $1,100 ($1000 + 300 -
200).
 Example 2: Concurrency control
 When teller #1 starts working on your account, a lock is placed on the account.
 When teller #2 tries to read or update your account while teller #1 is updating your account,
teller #2 will not be given access and gets an error message.
 After teller #1 has finished the update, teller #2 can proceed.
 At the end of the day, your account has $1,100 ($1000 - 200 + 300)
INTERFERENCE PROBLEM ARISE FROM
SIMULTANEOUS ACCESS TO DATABASE

Lost Update
Uncommitted dependency
Inconsistent retrieval
The scheduler
INTERFERENCE PROBLEM ARISE FROM
SIMULTANEOUS ACCESS TO DATABASE

Lost Update
 Lost updates occur when two or more transactions
select the same row and then update the row
based on the value originally selected.
 One user’s update overwrite another user’s update
 The last update overwrites updates made by the other transactions,
which results in lost data.
INTEREFERENCE PROBLEM ARISE FROM
SIMULTANEOUS ACCESS TO DATABASE

Uncommitted dependency(Dirty Read)

 When one transaction reads data written by another
transaction before the other transaction commits.

Inconsistent Retrieval
 Occurs when a transaction reads a several values, but
another transaction updates some of the values while the
first transaction is still executing.
READ/WRITE CONFLICT SCENARIOS:
CONFLICTING DATABASE OPERATIONS MATRIX

 Transactions T1 and T2 are executing concurrently over the

same data
 When they both access the data and at least one is executing a
WRITE, a conflict can occur
CONCURRENCY CONTROL WITH
LOCKING METHODS

Lock Granularity
Locks
Two-Phase Locking (2PL) protocol.
Deadlocks
LOCK GRANULARITY

It deals with the cost of implementing locks depending upon the space and time.

Here, space refers to data structure in DBMS for each lock and time refers to handling of lock request and release.

The cost of implementing locks depends on the size of data items. There are two types of lock granularity:
• Fine granularity
• Coarse granularity

Fine granularity refers for small item sizes and coarse granularity refers for large item Sizes.
Here, Sizes decides on the basis:
• a database record
• a field value of a database record
• a disk block
• a whole file
• the whole database

If a typical transaction accesses a small number of records it is advantageous that the data item granularity is one record.

If a transaction typically accesses many records of the same file it is better to have block or file granularity so that the transaction
will consider all those records as one data item.
LOCKS

 A procedure used to control to control concurrent access

to data. When transaction is accessing the database, a
lock may deny access to other transaction to prevent
incorrect results
 Two major types of locks are utilized:
 Shared Lock(Read): conflicts with exclusive locks – can read the item
but not update it.
 Exclusive Lock(Write) : can both read and update the item.
TWO-PHASE LOCKING (2PL) PROTOCOL

 The protocol utilizes locks that block other

transactions from accessing the same data
during a transaction's life.
 Protocol to prevent lost update problems
 2PL protocol locks are applied and removed in
two phases:
 Phase 1(Expanding phase): locks are acquired and no locks are
released.
 Phase 2(Shrinking phase): locks are released and no locks are
acquired
DEADLOCKS
 Condition that occurs when two transactions wait for each
other to unlock data
 T1 needs data items X and Y; T needs Y and X
 Each gets the its first piece of data but then waits to get the second
(which the other transaction is already holding) – deadly embrace
 Possible only if one of the transactions wants to obtain an
exclusive lock on a data item
 No deadlock condition can exist among shared locks

 Control through
 Prevention
 Detection
 Avoidance
HOW A DEADLOCK CONDITION IS CREATED
RECOVERY TOOLS
 Transaction Log
 Transaction log records all transactions
and the database modifications made by
each transaction.
 A critical component of the database and,
if there is a system failure, the transaction
log might be required to bring database
back to a consistent state.
RECOVERY TOOLS

 Transaction Log
 History of database changes
 Operations
 Undo: revert to previous state
LSN 
TransNo Action Time Table Row Column Old New
Redo: reestablish a new state
1 101001 START 10:29
2 101001 UPDATE 10:30 Acct 10001 AcctBal 100 200
3 101001 UPDATE 10:30 Acct 15147 AcctBal 500 400
4 101001 INSERT 10:32 Hist 25045 * <1002,
500,
…>
5 101001 COMMIT 10:33
RECOVERY TOOLS

 Database Back-up
 Enables to back up and restore databases.
 Backup and restore component provides an important safeguard
for protecting critical data stored in Database.
 A copy of data that can be used to restore and recover the data is
called a backup. Backups can restore data after a failure. With
good backups, it can recover from many failures, such as:
 Media failure.
 User errors, for example, dropping a table by mistake.
 Hardware failures, for example, a damaged disk drive or permanent loss of a
server.
 Natural disasters.
 DATABASE RECOVERY MANAGEMENT

 Database recovery
 Restores database from a given state, usually inconsistent, to a previously consistent
state
 Based on the atomic transaction property
 All portions of the transaction must be treated as a single logical unit of work, in which all
operations must be applied and completed to produce a consistent database
 If transaction operation cannot be completed, transaction must be aborted, and any
changes to the database must be rolled back (undone)
 TRANSACTION RECOVERY

 The database recovery process involves bringing the database to a consistent state after
failure.
 Transaction recovery procedures generally make use of deferred-write and write-through
techniques
 TRANSACTION RECOVERY

 Deferred write
 Transaction operations do not immediately update the physical database

 Only the transaction log is updated

 Database is physically updated only after the transaction reaches its

commit point using the transaction log information
 If the transaction aborts before it reaches its commit point, no
ROLLBACK is needed because the DB was never updated
 A transaction that performed a COMMIT after the last checkpoint is
redone using the “after” values of the transaction log
 TRANSACTION RECOVERY

 Write-through

 Database is immediately updated by transaction operations during the transaction’s execution, even
before the transaction reaches its commit point
 If the transaction aborts before it reaches its commit point, a ROLLBACK is done to restore the
database to a consistent state

 A transaction that committed after the last checkpoint is redone using the
“after” values of the log
 A transaction with a ROLLBACK after the last checkpoint is rolled back
using the “before” values in the log
A TRANSACTION LOG FOR TRANSACTION
RECOVERY EXAMPLES
 TRANSACTION RECOVERY
EXAMPLES
T101 consists of 2 UPDATE statements that reduce the QOH for
product 54778-2T and increase the customer balance for customer
10011 for a credit sale of 2 units of that product
 T106 represents a credit sale of 1 unit of 89-WRE-Q to customer
10016 for $277.55 This transaction consists of 3 INSERT and 2
UPDATE statements
 T155 is an inventory update increasing QOH for 2232/QWE to
26 units
 A DB checkpoint wrote all updated database buffers to disk
which is only for T101
 TRANSACTION RECOVERY
EXAMPLES

 Last checkpoint was 423

 T101 started and finished before that checkpoint so all changes
were written to disk and no action need be taken
 T106 and T155 committed after the last checkpoint so they will
have their “after” values written to disk using the log