1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009

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

3 A transaction n Unit of database work n Support concurrency control and crash recovery n Atomic ä All actions carried out, or none n Consistent ä Data always left in a consistent state n Isolated ä Database handles concurrency issues n Durable ä Completed transactions persist even if database not updated

4 Concurrency control n How do we handle ä Lost operations? ä Inconsistent data retrieval?

5 Lost operations example n Two transactions operating concurrently ä Update stock, product abc123, adding 20 ä Update stock, product abc123, adding 50 n Current stock level of product abc123 is 100

6 Lost operations example ADD 50 TO STOCK LEVEL TIME TRANSACTION 1TRANSACTION 2 READ IN RECORD FOR ABC123 READ IN RECORD FOR ABC123 ADD 20 TO STOCK LEVEL WRITE RECORD BACK BECAUSE OF THE TIMINGS, TRANSACTION 2 IS LOST!

7 Inconsistent data retrieval example n 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 TIME TRANSACTION 1TRANSACTION 2 READ IN RECORD FOR ABC123 READ IN RECORD FOR ABC123 SHOW 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 TIME TRANSACTION 1TRANSACTION 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 n Allow transactions to run concurrently, but have the effect of executing one at a time n If read access required, stop concurrent changes n If write/modify access required, stop all concurrent access

11 Shared/exclusive locking n Shared locking - allows other transactions to read data, but transactions requiring to update have to wait n Exclusive locking - applied during updates, all other transactions must wait

12 Rules for locking n Shared locks applied as soon as exclusive locks removed n Exclusive locks applied as soon as all other locks removed n Locks removed following commit/rollback n Locks applied at record or page level

13 TIME TRANSACTION 1TRANSACTION 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 EXAMPLE Two transactions, both update data object x and data object y

14 Pessimistic locking n All possible data objects required by a transaction are locked when transaction begins n Therefore avoids deadlock n Data locked for full duration of transaction, whether required or not!

15 Optimistic locking n Allows deadlocks to occur n Identifies them and aborts victim transactions n Significant performance delay due to repeated deadlock/rollback/restart cycle

16 Reliability (DBMS facilities) n Commit ä Make permanent changes n Rollback ä Return to previous values n Transaction logging ä Checkpoints) n BIJ – before image journal n AIJ – after image journal

17 Disaster recovery (1) n System crash/media failure n Transaction log is assumed to survive the crash (mirror it elsewhere?) n Restore backup copies ä They were kept offsite??)

18 Disaster recovery(2) n Recovery manager ä ANALYSE uncommitted and active transactions ä REDO uncommitted transactions ä UNDO incomplete transaction ä REPORT what has been done n UPDATE transaction log during recovery n Use checkpoints to reduce workload should system crash again before recovery complete

19 Physical reliability measures n Network redundancy ä Covered in other modules n Distributed database technology ä Ensures some survivability n Regular backups kept offsite ä Including backups of transaction files n Mirror sites for maximum survivability ä Only worthwhile for mission critical systems ä Update propagation is obviously an issue

20 Integrity n Ensuring “correctness”? n Only really ensuring consistency – “correctness” is a user concept connected with meaning!

21 Constraints n Type constraints ä Built-in ä User defined n Attribute constraints n Entity constraints ä Involves only one entity n Database constraint ä Involves two or more entities

22 Type constraints n Built in types ä CHAR, NUMBER, DATE etc n User defined types ä Constructed from built-in types n Choose or construct an appropriate type for all attributes!

23 Attribute constraints n At least partially met by use of TYPE constraints. n Consider also ä Maximum and minimum values ä Uniqueness? Nulls allowed? n ORACLE attribute constraints (exist as objects) ä CHECK ä UNIQUE ä NOT NULL

24 Entity constraints n Primary key ä ORACLE primary key constraint n Alternate key(s) n Transition constraints ä Student can become a binned student, but not the reverse……. (not here anyway!)

25 Database constraints n Foreign key ä ORACLE Foreign key constraint) n 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 n The concept of a transaction n Handling concurrent access n Database reliability n Ensuring integrity

27 Further reading n Rolland chapter 9 n Date chapters 9, 15 and 16 n Patrick chapters 6, 8 and 19 n A bloggers view of database integrity – click to follow the link A bloggers view of database integrity – click to follow the link