1
X. Transaction Management and Concurrency Control
2
Transactions A transaction is a logical unit of work that
must be completed as a whole or not at all Combination of related SELECT, UPDATE, INSERT
statements Could be a single SQL statement
Actions of a transaction (in a single user system) Open, Read, Write, Commit, Rollback
2
3
Example of a transactionopen transactionvideoId video1 = select id of a copy of "Star
Wars"if (video1 == null) rollback transactioninsert row into Reservation for video1videoId video2 = select id of a copy of “The
Empire Strikes Back"if (video2 == null) rollback transactioninsert row into Reservation for video2videoId video3 = select id of a copy of “Return
of the Jedi"if (video3 == null) rollback transactioninsert row into Reservation for video3commit transaction
Transaction Management with SQL SQL statements that provide transaction
support COMMIT ROLLBACK
Transaction sequence must continue until: COMMIT statement is reached ROLLBACK statement is reached End of program is reached Program is abnormally terminated
4
3
5
ACID Test for Transactions Atomicity: the property of a transaction that all of
the updates are successful, or there is no update at all.
Consistency: each transaction should leave the database in a consistent state. Properties such as referential integrity must be preserved.
Isolation: each transaction when executed concurrently with other transactions should have the same affect as if it had been executed by itself.
Durability: once a transaction has completed successfully, its changes to the database should be permanent. Even serious failures should not affect the permanence of a transaction.
6
Database Control Issues Data Integrity - protecting data from
inconsistent or unintended status Concurrency Control - problems that can
occur when two or more transactions attempt to update a piece of data simultaneously.
Backup and Recovery - having procedures in place to recreate data that has been lost or corrupted, for any reason.
Data Security - protecting the data from theft, from malicious destruction, from unauthorized updating, etc.
4
7
Overview Database control issues
Transaction processing ACID test
Integrity (deals with A and C) Concurrency Control (A, C, I) Backup and Recovery (A, C, D) Security (C, D)
8
Data Integrity Generally referring to accidental
introduction of inconsistencies through User error Interruption of transactions due to failure or user
request Protection provided by
Atomicity features (rollback and commit) Constraint checking (Consistency)
Either during transaction or before/after
5
9
Rollback segments in Oracle An RBS entry is a set of before images of rows that
have been modified by the transaction The transaction reads the table, other transactions
(in a concurrent setting) read the RBS
Oracle 8 Database Server
Rollback Segment Database Tables
a
b
c
d
a
b
before image updated valuesTransaction
write a
write b
read b
read d
Transaction Log Keeps track of all transactions that
update the databaseDBMS uses the information stored in a
log for: Recovery requirement triggered by a
ROLLBACK statement A program’s abnormal termination A system failure
10
6
Transaction Log
11
Data Integrity Consistent database state: All data
integrity constraints are satisfied Must begin with the database in a known
consistent state to ensure consistency Primary and foreign key constraints Check constraints More complex business rules
12
7
13
Concurrency Control Many people using database systems will
require access to the same data at the same time. Examples
Airline reservations Online add/drop Simultaneous ATM access to shared savings account eBay bidding Amazon purchases Google searching
Two or more users attempting to update some data simultaneously will conflict.
Concurrency Control Coordination of the simultaneous
transactions execution in a multiuser database system
Objective - Ensures serializability of transactions in a multiuser database environment
Involves the principle of isolation
14
8
15
Transaction Isolation Consider these transactions
Actions of T1 A: balance1 = (select balance from Customer where
accountId = 101); balance1 += 5.00; B: update Customer set balance = balance1 where
accountId = 101; Actions of T2
A: balance2 = (select balance from Customer where accountId = 101); balance2 += 10.00;
B: update Customer set balance = balance2 where accountId = 101;
16
Transaction Isolation Problems
Lost update: T1.A, T2.A, T1.B, T2.B, T1.commit, T2.commit
Uncommitted Data (“dirty read”): T1.A, T1.B, T2.A, T1.rollback, T2.B, T2.commit
Others: Inconsistent Retrievals Potential violations of C, I, D
9
Problems in Concurrency Control
• Occurs in two concurrent transactions when: • Same data element is updated• One of the updates is lost
Lost update
• Occurs when:• Two transactions are executed concurrently• First transaction is rolled back after the second transaction has
already accessed uncommitted data
Uncommitted data
• Occurs when a transaction accesses data before and after one or more other transactions finish working with such data
Inconsistent retrievals
17
18
Noninterfering Schedules Serializable
Conflict-equivalent to a serial schedule Addresses isolation (but doesn’t completely solve it) Ensures consistency
Integrity of values Goals:
maximize concurrency all schedules serializable
Testing for serializability
10
19
Noninterfering Schedules Recoverable
Another form of interference – a durabilityproblem
No rollback causes a committed transaction to rollback
If Tj reads a data item previously written by Ti, the commit operation of Ti appears before the commit operation of Tj
20
Noninterfering Schedules Cascadeless (or Strict)
No rollback causes any transaction to roll back If Tj reads a data item previously written by Ti, the
commit operation of Ti appears before the readoperation of Tj
Every strict schedule is recoverableObjective of Concurrency Control: Provide
a high degree of concurrency, while ensuring that all schedules that can be generated are serializable and cascadeless (strict).
11
21
Implementing Isolation Enforce serializable, strict schedules using
software locks Consider locks in previous schedules
Examples Issues
Types of locks Read (shared) locks Write (exclusive) locks
Explicit vs. implicit locks Implicit is lock as required by transaction ops
22
Implementing Isolation Lock granularity
What size object to lock? Table, row, field, column, whole DB
Effect on concurrency T1:Select sum(balance) from Customers T2: Update Customers set firstName=‘Joe’ where
accountId=101 Effect on size and cost
Smaller objects = more locks Releasing locks
Too early? Too late?
12
Database-Level Locking
23
Table-Level Locking
24
13
Row-Level Locking
25
26
Deadlock Two or more transactions must each
update the same, multiple pieces of data.
They each wait endlessly for the other to release the data that each has already locked.
14
27
Deadlock
28
Handling Deadlock Deadlock Prevention
Difficult to accomplish Deadlock Detection
Allow deadlock to occur Detect occurrence Roll back one of the deadlocked transactions
Alternative to deadlock is worse: Allowing inconsistent states
15
29
Starvation T2 has a shared lock on data item A T1 requests an exclusive lock on A
T1 waits T3 requests a shared lock on A
Not incompatible with T2, so granted T2 releases lock, but T3 still holds it Concurrency control manager must resolve
via some locking protocol (set of rules) Timestamps on lock requests
30
Two phase locking (2PL) Locks granted and released in two phases
Growing phase Transaction may request locks (or upgrade) May not release (or downgrade) any lock
Shrinking phase Transaction may release locks (or downgrade) May not obtain (or upgrade) any new locks
2PL guarantees serializability Any conflicting operation is blocked Serializability ordering: order by lock points
Easy to enforce Freedom from deadlock not guaranteed
16
31
Two phase locking (2PL) Freedom from cascading not guaranteed Strict 2PL
Guarantees cascadeless/strict schedules 2PL plus all write locks held until commit or rollback (Recall definition of cascadeless)
Rigorous 2PL All locks held until commit Transactions serialized by the order in which they commit
Implementation Most DBMSs use strict or rigorous 2PL No explicit request or release Release at commit or rollback
Two-Phase Locking Protocol
32
17
33
How to lock Explicit request
T1: request read on X Implicit request
T2: Select sum(balance) from Customers Explicit release
T1: release read on X Implicit release
T2: commit/rollback
34
Backup and Recovery We have to assume that from time to
time something will go wrong with our data, and so we have to have the tools available to correct or reconstruct it.
Critical to have a plan in place. E.g., local records (even on paper) in a
retail environment
18
Database Recovery Management Database recovery: Restores database
from a given state to a previously consistent state
Recovery is based on the atomicity and durability transaction properties If transaction operation cannot be completed:
Transaction must be aborted Changes to database must be rolled back
Committed transactions must remain in effect No matter what!
35
36
Causes of Failure Security breaches (Chapter 15) Catastrophic events Database server
computer crashes server program crashes disk drive corruption
Client failure computer crashes client program crashes
19
37
Causes of Failure Network failure
connection fails, often temporary Transaction failure
executes rollback (voluntary) executes illegal operation (server created) deadlock introduces errors into the database
39
Backups and Checkpoints Primary tool for supporting recovery is redundancy Backup is a copy of the state at a specific time. On a regularly scheduled basis, a company’s
databases must be backed up or copied. The backup copy must be put in a safe place, away
from the original in the computer system. Checkpoint is an incremental save of changes from
buffer to disk since a full backup (“save often”). Database can be recovered after failure:
At backup state (if disk corrupted) At checkpoint (if disk okay)
20
40
Recall: Transaction Log Track all changes that take place in the
data Updates to existing records Insertion of new records Deletion of existing records
Do not track read operations, because they do not change the data
Ideally stored in remote location No commit until log is updated
Recovery Process (if disk okay) Identify the last checkpoint in transaction log If transaction was committed before the last
checkpoint Nothing needs to be done
If transaction was committed after the last checkpoint Transaction log is used to redo the transaction
If transaction had a ROLLBACK operation after the last checkpoint (or wasn’t finished) Nothing needs to be done
42
21
Example
43
45
Backward Recovery What if the data on disk is corrupted? Rollback Suppose an error is discovered that
involves a piece of recently updated data.
The discovered error, and all other changes that were made to the database since the error was discovered, must be backed out.
22
46
Backward Recovery or Rollback Start with the database in its current state. The log is positioned at the last entry. Recovery program proceeds backwards
through the change log, resetting each updated data value in the database to its “before image,” until it reaches the point where the error was made.
May then roll forward again from the point the error occurred. Maintains durability
47
Media Failure (Secondary Storage) Roll Forward or Forward Recovery Assume a database table has been lost
No checkpoint to reference To recreate this table:
Start with the last backup copy of the table. Roll forward in the log, applying the changes that
were made to the table since the last backup in order.
Only the last change to a particular piece of data needs to be used.
23
48
Duplicate or Mirrored Databases
Two copies of the entire database are maintained, and both are updated simultaneously.
49
Advantage: If one system is destroyed, the applications that use the database can just keep on running with the duplicate database.
Disadvantage: This is a relatively expensive proposition.
Duplicate or Mirrored Databases
24
50
Disaster Recovery Rebuilding an entire information system
or significant parts of one, after a catastrophic natural disaster such as: a hurricane a tornado a earthquake a building collapse a major fire
51
Being Prepared for Disaster Recovery Maintain totally mirrored systems (not just
databases) in different cities.
Contract with a company that maintains hardware similar to yours (a hot site) so that you can be up and running again quickly after a disaster.
Build a computer center that is relatively disaster proof.
25
52
Being Prepared for Disaster Recovery Maintain space (a cold site) with
electrical connections, air conditioning, etc., into which new hardware can be moved if need be.
Make a reciprocal arrangement with another company with hardware similar to yours to aid each other in case one suffers a disaster.
Top Related