1 iru concurrency, reliability and integrity issues geoff leese october 2007 updated august 2008,...
Post on 13-Jan-2016
215 Views
Preview:
TRANSCRIPT
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
top related