COP 5725 Fall 2012 Database Management Systems

  COP 5725 Fall 2012 Database Management Systems

  University of Florida, CISE Department _{Prof. Daisy Zhe Wang} Adapted Slides from Prof. Jeff Ullman ₁ Transaction Management Overview

  Transaction & ACID Schedules

  Isolation Levels

  2 Transactions

• A transaction is the DBMS’s abstract view of a user program: a sequence of reads and writes.
• A user’s program may carry out many operations on the data retrieved from the database, but the DBMS is only concerned about what data is read/written from/to the database.
• of user programs is essential for

  Concurrent execution good DBMS performance.

  Because disk accesses are frequent, and relatively slow, it is – important to keep the cpu humming by working on several user programs concurrently. Saga transactions vs. short transactions

• –

  ACID Transactions

• A DBMS is expected to support “

  ACID transactions ,” processes that are:

• – : Either the whole process is done or

  Atomic none is.

• – : Database constraints are

  Consistent preserved.

• – : It appears to the user as if only one

  Isolated process executes at a time.

• – : Effects of a process do not get lost if

  Durable the system crashes.

  Concurrency in a DBMS

• Users submit transactions, and can think of each transaction as executing by itself.
• – actions (reads/writes of DB objects) of various transactions. Each transaction must leave the database in a consistent

  Concurrency is achieved by the DBMS, which interleaves

• – state if the DB is consistent when the transaction begins.

• • DBMS will enforce some ICs, depending on the ICs declared in

  _{CREATE TABLE statements.}
• Beyond this, the DBMS does not really understand the semantics of _{account is computed). the data. (e.g., it does not understand how the interest on a bank}
• Effect of transactions, and

  Issues: interleaving . crashes/aborts

  Atomicity of Transactions

• A transaction might commit after completing all its actions, or it could (or be aborted by

  abort the DBMS) after executing some actions.

• A very important property guaranteed by the

  DBMS for all transactions is that they are

  

atomic . That is, a user can think of a Xact as

  always executing all its actions in one step, or not executing any actions at all.

• – DBMS logs all actions so that it can undo the actions of aborted transactions.

  Example

• Consider two transactions ( Xacts ):

  T1: BEGIN A=A+100, B=B-100 END T2: BEGIN A=1.06*A, B=1.06*B END 

  Intuitively, the first transaction is transferring $100 from B’s account to A’s account. The second is crediting both accounts with a 6% interest payment.

  

  There is no guarantee that T1 will execute before T2 or vice-versa, if both are submitted together. However, the net effect must be equivalent to these two transactions running serially in some order.

  Example (Contd.)

• Consider a possible interleaving ( schedule ) :

  T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B 

  This is OK. But what about:

  T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B

  

The DBMS’s view of the second schedule:

  R(B), W(B) T2: R(A), W(A), R(B), W(B) Scheduling Transactions

• Schedule that does not interleave the

  Serial schedule: actions of different transactions.

• : For any database state, the

  Equivalent schedules

  effect (on the set of objects in the database) of executing the first schedule is identical to the effect of executing the second schedule.

• : A schedule that is equivalent to

  Serializable schedule some serial execution of the transactions.

  (Note: If each transaction preserves consistency, every serializable schedule preserves consistency. )

  Anomalies with Interleaved Execution

• Reading Uncommitted Data (WR

  Conflicts, “dirty reads”):

  T1: R(A), W(A), R(B), W(B), Abort T2: R(A), W(A), C

• Unrepeatable Reads (RW Conflicts):

  T1: R(A), R(A), W(A), C T2: R(A), W(A), C

  Anomalies (Continued)

• Overwriting Uncommitted Data (WW

  Conflicts):

  T1: W(A), W(B), C T2: W(A), W(B), C

  Lock-Based Concurrency Control

• Strict Two-phase Locking (Strict 2PL) Protocol :
• – reading, and an X ( ) lock on object before writing.

  Each Xact must obtain a S ( ) lock on object before shared

  exclusive All locks held by a transaction are released when the

