View
221
Download
0
Tags:
Embed Size (px)
Citation preview
Transaction Management and Concurre
cy OverviewR & G Chapter 16-17
There are three side effects of acid. Enhanced long term memory, decreased short term memory, and I forget the third.
- Timothy Leary
Administrivia
• Homework 3 due today by end of class period
• Homework 4 available on class website– Due date: April 10 (after Spring Break)
• Midterm 2 is next class! Thu 3/22– In class, covers lectures 10-17– Review will be held Wed 3/21 7-9 pm 306
Soda Hall
Query Compiler
query
Execution Engine Logging/Recovery
LOCK TABLE
Concurrency Control
Storage ManagerBUFFER POOLBUFFERS
Buffer Manager
Schema Manager
Data Definition
DBMS: a set of cooperating software modules
Transaction Manager
transaction
Components of a DBMS
We are here
Correctness criteria: The ACID properties
• AA tomicity: All actions in the Xact happen, or none happen.
• CC onsistency: If each Xact is consistent, and the DB starts consistent, it ends up consistent.
• II solation: Execution of one Xact is isolated from that of other Xacts.
• D D urability: If a Xact commits, its effects persist.
We are here
Review - Definitions• Transaction - a sequence of read and write operations
(read(A), write(B), …)– DBMS’s abstract view of a user program
• Serial schedule: Schedule that does not interleave the actions of different transactions.
• Equivalent schedules: For any database state, the effect of executing the first schedule is identical to the effect of executing the second schedule.
• Serializable schedule: A schedule that is equivalent to some serial execution of the transactions.
(Note: If each transaction preserves consistency, every serializable schedule preserves consistency. )
• Reading Uncommitted Data (“WR”, dirty reads):– T2 reads a value A that T1 wrote but didn’t commit– e.g: T1 moves $100 from account B to account A
T2 adds 6% interest to account A$1100 + $66 + 900 = $2066 total after T1 &
T2
Anomalies with interleaved execution
T1: R(A), W(A), R(B), W(B), AbortT2: R(A), W(A), C
A=A+100=1100A=A+100=1100
A=1100A=1100 A=1100*1.0A=1100*1.06 =11666 =1166
B=1000B=1000B=1000-100 B=1000-100 =900=900
1166+1000 = 2166 ->1166+1000 = 2166 ->Bank is out $106 Bank is out $106 because T2 read T1’s because T2 read T1’s A value before it was A value before it was done! done!
A=?A=?B=1000B=1000
A=1166A=1166B=1000B=1000
A=1000A=1000->A=1166->A=1166
• Unrepeatable Reads (“RW” Conflicts):– T1 reads a value A that is then written by T2– e.g. T1 and T2 place orders for books, and A
represents the quantity in stock (1)
Anomalies with interleaved execution
T1: R(A), R(A), W(A)T2: R(A), W(A), C
A=1A=1
A=1A=1 A=0A=0 A=0A=0
A=0A=0 A=-1A=-1Hopefully T1 gets an error if there is Hopefully T1 gets an error if there is an integrity constraint!an integrity constraint!
• Overwriting Uncommitted Data (“WW”, lost update):– T2 overwrites a write by T1– e.g. T1 assigns seat A to passenger 1 and seat B to passenger 2 T2 assigns seat A to passenger 3 and seat B to passenger 4
Anomalies with interleaved execution
T1: W(A), W(B), CT2: W(A), W(B), C
A=1A=1
A=3A=3 B=4B=4 A=3A=3B=4B=4
B=2B=2A=3A=3B=2B=2
-> Passenger 1’s partner is -> Passenger 1’s partner is sitting with passenger 3!sitting with passenger 3!
How to prevent anomalies? Locks!
• Database allows “objects” to be locked– “object” might be entire database, file,
page, tuple
• Two kinds of locks:– “Shared” or “Read” Lock
• No one else is allowed to write the object if you have this
– “Exclusive” or “Write” Lock• No one else is allowed to read or write the object
Locks are not enough
• If lock/unlock objects right away, anomalies are still possible– e.g. The unrepeatable read example
T1: R(A), R(A), W(A)T2: R(A), W(A), C
T1 obtainT1 obtainShareLock(A)ShareLock(A)
T2 obtainT2 obtainExclusiveLockL(A)ExclusiveLockL(A)
T1 release T1 release ShareLock(A)ShareLock(A)
T2 releaseT2 releaseExclusiveLock(A)ExclusiveLock(A)
T1 obtainT1 obtainShareLock(A)ShareLock(A)
Locks are not enough
• Idea: Two Phase Locking– In a transaction,
• only acquire locks in one phase• only release locks in a second phase• once one lock has been released, can never
acquire another lock during transaction
Time
#locks
T1: R(A), R(A), W(A), ….T2: R(A),W(A), C
T1 obtainT1 obtainExclusiveLock(A)ExclusiveLock(A)
T2 T2 waitswaits to obtain to obtainExclusiveLock(A)ExclusiveLock(A)
T1 release lock(A)T1 release lock(A)
T2 obtainsT2 obtainsExclusiveLock(A)ExclusiveLock(A)
Lock-Based Concurrency Control
Two-phase Locking (2PL) Protocol:– Each Xact must obtain:
• a S (shared) lock on object before reading, and • an X (exclusive) lock on object before writing.
– If an Xact holds an X lock on an object, no other Xact can get a lock (S or X) on that object.
– System can obtain these locks automatically– Two phases: acquiring locks, and releasing them
• No lock is ever acquired after one has been released• “Growing phase” followed by “shrinking phase”.
• Lock Manager keeps track of request for locks and grants locks on database objects when they become available.
Strict 2PL• 2PL allows only serializable schedules but
is subjected to cascading aborts.• Example: rollback of T1 requires rollback of T2!
• To avoid Cascading aborts, use Strict 2PL
T2 read T1’s value of T2 read T1’s value of A, so it must also be A, so it must also be aborted.aborted.
T1 obtainT1 obtainExclusiveLock(A)ExclusiveLock(A)
T1 releaseT1 releaseExclusiveLock(A)ExclusiveLock(A)
T2 obtainsT2 obtainsExclusiveLock(A)ExclusiveLock(A)
AbortT1: R(A), W(A), T2: R(A), W(A), R(B), W(B)
Strict 2PL (cont)
• Advantage: no other transaction even reads anything you write until you commit.– e.g a transaction will only read committed data.
• Disadvantage: transactions end up waiting.– e.g. inserts may lock a whole table
• Why? Because of Phantom problem
• Strict Two-phase Locking (Strict 2PL) Protocol:
– Same as 2PL, except:– All locks held by a transaction are released
only when the transaction completes
#locks
vs
The Phantom Problem
• Even Strict 2PL (on individual rows) will not assure serializability:
• Consider T1 – “Find oldest sailor with Rating = 1”
• T1 sees 2 different answers, even though it did no updates itself.
Time T1 T2
1 Obtain Share Lock on all existing Sailors with rating = 1
2 Compute oldest sailor (age = 71)
3 Obtain Exclusive Lock on new Sailor tuple
4 Insert Sailor age 96 rating 1
5 Commit
6 Compute oldest sailor (age = 96)
Transactions in SQL• A new transaction is started with first SQL
statement issued by a userSELECT S.SID, R.BIDFROM SAILORS S, RESERVES RWHERE S.SID = R.SID
• All statements from that point on appear in the same transaction
UPDATE SAILORS SET RATING = RATING - 1 UPDATE RESERVES SET DATE = DATE+1
• A user can use commands COMMIT or ROLLBACK to explicitly end a transaction and start a new one COMMIT
• Any new statements that follow will occur in a new transaction
Transactions in SQL
• Because of performance, some anomalies might be acceptable for some applications– Internet apps in particular!
• SQL 92 supports different “Isolation Levels” for a transaction (Lost Update not allowed at any level)
NoNoNoSerializable
MaybeNoNoRepeatable Reads
MaybeMaybeNoRead Committed
MaybeMaybeMaybe
Read Uncommitted
Phantom
Problem
Unrepeatable Read
DirtyRead
Isolation Level
Aborting a Transaction (i.e., Rollback)
• If an xact Ti aborted, all actions must be undone.
• To undo actions of an aborted transaction, DBMS maintains log which records every write.
• Log is also used to recover from system crashes(which can occur as either hardware or software
failure)– All active Xacts at time of crash are aborted when
system comes back up.
The Database Log
XID 1:XID 1:REDO TID 1 <data>REDO TID 1 <data>REDO TID 2 <data>REDO TID 2 <data>COMMITCOMMITXID 2:XID 2:REDO TID 3 <data>REDO TID 3 <data>……
BufferBuffer
Data PageData Page Data PageData Page LogLog
Data PagesData Pages LogLog
• Updates are logged in the database log.
• Log consists of “records” that are written sequentially.– Typically chained together by
Xact id– Log is often archived on stable
storage.– And backed up to even more
stable storage (like tape!)
The Database Log• Write-Ahead Logging protocol
– Log record must go to disk before the changed page!
– All log records for a transaction (including its commit record) must be written to disk before the transaction is considered “Committed”.
XID 1:XID 1:REDO TID 1 <data>REDO TID 1 <data>REDO TID 2 <data>REDO TID 2 <data>COMMITCOMMITXID 2:XID 2:REDO TID 3 <data>REDO TID 3 <data>……
BufferBuffer
Data PageData Page Data PageData Page LogLog
Data PagesData Pages LogLog
Update TID 1 <data>Update TID 1 <data>Update TID 2 <data>Update TID 2 <data>
1122
33SQL: COMMIT XID1SQL: COMMIT XID1
The Log
• Log records are either UNDO or REDO records– Depends on the Buffer manager
• UNDO required if: Buffer mgr allows uncommitted data to overwrite stable version of committed data (STEAL buffer management).
• REDO required if: xact can commit before all its updates are on disk (NO FORCE buffer management).
• The following actions are recorded in the log:– if Ti writes an object, write a log record with:
• If UNDO required need “before image”• IF REDO required need “after image”.
– Ti commits/aborts: a log record indicating this action.
How Professor Roth made some traders very unhappy at market open…
XID 1:XID 1:REDO TID 1 <data>REDO TID 1 <data>REDO TID 2 <data>REDO TID 2 <data>COMMITCOMMITXID 2:XID 2:REDO TID 3 <data>REDO TID 3 <data>……
LogLog
Log2Log2
• Log on disk can fill up quickly for active DBMS
• DBMS duplexes between two logs– Writes DB log to one – While archiving the other– When DB log is full, reverse
• Must STOP all DBMS activity while you reverse Log1Log1 LogLog
How Professor Roth made some traders very unhappy at market open…
XID 1:XID 1:REDO TID 1 <data>REDO TID 1 <data>REDO TID 2 <data>REDO TID 2 <data>COMMITCOMMITXID 2:XID 2:REDO TID 3 <data>REDO TID 3 <data>……
LogLog
Log2Log2
• Stock DB at market open is VERY busy
• We wanted to make sure there was an empty log just before market open
• I wrote a script to ‘switch’ logs 5 mins before market open
If (not already writing a log)
Then switch logs
Write the old log to tape• Except I forgot a comma, so it
was more like this:
Switch logs; write the old log to tape
...and because the DB was writing out its log, the DB hung until it was done writing to tape!
Log1Log1
I’m waitingI’m waiting……
(Review) Goal: The ACID properties
• AA tomicity: All actions in the Xact happen, or none happen.
• CC onsistency: If each Xact is consistent, and the DB starts consistent, it ends up consistent.
• II solation: Execution of one Xact is isolated from that of other Xacts.
• D D urability: If a Xact commits, its effects persist.
What happens if system crashes between commit and flushing modified data to disk ?
Durability - Recovering From a Crash
• Three phases:– Analysis: Scan the log (forward from the most
recent checkpoint) to identify all Xacts that were active at the time of the crash.
– Redo: Redo updates as needed to ensure that all logged updates are in fact carried out and written to disk.
– Undo: Undo writes of all Xacts that were active at the crash, working backwards in the log.
• At the end – all committed updates and only those updates are reflected in the database.
• Some care must be taken to handle the case of a crash occurring during the recovery process!
DD
Summary
• Concurrency control and recovery are among the most important functions provided by a DBMS.
• Concurrency control is automatic– System automatically inserts lock/unlock requests
and schedules actions of different Xacts– Property ensured: resulting execution is equivalent to
executing the Xacts one after the other in some order.
• Write-ahead logging (WAL) and the recovery protocol are used to:1. undo the actions of aborted transactions, and 2. restore the system to a consistent state after a
crash.