1 iru concurrency, reliability and integrity issues geoff leese october 2007 updated august 2008,...
TRANSCRIPT
![Page 1: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/1.jpg)
1
IRU Concurrency, Reliability and
Integrity issuesGeoff Leese October 2007
updated August 2008, October 2009
![Page 2: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/2.jpg)
2
Introduction
The concept of a transaction Handling concurrent access Database reliability Ensuring integrity
![Page 3: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/3.jpg)
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
![Page 4: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/4.jpg)
4
Concurrency control
How do we handle Lost operations? Inconsistent data retrieval?
![Page 5: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/5.jpg)
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
![Page 6: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/6.jpg)
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!
![Page 7: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/7.jpg)
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
![Page 8: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/8.jpg)
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!
![Page 9: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/9.jpg)
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
![Page 10: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/10.jpg)
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
![Page 11: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/11.jpg)
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
![Page 12: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/12.jpg)
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
![Page 13: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/13.jpg)
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
![Page 14: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/14.jpg)
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!
![Page 15: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/15.jpg)
15
Optimistic locking
Allows deadlocks to occur Identifies them and aborts
victim transactions Significant performance delay
due to repeated deadlock/rollback/restart cycle
![Page 16: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/16.jpg)
16
Reliability (DBMS facilities)
Commit Make permanent changes
Rollback Return to previous values
Transaction logging Checkpoints)
BIJ – before image journal AIJ – after image journal
![Page 17: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/17.jpg)
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??)
![Page 18: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/18.jpg)
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
![Page 19: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/19.jpg)
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
![Page 20: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/20.jpg)
20
Integrity
Ensuring “correctness”? Only really ensuring
consistency – “correctness” is a user concept connected with meaning!
![Page 21: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/21.jpg)
21
Constraints
Type constraints Built-in User defined
Attribute constraints Entity constraints
Involves only one entity Database constraint
Involves two or more entities
![Page 22: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/22.jpg)
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!
![Page 23: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/23.jpg)
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
![Page 24: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/24.jpg)
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!)
![Page 25: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/25.jpg)
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
![Page 26: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/26.jpg)
26
Summary
The concept of a transaction Handling concurrent access Database reliability Ensuring integrity
![Page 27: 1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009](https://reader035.vdocuments.site/reader035/viewer/2022070410/56649ef05503460f94c0072b/html5/thumbnails/27.jpg)
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