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.