Upload
sydney-davidson
View
237
Download
0
Tags:
Embed Size (px)
Citation preview
Quick revision on Transaction Processing
Concepts
By:Dr. Yousry Taha
Copyright 2010
IS 533 - Transactions 2
Intoduction
– The concept of transaction : • provides a mechanism for describing logical units of
database processing.
– Transaction processing systems : • systems with large databases and hundreds of
concurrent users that are executing database transactions.
IS 533 - Transactions 3
Singile user Versus Multiuser Systems
• Single-User : at most one user at a time can use the system
• Multiuser : many users can use the system concurrently.
• Multiprogramming : allows the computer to execute multiple programs at the same time.
• Interleaving : keeps the CPU busy when a process requires an input or output operation, the CPU switched to execute another process rather than remaining idle during I/O time .
• Most of the theory concerning concurrency control in databases is developed in terms of interleaved concurrency.
IS 533 - Transactions 4
Transactions, Read and Write Operations, and
DBMS Buffers
• A Transaction : is a logical unit of database processing that includes one or more database access operation.
• All database access operations between Begin Transaction and End Transaction statements are considered one logical transaction.
• If the database operations in a transaction do not update the database but only retrieve data , the transaction is called a read-only transaction.
• Basic database access operations :– read_item(X) : reads a database item X into program variable.– Write_item(X) : Writes the value of program variable X into the database item X.
IS 533 - Transactions 5
Why Concurrency Control is needed
• Several problems can occur when concurrent transactions execute in an uncontrolled manner.
1. The Lost Update Problem :
T1 T2
Read_item(X);X=:X-N;
TimeRead_item(X);X=:X+M;
Write_item(X); Read_item(Y);Y=:Y+N; Write_item(X);
Item X has incorrect value
Write_item(Y);
IS 533 - Transactions 6
Why Concurrency Control is needed (continued)
2. The temporary Update (or Dirty read) problem
T1 T2
Read_item(X);X=:X-N;write_item(X);
TimeRead_item(X);X=:X+M;write_item(X);read_item(Y);
T1 fails and must rollback, meanwhile T2 has read the temporary value
IS 533 - Transactions 7
Why Concurrency Control is needed (continued)
3. The Incorrect Summary Problem
4. Unrepeatable Read problem: A transaction reads items twice with two different values because it was changed by another transaction between the two reads.
T1 T3
Read_item(X);X=:X-N;write_item(X);
TimeRead_item(X);sum:=sum+x;read_item(Y);sum:=sum+Y;
read_item(Y);Y:=Y+N;write_item(Y);
T3 reads X after N is subtracted and reads Y before N is added;
Sum:=0;Read_item(A);sum:=sum+A;
.
.
.
IS 533 - Transactions 8
Why Recovery Is Needed
• There several possible reasons for a transaction to fail– A computer failure : A hardware, software, or network error
occurs in the computer system during transaction execution.
– A transaction or system error : Some operations in the transaction may cause it to fail.
– Local errors or exception conditions detected by the transaction.
IS 533 - Transactions 9
Why Recovery Is Needed (continued)
– Concurrency control enforcement : The concurrency control method may decide to abort the transaction.
– Disk failure : all disk or some disk blocks may lose their data
– Physical problems : Disasters,theft, fire, etc.
• The system must keep sufficient information to recover from the failure.
IS 533 - Transactions 10
Transaction states and additional operations
• A transaction is an atomic unit of work that is either completed in its entirety or not done at all.
• For recovery purposes the system needs to keep track of when the transaction starts, terminates, and commits or aborts.
• The recovery manager keeps track of the following operations :
– BEGIN_TRANSACTION– READ OR WRITE– END_TRANSACTION– COMMIT_TRANSACTION– ROLLBACK
IS 533 - Transactions 11
Transaction states and additional operations(continued)
ACTIVE PARTIALLYCOMMITTED
FAILD TERMINATED
COMMITTED
BEGINTRANSACTION
ENDTRANSACTION COMMIT
ABORTABORT
Figure 19.4 State transition diagram illustrating the states for transaction execution
READ/WRITE
IS 533 - Transactions 12
The System Log
• The system maintains a log to keep track of all transaction operations that affect the values of database items.
• This log may be needed to recover from failures.• Types of log records :
– [start_transaction,T] : indicates that transaction T has started execution.
– [write_item,T,X,old_value,new_value] : indicates that transaction T has changed the value of database item X from old_value to new_value.
(new_value may not be recorded)
IS 533 - Transactions 13
The System Log (continued)
– [read_item,T,X]: indicates that transaction T has read the value of database item X.
(read_item may not be recorded)
– [commit,T]: transaction T has recorded permanently .
– [abort,T]: indicates that transaction T has been aborted.
IS 533 - Transactions 14
Desirable Properties of transactions
• ACID should be enforced by the concurrency control and recovery methods of the DBMS.
• ACID properties of transactions :– Atomicity : a transaction is an atomic unit of processing; it is
either performed entirely or not performed at all.
(It is the responsibility of recovery)
– Consistency : transfer the database from one consistent state to another consistent state
(It is the responsibility of the applications and DBMS to maintain the constraints)
IS 533 - Transactions 15
Desirable Properties of transactions (continued)
– Isolation : the execution of the transaction should be isolated from other transactions (Locking)
(It is the responsibility of concurrency) * Isolation level: -Level 0 (no dirty read) -Level 1 ( no lost update)
-Level 2 (no dirty+ no lost) -Level 3 (level 2+repeatable reads)
– Durability : committed transactions must persist in the database ,i.e. those changes must not be lost because of any failure.
(It is the responsibility of recovery)
IS 533 - Transactions 16
Schedules of Transactions
• Schedule(or History) S of n transactions T1,T2,..,Tn is an ordering of operations of the transactions with the following conditions :
– for each transaction Ti that participate in S , the operations of Ti in S must appear in the same order in which they occur in Ti
– the operations from other transactions Tj can be interleaved with the operations of Ti in S.
• The symbols r,w,c, and a are used for the operations read_item, write_item, commit, and abort respectively.
IS 533 - Transactions 17
Schedules of Transactions (continued)
• Two operations are said to be conflict if:– they belong to different tansactions – they access the same item X– at least one the operations is a write_item(X)
Ex:
S1: r1(x);r2(x);w1(x);r1(y);w2(x);w1(y);
conflicts: [r1(x);w2(x)] – [r2(x);w1(x)] – [w1(x); w2(x)]
IS 533 - Transactions 18
Schedules of Transactions (continued)
• A schedule S of n transactions T1,T2,..,Tn is said to be a complete schedule if :– The operations in S are exactly those operations in T1,T2,.., Tn ,
including a commit or abort operation as the last operation for each transaction in the schedule.
– For any pair of operations from the same transaction Ti, their order of appearance in S the same as their order of appearance in Ti
– For any two conflicting operations, one of the two must occur before the other in the schedule.
IS 533 - Transactions 19
Characterizing Schedules based on Recoverability
• Type of schedules :– recoverable scheduls : once a transaction T is
commited , it should never rollbacked.
• i.e. If no transaction T in S commits until all transactions T’ that have written an item that T reads have committed.
• It is possible for Cascading rollback to occur when an uncommited transaction has to be rolled back.
IS 533 - Transactions 20
Examples
• 1- Sa: r1(x);r2(x);w1(x);r1(y);w2(x);c2;w1(y);c1;
Recoverable schedule, even it suffers from the lost update problem [w1(x);w2(x)]
• 2- Sc: r1(x); w1(x); r2(x); r1(y);w2(x);c2;a1;
Nonrecoverable schedule. Why?
T2 reads x from T1, and then T2 commits before T1 commits. If T1 aborts, then T2 must be aborted after had been committed.
IS 533 - Transactions 21
Examples
• 3- To make Sc recoverable, c2 of Sc must be postponed until after T1 commits as follows:
Sd: r1(x); w1(x); r2(x); r1(y);w2(x); w1(y);c1; c2;
• If T1 aborts, then T2 should also abort as follows:
Se: r1(x); w1(x); r2(x); r1(y);w2(x); w1(y);a1; a2;
IS 533 - Transactions 22
Characterizing Schedules based on Recoverability (continued)
– Cascadeless schedule : if every transaction in the schedule reads only items that were written by committed transactions.
– Strict Schedule : transactions can neither read nor write an item X until the last transaction that wrote X has committed or aborted.
IS 533 - Transactions 23
Serializability of SchedulesSerial, Nonserial, and Conflict-Serializable schedules
• A schedule S is serial if, for every transaction T participating in the schedule , all the operations of T are executed consecutively in the schedule.
• No interleaving occurs in serial schedule
• if we consider transactions to be independant, then every serial schedule is considered correct.
IS 533 - Transactions 24
Serializability of SchedulesSerial, Nonserial, and Conflict-Serializable schedules
(continued)
• the problems of serial schedules :– they limit concurrency or interleaving of operations
• if a transaction waits for an I/O operation to complete, we cannot switch the CPU Processor to another transaction
• if some transaction T is long , the other transactions must wait for T to complete all its operations.
IS 533 - Transactions 25
Serial, Nonserial, and Conflict-Serializable schedules (continued)
• A schedule S of n transactions is serializable if it is equivalent to some serial schedule of the same n transactions.
• Two schedules are called result equivalent if they produce the same final state of the database.
• Two schedules are said to be conflict equivalent if the order of any two conflicting operations is the same in both schedules
• schedule S is conflict serializable if it is conflict equivalent to some serial schedule S’.
IS 533 - Transactions 26
Testing for Conflict Serializability of a Schedule(Precedence Graph)
• Algorithm for Testing conflict serializability of schedule S
• For each transaction Ti participating in schedule S, create a node labeled Ti in the percedence graph
• For each case in S where Tj executes a read_item(X) after Ti executes a write_item(X),create an edge (TiTj)
• For each case in S where Tj executes a write_item(X) after Ti executes a read_item(X) create an edge (TiTj)
• For each case in S where Tj executes a write_item(X) after Ti executes a write_item(X) create an edge (TiTj)
• The schedule S is serializable if and only if the precedance graph has no cycles.
IS 533 - Transactions 27
Examples (Precedence Graph)
Assume we have these three transactions:• T1: r1(x);w1(x);r1(y);w1(y)
• T2: r2(z);r2(y);w2(y);r2(x);w2(x)
• T3: r3(y);r3(z);w3(y);w3(z)
Assume we have these schedule:
• S1: r2(z);r2(y);w2(y); r3(y);r3(z); r1(x);w1(x); w3(y);w3(z);r2(x); r1(y);w1(y); w2(x)
No equivalent serial schedule
(cycle x(T1T2),y(T2T1))
(cycle x(T1T2),yz(T2T3),y(T3T1))
y
x
y y,z
T1 T2
T3
IS 533 - Transactions 28
Examples (Precedence Graph)
Assume we have another schedule for the same transactions:
• S2: r3(y);r3(z);r1(x); w1(x);w3(y);w3(z);r2(z); r1(y);w1(y);r2(y); w2(y);r2(x);w2(x)
Equivalent serial schedule
T3T1T2
x,y
y y,z
T1 T2
T3
IS 533 - Transactions 29
Uses of serializability
• Note that: being Serializable is distinct from being Serial.
• A Serial Schedule leads to inefficient utilization of CPU because of no interleaving of operations from different transactions.
• A Serializable Schedule gives the benefits of concurrent execution without giving up any correctness
IS 533 - Transactions 30
Uses of serializability (continued)
• Practically, it is difficult to test for the serializability.
• Also, it is impractical to execute the schedule and then test the result for serializability and cancel the effect of the schedule if it is not serializable.
• The approach taken in most commercial DBMSs is to design Protocols that will ensure serializabilty of all schedules.
IS 533 - Transactions 31
View Equivalence and View Serializability
• Two schedules S and S’ are said to be view equivalent when :
– The same set of transactions participates in S and S’, and S and S’ include the same operations of those transactions.
– For any operation ri(X) of Ti in S, if the value of X read by the operation has been written by an operation wj(X) of Tj, the same condition must hold for the value of X read by operation ri(X) of Ti in S’
– If the operation wk(Y) of Tk is the last operation to write item Y in S,then wk(Y) of Tk must also be the last operation to write item Y in S’
• A schedule S is said to be view serializable if it is view equivalent to a serial schedule .
IS 533 - Transactions 32
Transaction Support in SQL• Transaction initiation is done implicitly when SQL
statement is executed.
• Every transaction must have explicit end statement, which is either a commit or a rollback.
• Every transaction has certain characteristics :– access mode : read only or read write.– diagnostic area size : option specifies an integer value n,
indicating the number of conditions that can be held simultaneously in the diagnostic area.
– The isolation level: option that can be read uncommitted, read committed, repeatable read, serializable.
IS 533 - Transactions 33
Transaction Support in SQL (continued)
If a transaction executes at a lower isolation level than serializable, then one or more of the following three violations may occur:
• Dirty read
• Nonrepeatable read
• Phantom: A transaction T1 may read a set of rows from a table, then another transaction T2 inserts new rows. If T1
repeated, then it will see a Phantom.
IS 533 - Transactions 34
Transaction Support in SQL (continued)
Possible Violations Based on Isolation Level:
Types of Violation
Isolation Dirty NonrepeatablePhantom
Level read read
Read uncommitted yes yes yes
Read committed no yes yes
Repeatable read no no yes
Serializable no no no
IS 533 - Transactions 35
Transaction Support in SQL (continued)
Example for SQL transaction:
EXEC SQL WHENEVER SQLERROR GOTO UNDO;EXEC SQL SET TRANSACTION
READ WRITEDIAGNOSTICS SIZE 5ISOLATION LEVEL SERIALIZABLE;
EXEC SQL INSERT EMPLOYEEVALUES (‘Robert’ , Smith’ , ‘991004321’ , 2 , 35000);
EXEC SQL UPDATE EMPLOYEESET SALARY = SALARY * 1.1 WHERE DNO = 2;
EXEC SQL COMMIT;GOTO THE_END;UNDO: EXEC SQL ROLLBACK;THE_END: ……..