1

IRU Concurrency, Reliability and

Integrity issuesGeoff Leese October 2007

updated August 2008, October 2009

2

Introduction

The concept of a transaction Handling concurrent access Database reliability Ensuring integrity

3

A transaction Unit of database work Support concurrency control and crash

recovery Atomic

All actions carried out, or none Consistent

Data always left in a consistent state Isolated

Database handles concurrency issues Durable

Completed transactions persist even if database not updated

4

Concurrency control

How do we handle Lost operations? Inconsistent data retrieval?

5

Lost operations example

Two transactions operating concurrently Update stock, product abc123,

adding 20 Update stock, product abc123,

adding 50 Current stock level of product

abc123 is 100

6

Lost operations example

ADD 50 TO STOCK LEVEL

TIMETRANSACTION 1 TRANSACTION 2

READ IN RECORD FOR ABC123 READ IN RECORD

FOR ABC123

ADD 20 TO STOCK LEVEL

WRITE RECORD BACK

WRITE RECORD BACK

BECAUSE OF THE TIMINGS, TRANSACTION 2 IS LOST!

7

Inconsistent data retrieval example

Two transactions, operating concurrently Give me details of product

abc123, then a summary of the group of products containing product abc123

Update stock, product abc123, adding 50

8

Inconsistent data retrieval example

TIMETRANSACTION 1 TRANSACTION 2

READ IN RECORD FOR ABC123 READ IN RECORD

FOR ABC123SHOW PRODUCT DETAILS

SHOW GROUP SUMMARY

WRITE RECORD BACK

ADD 50 TO STOCK

BECAUSE OF TIMINGS, GROUP SUMMARY DOESN’T MATCH DETAILS FOR ABC123!

9

INCONSISTENT DATA RETRIEVAL EXAMPLE

TIMETRANSACTION 1 TRANSACTION 2

READ IN RECORD FOR ABC123

READ IN RECORD FOR ABC123

SHOW PRODUCT DETAILS

SHOW GROUP SUMMARY

ADD 50 TO STOCK

TRANSACTION 1 IS NOW SELF-CONSISTENT, BUT DETAILS ARE BASED ON AN ABORTED TRANSACTION!

ROLLBACK

10

Serialisable transactions

Allow transactions to run concurrently, but have the effect of executing one at a time

If read access required, stop concurrent changes

If write/modify access required, stop all concurrent access

11

Shared/exclusive locking

Shared locking - allows other transactions to read data, but transactions requiring to update have to wait

Exclusive locking - applied during updates, all other transactions must wait

12

Rules for locking

Shared locks applied as soon as exclusive locks removed

Exclusive locks applied as soon as all other locks removed

Locks removed following commit/rollback

Locks applied at record or page level

13

TIMETRANSACTION 1 TRANSACTION 2

APPLY EXCLUSIVE LOCK TO X

APPLY EXCLUSIVE LOCK TO Y

REQUEST EXCLUSIVE LOCK ON Y

REQUEST EXCLUSIVE LOCK ON X

BOTH TRANSACTIONS ARE DEADLOCKED!

DEADLOCK EXAMPLETwo transactions, both update data object x and data object y

14

Pessimistic locking

All possible data objects required by a transaction are locked when transaction begins

Therefore avoids deadlock Data locked for full duration of

transaction, whether required or not!

15

Optimistic locking

Allows deadlocks to occur Identifies them and aborts

victim transactions Significant performance delay

due to repeated deadlock/rollback/restart cycle

16

Reliability (DBMS facilities)

Commit Make permanent changes

Rollback Return to previous values

Transaction logging Checkpoints)

BIJ – before image journal AIJ – after image journal

17

Disaster recovery (1) System crash/media failure Transaction log is assumed to

survive the crash (mirror it elsewhere?)

Restore backup copies They were kept offsite??)

18

Disaster recovery(2)

Recovery manager ANALYSE uncommitted and active

transactions REDO uncommitted transactions UNDO incomplete transaction REPORT what has been done

UPDATE transaction log during recovery Use checkpoints to reduce workload

should system crash again before recovery complete

19

Physical reliability measures

Network redundancy Covered in other modules

Distributed database technology Ensures some survivability

Regular backups kept offsite Including backups of transaction files

Mirror sites for maximum survivability Only worthwhile for mission critical

systems Update propagation is obviously an issue

20

Integrity

Ensuring “correctness”? Only really ensuring

consistency – “correctness” is a user concept connected with meaning!

21

Constraints

Type constraints Built-in User defined

Attribute constraints Entity constraints

Involves only one entity Database constraint

Involves two or more entities

22

Type constraints

Built in types CHAR, NUMBER, DATE etc

User defined types Constructed from built-in types

Choose or construct an appropriate type for all attributes!

23

Attribute constraints

At least partially met by use of TYPE constraints.

Consider also Maximum and minimum values Uniqueness? Nulls allowed?

ORACLE attribute constraints (exist as objects) CHECK UNIQUE NOT NULL

24

Entity constraints

Primary key ORACLE primary key constraint

Alternate key(s) Transition constraints

Student can become a binned student, but not the reverse……. (not here anyway!)

25

Database constraints

Foreign key ORACLE Foreign key constraint)

Referential integrity DELETE actions

– Restrict (default)– Set null– Cascade

UPDATE action– Cascade

Use “ON DELETE” clause when specifying FK constraint

Use “REFERENCES” clause when specifying FK constraint

26

Summary

The concept of a transaction Handling concurrent access Database reliability Ensuring integrity

27

Further reading

Rolland chapter 9 Date chapters 9, 15 and 16 Patrick chapters 6, 8 and 19 A bloggers view of database in

tegrity – click to follow the link