* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Transaction processing systems
Survey
Document related concepts
Microsoft SQL Server wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Database model wikipedia , lookup
Relational model wikipedia , lookup
Consistency model wikipedia , lookup
Clusterpoint wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Global serializability wikipedia , lookup
Object-relational impedance mismatch wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Commitment ordering wikipedia , lookup
Transcript
Quick revision on Transaction Processing Concepts By: Dr. Yousry Taha Copyright 2010 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 2 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 3 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 readonly 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 4 Why Concurrency Control is needed • Several problems can occur when concurrent transactions execute in an uncontrolled manner. 1. The Lost Update Problem : T1 Read_item(X); X=:X-N; Time Write_item(X); Read_item(Y); Y=:Y+N; T2 Read_item(X); X=:X+M; Item X has incorrect value Write_item(X); Write_item(Y); IS 533 - Transactions 5 Why Concurrency Control is needed (continued) 2. The temporary Update (or Dirty read) problem T2 T1 Read_item(X); X=:X-N; write_item(X); Read_item(X); X=:X+M; write_item(X); Time read_item(Y); T1 fails and must rollback, meanwhile T2 has read the temporary value IS 533 - Transactions 6 Why Concurrency Control is needed (continued) 3. The Incorrect Summary Problem T3 T1 Sum:=0; Read_item(A); sum:=sum+A; Read_item(X); X=:X-N; write_item(X); Time . . . Read_item(X); sum:=sum+x; read_item(Y); sum:=sum+Y; T3 reads X after N is subtracted and reads Y before N is added; read_item(Y); Y:=Y+N; write_item(Y); 4. Unrepeatable Read problem: A transaction reads items twice with two different values because it was changed by another transaction between the two reads. IS 533 - Transactions 7 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 8 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 9 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 10 Transaction states and additional operations (continued) READ/ WRITE END TRANSACTION BEGIN TRANSACTION COMMIT PARTIALLY COMMITTED ACTIVE ABORT COMMITTED ABORT FAILD TERMINATED Figure 19.4 State transition diagram illustrating the states for transaction execution IS 533 - Transactions 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 Serializability of Schedules Serial, 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 23 Serializability of Schedules Serial, 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 24 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 25 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 26 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) T1 No equivalent serial schedule (cycle x(T1T2),y(T2T1)) y (cycle x(T1T2),yz(T2T3),y(T3T1)) y T2 x y,z T3 IS 533 - Transactions 27 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 x,y T3T1T2 T1 T2 y y,z T3 IS 533 - Transactions 28 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 29 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 30 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 31 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 32 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 33 Transaction Support in SQL (continued) Possible Violations Based on Isolation Level: Types of Violation Isolation Level Dirty read Read uncommitted Read committed Repeatable read Serializable yes no no no Nonrepeatable read yes yes no no IS 533 - Transactions Phantom yes yes yes no 34 Transaction Support in SQL (continued) Example for SQL transaction: EXEC SQL WHENEVER SQLERROR GOTO UNDO; EXEC SQL SET TRANSACTION READ WRITE DIAGNOSTICS SIZE 5 ISOLATION LEVEL SERIALIZABLE; EXEC SQL INSERT EMPLOYEE VALUES (‘Robert’ , Smith’ , ‘991004321’ , 2 , 35000); EXEC SQL UPDATE EMPLOYEE SET SALARY = SALARY * 1.1 WHERE DNO = 2; EXEC SQL COMMIT; GOTO THE_END; UNDO: EXEC SQL ROLLBACK; THE_END: …….. IS 533 - Transactions 35