• – transaction completes _{(Non-strict) 2PL Variant : Release locks anytime, but cannot acquire locks after releasing any lock. •} If an Xact holds an X lock on an object, no other Xact can
• – get a lock (S or X) on that object.
• Strict 2PL allows only serializable schedules.
• – Additionally, it simplifies transaction aborts
• – (Non-strict) 2PL also allows only serializable schedules, but

  involves more complex abort processing

  Aborting a Transaction

  is aborted, all its actions have to be

• If a transaction Ti undone. Not only that, if Tj reads an object last written by , must be aborted as well!

  Ti Tj

• Most systems avoid such cascading aborts by releasing a transaction’s locks only at commit time.
• – If writes an object, can read this only after commits.

  Ti Tj Ti

  the actions of an aborted

• In order to undo transaction, the DBMS maintains a log in which every write is recorded.
• This mechanism is also used to recover from system crashes: all active Xacts at the time of the crash are

  The Log

• The following actions are recorded in the log: : the old value and the new value.

  Ti writes an object

• – • Log record must go to disk before the changed page! : a log record indicating this action.

  Ti commits/aborts

• – • Log records are chained together by Xact id, so it’s easy to undo a specific Xact.

  and on stable storage.

• Log is often duplexed archived
• All log related activities (and in fact, all CC related activities such as lock/unlock, dealing with deadlocks etc.) are handled transparently by the DBMS.

  Recovering From a Crash

  recovery algorithm:

