data concurrency, consistency and integrity
DESCRIPTION
Data Concurrency, Consistency and Integrity. My goals. Managing Data Keep it valid Let people access it Start from simple models Build more complex ones High-Level Abstraction Oracle implementation No Code. You. Programming Databases Concurrency SQL Oracle. A Simple Model. Read - PowerPoint PPT PresentationTRANSCRIPT
Giovanni Chierico | May 2012 | Дубна
Data Concurrency, Consistency and Integrity
Giovanni Chierico | May 2012 | Дубна
My goals
•Managing Data• Keep it valid• Let people access it
• Start from simple models• Build more complex ones• High-Level Abstraction•Oracle implementation•No Code
2
Giovanni Chierico | May 2012 | Дубна
You
• Programming• Databases• Concurrency• SQL• Oracle
3
Giovanni Chierico | May 2012 | Дубна
A Simple Model
Processor
Memory
Read Write
1.Read2.Process3.Write4.Read5.Process6.Write7.…
4
Giovanni Chierico | May 2012 | Дубна
Increase a counter: Single User
1
1+1 2⇒
Time2 2
2+1 3⇒
3
5
Giovanni Chierico | May 2012 | Дубна
Increase a counter: Multi User
1
1+1 2⇒
Time1 2 2
1+1 2⇒
6
Giovanni Chierico | May 2012 | Дубна
Increase a counter: Multi User
1
1+1 2⇒
Time1 2
1+1 2⇒
2 3 2
2+1 3⇒
7
Giovanni Chierico | May 2012 | Дубна
Locking
1
1+1 2⇒
Time1 2 2
1+1 2⇒
ReadLock
WriteLock
8
Giovanni Chierico | May 2012 | Дубна
Concurrency
Data Concurrency means that many users can access data at the same time
Locks limit concurrency
9
Giovanni Chierico | May 2012 | Дубна
Transfer Funds: Consistency
A:100€B:100€
Transfer 50€: (100,100) (50,150)⇒
A:50€B:100€
A:50€B:150€
T:200€ T:200€T:150€
10
Giovanni Chierico | May 2012 | Дубна
Transaction
A transaction comprises a unit of work treated in a coherent and reliable way independent of other transactions.
11
Giovanni Chierico | May 2012 | Дубна
Transfer Funds: Failures
A:100€B:100€
Transfer 50€: (100,100) (50,150)⇒
A:50€B:100€
Anything can go wrong at any time
12
Giovanni Chierico | May 2012 | Дубна
Transaction Properties
•Atomicity (all or nothing)
•Consistency (From Valid to Valid)
•Isolation (No interference)
•Durability (Changes are reliably persisted)
ACID13
Giovanni Chierico | May 2012 | Дубна
Commit
1
1+1 2⇒
2
1 1 2
Transaction#1
Transaction#2
Commit
Multiple versions must be kept14
Giovanni Chierico | May 2012 | Дубна
Transfer Funds: Commit
A:100€B:100€
Transfer 50€
A:50€B:100€
A:50€B:150€
T:200€ T:200€ T:200€
Commit
T#1
T#2
15
Giovanni Chierico | May 2012 | Дубна
Transfer Funds: Rollback
A:100€B:100€
Transfer 50€
A:50€B:100€
A:100€B:100€
Rollback
Automatic or user initiated
16
Giovanni Chierico | May 2012 | Дубна
Transaction Isolation LevelsRead Phenomena
• Dirty Reads: read uncommitted data of another transaction
• Nonrepeatable & Phantom Reads: read changes committed by another transaction
Oracle Isolation Lvl Dirty Reads Nonrep & Phantom
Read Committed NO YES
Serializable NO NO
17
Giovanni Chierico | May 2012 | Дубна
Oracle Read Consistency
Statement-Level Read Consistency is always guaranteed
Session-Level Read Consistency is guaranteed in only serializable mode
18
Giovanni Chierico | May 2012 | Дубна
Oracle Read Consistency
A:50€B:150€
Transfer 50€
T#1
T#2
A:100€ B:100 or 150€?
Same read 100€⇒
Multiple reads• Read committed 150€⇒• Serializable 100€⇒
Same read?
A:100€B:100€
19
Giovanni Chierico | May 2012 | Дубна
Multiversion Concurrency ControlSystem Change Number (SCN): the Oracle database “clock”, incremented at every insert, update, delete.
A 1 2 14
B 1 10 11 18 19
C 1 3 5
D 1 4 9 17
E 1 8 12
F 1 6 13 16
G 1 7 15
A query made at (SCN) time T return the most recent (highest SCN) records whose SCN is less or equal to T
Read SCN = 1Read SCN = 10
Readers never block WritersWriters never block Readers
*except when they do
*
20
Giovanni Chierico | May 2012 | Дубна
Updates: LocksWrite 1
1
T#1
T#2
Commit
Write 2
2
CommitWait
21
Giovanni Chierico | May 2012 | Дубна
Locks: Implicit Vs Explicit
• Implicit Locks• Automatic for every operation• Locks as little as possible for highest
concurrency
• Explicit Locking• transaction-level read consistency
(repeatable reads)• Cannot afford to wait once it has started
22
Giovanni Chierico | May 2012 | Дубна
Increase a Counter
1.Read
2.Compute
3.Update
4.Commit
1.Read
2.Compute
3.Update
4.Commit
Wait
1
1
2
2
1
2
2
23
Giovanni Chierico | May 2012 | Дубна
Increase a Counter
1.Lock2.Read 3.Compute4.Update5.Commit
1.Lock
2.Read 3.Compute4.Update5. Commit
Wait
1
1
22
2
33
24
Giovanni Chierico | May 2012 | Дубна
Optimistic Locking1. Read Value & Version
2. Compute
3. Lock
4. Check if version changed. If no (1=1) then
5. Update Value & Version
6. Commit
A|1
1. Read Value & Version
2. Compute
3. Lock4. Check version ⇒ Exception
B|2
B
A|1A|1
C
25
Giovanni Chierico | May 2012 | Дубна
Deadlocks
Transaction #2
Update B
Update A
Transaction #1
Update A
Update BWait #2Wait #1
Deadlock!
Avoid by always locking in the same order.
26
Giovanni Chierico | May 2012 | Дубна
Data IntegrityEnforce Business Rules
Player• have a last name• have age > 0• have a unique login name• belong to a team (reference)
27
Giovanni Chierico | May 2012 | Дубна
Unique Constraint
• Insert new player with login “chierico”• Check that no other “chierico” exists• Insert new “chierico” record• Make sure no one insert it between your
“check” and your “insert” ⇒1. Lock whole table Bad for Concurrency⇒2. Check3. Insert4. Commit
DBs offer a proper “unique” constraint.
28
Giovanni Chierico | May 2012 | Дубна
Lessons Learned
• Always think about how others might use the data• No “one solution fits all”• Databases offer valuable abstractions• Flexible• Safe• Declarative
• Not all databases behave the same way
29
Giovanni Chierico | May 2012 | Дубна
Q&A
30
Giovanni Chierico | May 2012 | Дубна
спасибо
Globe of Science and Innovation, CERN
31
Giovanni Chierico | May 2012 | Дубна 32
Giovanni Chierico | May 2012 | Дубна 33
Giovanni Chierico | May 2012 | Дубна 34
Giovanni Chierico | May 2012 | Дубна 35