• There are 3 phases in the Aries
• – ) to identify all Xacts that were active, and all

  : Scan the log forward (from the most recent Analysis

  checkpoint dirty pages in the buffer pool at the time of the crash.

• – : Redoes all updates to dirty pages in the buffer pool,

  Redo

as needed, to ensure that all logged updates are in fact

carried out and written to disk.

• – are undone (by restoring the of the update,

  : The writes of all Xacts that were active at the crash Undo

  before value which is in the log record for the update), working backwards in the log. (Some care must be taken to handle the case of a crash occurring during the recovery process!) Summary

• Concurrency control and recovery are among the most important functions provided by a DBMS.
• Users need not worry about concurrency.
• –

  schedules actions of different Xacts in such a way as to

  ensure that the resulting execution is equivalent to

  executing the Xacts one after the other in some order.

  System automatically inserts lock/unlock requests and

• Write-ahead logging (WAL) is used to undo the actions of aborted transactions and to restore the system to a consistent state after a crash.

  : Only the effects of commited Xacts seen.

  Consistent state

• –

  Transactions in SQL

• SQL supports transactions, often behind the scenes.
• – Each statement issued at the generic query interface is a transaction by itself.
• – In programming interfaces like Embedded SQL or PSM, a transaction begins the first time a SQL statement is executed and ends with the program or an explicit transaction- end.

• The SQL statement COMMIT causes a transaction to complete.
• – It’s database modifications are now permanent in the database.

  18 COMMIT ROLLBACK

• The SQL statement ROLLBACK also causes the transaction to end, but by aborting .
• – No effects on the database.
• Failures like division by 0 or a constraint violation can also cause rollback, even if the programmer does not request it.
₁₉

  An Example: Interacting Processes

• Assume the usual Sells(bar,beer,price) relation, and suppose that Joe’s Bar sells only Bud for $2.50 and Miller for $3.00.
• Sally is querying Sells for the highest and lowest price Joe charges.
• Joe decides to stop selling Bud and Miller, but to sell only Heineken at $3.50.

  20 Sally’s Program

• Sally executes the following two SQL statements, which we call (min) and (max) , to help remember what they do.

  

(max) SELECT MAX(price) FROM Sells

  WHERE bar = ’Joe’’s Bar’;

  (min) SELECT MIN(price) FROM Sells

  WHERE bar = ’Joe’’s Bar’;

  21 Joe’s Program

• At about the same time, Joe executes the following steps, which have the mnemonic names (del) and (ins) .

  (del) DELETE FROM Sells

  WHERE bar = ’Joe’’s Bar’;

  (ins)

  INSERT INTO Sells

  VALUES(’Joe’’s Bar’, ’Heineken’, 3.50);

  22 Interleaving of Statements

• Although (max) must come before

  (min) , and (del) must come before (ins) , there are no other constraints on

  the order of these statements, unless we group Sally’s and/or Joe’s statements into transactions.

  23 Example: Strange Interleaving

• Suppose the steps execute in the order (max)(del)(ins)(min) .

  Joe’s Prices:

  2.50, 3.00 2.50, 3.00

  3.50 Statement: (max) (del) (ins) (min)

  Result:

  3.00

  3.50

• Sally sees MAX < MIN!

  24

  

Fixing the Problem by Using Transactions

• If we group Sally’s statements

  (max)(min) into one transaction, then she cannot see this inconsistency.

• She sees Joe’s prices at some fixed time.
• – Either before or after he changes prices, or in the middle, but the MAX and MIN are computed from the same prices.

  25 Another Problem: Rollback

• Suppose Joe executes (del)(ins) , not as a transaction, but after executing these statements, thinks better of it and issues a ROLLBACK statement.
• If Sally executes her statements after

  (ins) but before the rollback, she sees a

  value, 3.50, that never existed in the database. ₂₆

  Solution

• If Joe executes (del)(ins) as a transaction, its effect cannot be seen by others until the transaction executes COMMIT.
• – If the transaction executes ROLLBACK instead, then its effects can be

  never seen.

  27 Isolation Levels

• SQL defines four isolation levels = choices about what interactions are allowed by transactions that execute at about the same time.
• How a DBMS implements these isolation levels is highly complex, and a typical DBMS provides its own options.

  28 Choosing the Isolation Level

• Within a transaction, we can say: SET TRANSACTION ISOLATION LEVEL

  X

  where =

  X

  1. SERIALIZABLE

  2. REPEATABLE READ

  3. READ COMMITTED

  4. READ UNCOMMITTED

  29 Serializable Transactions (max)(min) and Joe = (del)(ins)

• If Sally = are each transactions, and Sally runs with isolation level SERIALIZABLE, then she will see the database either before or after Joe runs, but not in the middle.
• It’s up to the DBMS vendor to figure out how to do that, e.g.: – True isolation in time.
• – Keep Joe’s old prices around to answer Sally’s queries.
₃₀
Isolation Level Is Personal Choice

• Your choice, e.g., run serializable, affects only how see the database,

  you not how others see it.

• Example : If Joe Runs serializable, but

Sally doesn’t, then Sally might see no prices for Joe’s Bar

• – i.e., it looks to Sally as if she ran in the middle of Joe’s transaction.
₃₁

  Read-Commited Transactions

• If Sally runs with isolation level READ

  COMMITTED, then she can see only committed data, but not necessarily the same data each time.

• Example: Under READ COMMITTED, the interleaving (max)(del)(ins)(min) is allowed, as long as Joe commits.
• – Sally sees MAX < MIN.

  32 Repeatable-Read Transactions

• Requirement is like read-committed, plus: if data is read again, then everything seen the first time will be seen the second time.
• – But the second and subsequent reads may see tuples as well.

  more

  33

• Suppose Sally runs under REPEATABLE
• – (max) sees prices 2.50 and 3.00.
• – (min)

  34 Example: Repeatable Read

  READ, and the order of execution is (max)(del)(ins)(min) .

  can see 3.50, but must also see 2.50 and 3.00, because they were seen on the earlier read by (max) . Read Uncommitted

• A transaction running under READ

  UNCOMMITTED can see data in the database, even if it was written by a transaction that has not committed (and may never).

• Example: If Sally runs under READ

  UNCOMMITTED, she could see a price 3.50 even if Joe later aborts.

  35