Published on

Navate Database Management system


  1. 2. <ul><li>Introduction to </li></ul><ul><li>Transaction </li></ul><ul><li>Processing Concepts </li></ul><ul><li>and </li></ul><ul><li>Theory </li></ul>Chapter 17
  2. 3. <ul><li>Introduction to Transaction Processing </li></ul><ul><li>Transaction and System Concepts </li></ul><ul><li>Desirable Properties of Transactions </li></ul><ul><li>Characterizing Schedules Based on Recoverability </li></ul><ul><li>Characterizing Schedules based on Serializability </li></ul><ul><li>Transaction Support in SQL </li></ul>Chapter Outline
  3. 4. <ul><li>Database systems are classified as: </li></ul><ul><ul><li>Single-user: at most one user at a time can use the system </li></ul></ul><ul><ul><li>Multi-user: many users –simultaneously-- can use the system </li></ul></ul><ul><li>Multi-user systems work in one of the following modes: </li></ul><ul><ul><li>Interleaved concurrency, </li></ul></ul><ul><ul><li>Parallel processing </li></ul></ul><ul><li>Transaction processing systems are systems with large number of users that are executing database transactions on large databases (e.g., reservation systems, banking, credit card processing, supermarket checkout, and etc.). </li></ul>Introduction to Transaction Processing
  4. 5. <ul><li>FIGURE 17.1 Interleaved processing versus parallel processing of concurrent transactions. </li></ul>Introduction to Transaction Processing
  5. 6. <ul><li>A transaction is a logical unit of database processing that includes one or more database access operations (e.g., insertion, deletion, modification, or retrieval operations). </li></ul><ul><li>A read-only transaction only retrieves data and thus do not change the state of the database. </li></ul><ul><li>The basic database access operations are: </li></ul><ul><ul><li>Read-item(X): reads a database item X into a program variable X </li></ul></ul><ul><ul><li>Write-item(X): writes the value of program variable X into the database item named X </li></ul></ul>Introduction to Transaction Processing
  6. 7. <ul><li>FIGURE 17.2 Two sample transactions. </li></ul><ul><li>Transaction T 1 . </li></ul><ul><li>Transaction T 2 . </li></ul>Introduction to Transaction Processing
  7. 8. <ul><li>Problems occur when concurrent transactions execute in an uncontrolled manner: </li></ul><ul><ul><li>The Lost Update Problem </li></ul></ul><ul><ul><li>The Temporary Update (or Dirty Read) Problem </li></ul></ul><ul><ul><li>The Incorrect Summary Problem </li></ul></ul>Why Concurrency Control is Needed
  8. 9. <ul><li>FIGURE 17.3 </li></ul><ul><li>The lost update problem. </li></ul>Why Concurrency Control is Needed
  9. 10. <ul><li>FIGURE 17.3 (continued) </li></ul><ul><li>(b) The temporary update problem. </li></ul>Why Concurrency Control is Needed
  10. 11. <ul><li>FIGURE 17.3 (continued) </li></ul><ul><li>(c) The incorrect summary problem. </li></ul>Why Concurrency Control is Needed
  11. 12. <ul><li>A DBMS must make sure that either: </li></ul><ul><ul><li>All operations in the transaction are completed, or </li></ul></ul><ul><ul><li>The transaction has no effect whatsoever on the database or on any other transactions. </li></ul></ul><ul><li>Transaction failure in the middle of execution: </li></ul><ul><ul><li>A computer failure –e.g., main memory failure </li></ul></ul><ul><ul><li>A transaction or system error –e.g., division by zero </li></ul></ul><ul><ul><li>Local errors or exception conditions detected by the transaction –e.g., data may not be found </li></ul></ul><ul><ul><li>Concurrency control enforcement –e.g., abort the transaction, and start it later </li></ul></ul><ul><ul><li>Disk failure –e.g., read/write head crash </li></ul></ul><ul><ul><li>Physical problems and catastrophes –e.g., fire, sabotage </li></ul></ul>Why Recovery is Needed
  12. 13. <ul><li>A transaction is an atomic unit of work. </li></ul><ul><li>For recovery purpose, the system needs to keep track of when the transaction starts, terminates, and commits/aborts. </li></ul><ul><li>The recovery manager keeps track of the following operations: </li></ul><ul><ul><li>BEGIN_TRANSACTION </li></ul></ul><ul><ul><li>READ OR WRITE </li></ul></ul><ul><ul><li>END_TRANSACTION </li></ul></ul><ul><ul><li>COMMIT_TRANSACTION –ended successfully </li></ul></ul><ul><ul><li>ROLLBACK (OR ABORT) --ended unsuccessfully </li></ul></ul>Transactions and System Concepts
  13. 14. <ul><li>A transaction goes into an active state immediately after it starts execution. </li></ul><ul><li>When the transaction ends, it moves to the partially committed state . </li></ul><ul><li>If the transaction passes recovery protocol checks, then it enters the committed state, otherwise it goes to the failed state. </li></ul><ul><li>The terminated state corresponds to the transaction leaving the system. </li></ul>Transactions and System Concepts
  14. 15. <ul><li>FIGURE 17.4 State transition diagram illustrating the states for transaction execution . </li></ul>Transactions and System Concepts
  15. 16. <ul><li>For recovery purpose, the system maintains a log to keep track of all transaction operations that affect the value of database items. </li></ul><ul><li>Log records contains of the following information </li></ul><ul><ul><li>START_TRANSACTION, T </li></ul></ul><ul><ul><li>WRITE_ITEM, T, X, OLD_VALUE, NEW_VALUE </li></ul></ul><ul><ul><li>READ_ITEM, T, X </li></ul></ul><ul><ul><li>COMMIT, T </li></ul></ul><ul><ul><li>ABORT, T </li></ul></ul><ul><ul><li>Where T refers to a unique transaction-id that is generated automatically by the system. </li></ul></ul><ul><li>Log records enables undo/redoing </li></ul>Transactions and System Concepts
  16. 17. <ul><li>Transactions should posses ACID properties: </li></ul><ul><ul><li>A tomicity: it is either performed in its entirety or not performed at all. </li></ul></ul><ul><ul><li>C onsistency preservation: its complete execution take(s) the database from one consistent state to another. </li></ul></ul><ul><ul><li>I solation: its execution should not be interfered with by any other transaction executing concurrently. </li></ul></ul><ul><ul><li>D urability or Permanency: the changes applied to the database by a committed transaction must persist in the database. </li></ul></ul>Desirable Properties of Transactions
  17. 18. <ul><li>A schedule (or history ) S of n transactions T 1 , T 2 , …, T n is an ordering of the operations of the transactions, such that operations of T i in S must appear in the same order in which they occur in T i . For example, the schedule of Figure 17.3(a) is </li></ul><ul><li>S a : r 1 (X); r 2 (X); w 1 (X); r 1 (Y); w 2 (X); w 1 (Y); </li></ul><ul><li>and the schedule for Figure 17.3(b) is </li></ul><ul><li>S b : r 1 (X); w 1 (X); r 2 (X); w 2 (X); r 1 (Y); a 1 ; </li></ul><ul><li>Two operations in a schedule are conflict if: </li></ul><ul><ul><li>They belong to different transactions, </li></ul></ul><ul><ul><li>They access the same item X, and </li></ul></ul><ul><ul><li>At least one them is a WRITE_ITEM(X) operation. </li></ul></ul>Characterizing Schedules Based on Recoverability
  18. 19. <ul><li>A schedule S of n transactions T 1 , T 2 , …, T n is said to be a complete schedule if: </li></ul><ul><ul><li>The operations in S are exactly those operations in T 1 , T 2 , …, T n including a commit or abort operation as the last operation for each transaction. </li></ul></ul><ul><ul><li>The order of operations in S is the same as their occurrence in T i . </li></ul></ul><ul><ul><li>For any two conflict operations, one of the two must occur before the other in the schedule. </li></ul></ul>Characterizing Schedules Based on Recoverability
  19. 20. <ul><li>For some schedule it is easy to recover from transaction failures. </li></ul><ul><li>We would like that, once a transaction T is committed, it should never be necessary to roll back T. The schedules that meet this criterion are called recoverable schedules . Therefore: </li></ul><ul><ul><li>A schedule S is recoverable if no transaction T in S commits until all transactions T’ that have written an item that T reads have committed. For example </li></ul></ul><ul><ul><li>S’ a : r 1 (X); r 2 (X); w 1 (X); r 1 (Y); w 2 (X); c 2 ; w 1 (Y); c 1 ; </li></ul></ul><ul><ul><li>is recoverable, even though it suffers from the lost update problem. </li></ul></ul>Characterizing Schedules Based on Recoverability
  20. 21. <ul><li>Example -- Consider the following schedules: </li></ul><ul><ul><li>S c : r 1 (X); w 1 (X); r 2 (X); r 1 (Y); w 2 (X); c 2 ; a 1 ; </li></ul></ul><ul><ul><li>S d : r 1 (X); w 1 (X); r 2 (X); r 1 (Y); w 2 (X); w 1 (Y); c 1 ; c 2 ; </li></ul></ul><ul><ul><li>S e : r 1 (X); w 1 (X); r 2 (X); r 1 (Y); w 2 (X); w 1 (Y); a 1 ; a 2 ; </li></ul></ul><ul><ul><li>S c is not recoverable , because T 2 reads item X written by T 1 , and then T 2 commits before T 1 commits. </li></ul></ul><ul><ul><li>S d is recoverable , because T 2 reads item X written by T 1 , and then T 2 commits after T 1 commits and no other conflict operations exists in the schedule. </li></ul></ul><ul><ul><li>S e is similar to S d , but T 1 is aborted (instead of commit). </li></ul></ul><ul><ul><li>In this situation T 2 should also abort, because the value of X it read is no longer valid (this phenomenon known as cascading rollback or cascading abort ). </li></ul></ul>Characterizing Schedules Based on Recoverability
  21. 22. <ul><li>Because cascading rollback can be quite time-consuming, we perform cascadeless schedules. </li></ul><ul><li>A schedule is said to be cascadeless or to avoid cascading rollback if every transaction in the schedule reads only items that were written by committed transactions. </li></ul><ul><li>A more restrictive type of schedule is called strict schedule, in which transactions can neither read nor write an item X until the last transaction that wrote X has committed (or aborted) </li></ul>Characterizing Schedules Based on Recoverability
  22. 23. <ul><li>If no interleaving of operations is permitted, there are only two possible arrangements for executing transactions T 1 and T 2 : </li></ul><ul><ul><li>Execute (in sequence) all the operations of transaction T 1 , followed by all the operations of transaction T 2 . </li></ul></ul><ul><ul><li>Execute (in sequence) all the operations of transaction T 2 , followed by all the operations of transaction T 1 . </li></ul></ul><ul><li>If interleaving of operations is allowed there will be many possible schedules. </li></ul><ul><li>The concept of serializability of schedules is used to identify which schedules are correct. </li></ul>Characterizing Schedules Based on Serializability
  23. 24. <ul><li>FIGURE 17.5 Examples of serial and nonserial schedules involving transactions T 1 and T 2 . </li></ul><ul><li>Serial schedule A: T 1 followed by T 2 . </li></ul><ul><li>Serial schedules B: T 2 followed by T 1 . </li></ul>Characterizing Schedules Based on Serializability
  24. 25. <ul><li>FIGURE 17.5 (continued) </li></ul><ul><li>Examples of serial and nonserial schedules involving transactions T 1 and T 2 . </li></ul><ul><li>(c) Two nonserial schedules C and D with interleaving of operations. </li></ul>Characterizing Schedules Based on Serializability
  25. 26. <ul><li>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; otherwise the schedule is called nonserial. </li></ul><ul><li>The drawback of serial schedules is that they limit concurrency of interleaving of operations. </li></ul><ul><li>Two schedules are called result equivalent if they produce the same final state of the database. </li></ul>Characterizing Schedules Based on Serializability
  26. 27. <ul><li>FIGURE 17.6 Two schedules that are result equivalent for the initial value of X = 100, but are not result equivalent in general. </li></ul>Characterizing Schedules Based on Serializability
  27. 28. <ul><li>Two schedules are called conflict equivalent if the order of any two conflicting operations is the same in both schedules. </li></ul><ul><li>A schedule S of n transactions is serializable if it is equivalent to some serial schedule of the same n transactions. </li></ul><ul><li>A schedule S to be conflict serializable if it is conflict equivalent to some serial schedule S’. </li></ul>Characterizing Schedules Based on Serializability
  28. 29. <ul><li>Algorithm for testing conflict serializability of S: </li></ul><ul><ul><li>For each transaction T i in schedule S, create a node, </li></ul></ul><ul><ul><li>If T j executes a READ_ITEM(X) after T i executes a WRITE_ITEM(X), create an edge T i  T j </li></ul></ul><ul><ul><li>If T j executes a WRITE_ITEM(X) after T i executes a READ_ITEM(X), create an edge T i  T j </li></ul></ul><ul><ul><li>If T j executes a WRITE_ITEM(X) after T i executes a WRITE_ITEM(X), create an edge T i  T j </li></ul></ul><ul><ul><li>The schedule S is serializable if and only if the precedence graph has no cycle. </li></ul></ul>Characterizing Schedules Based on Serializability
  29. 30. <ul><ul><li>FIGURE 17.7 Constructing the precedence graphs for schedules A, B, C, and D from Figure 17.5 to test for conflict serializability </li></ul></ul><ul><ul><li>Precedence graph for serial schedule A. </li></ul></ul><ul><ul><li>Precedence graph for serial schedule B. </li></ul></ul><ul><ul><li>Precedence graph for schedule C (not serializable). </li></ul></ul><ul><ul><li>Precedence graph for schedule D (serializable, equivalent to schedule A) </li></ul></ul>Characterizing Schedules Based on Serializability
  30. 31. <ul><li>Every transaction has certain characteristics attributed to it, which is specified by a SET TRANSACTION statement in SQL. The characteristics are: </li></ul><ul><ul><li>Access mode: can be READ ONLY or READ WRITE </li></ul></ul><ul><ul><li>Diagnostic area size: specifies an integer value n, indicating the number of conditions that can be held simultaneously (supplies feedback information). </li></ul></ul><ul><ul><li>Isolation level: is specified using the statement </li></ul></ul><ul><ul><ul><li>ISOLATION LEVEL <isolation> </li></ul></ul></ul><ul><ul><ul><li>Where the value for <isolation> can be READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, or SERIALIZABLE </li></ul></ul></ul>Transaction Support in SQL
  31. 32. <ul><li>The default isolation level is SERIALIZABLE (not allowing violations that cause dirty read, unrepeatable read, and phantoms). </li></ul><ul><li>If a transaction executes at a lower level than SERIALIZABLE, then one or more of the following violations may occur: </li></ul><ul><ul><li>Dirty read: a transaction T 1 may read the update of a transaction T 2 , which is not committed yet, </li></ul></ul><ul><ul><li>Nonrepeatable read: T 1 may read a value, and after T 2 updates it, T 1 reads and will see a different value, </li></ul></ul><ul><ul><li>Phantoms: T1 reads a set of rows from a table, a transaction inserts a row; if T1 is repeated it will see a phantom (a row that previously did not exist). </li></ul></ul>Transaction Support in SQL
  32. 33. <ul><li>A sample SQL transaction: </li></ul><ul><li>EXEC SQL WHENEVER SQLERROR GOTO UNDO; </li></ul><ul><li>EXEC SQL SET TRANSACRTION </li></ul><ul><li>READ WRITE </li></ul><ul><li>DIAGNOSTIC SIZE 5 </li></ul><ul><li>ISOLATION LEVEL SERIALIZABLE; </li></ul><ul><li>EXEC SQL INSERT INTO EMPLOYEE (FNAME, LNAME, SSN, DNO, SALARY) </li></ul><ul><li>VALUES (‘Robert’, ‘Smith’, ‘991004321’, 2, 35000); </li></ul><ul><li>EXEC SQL UPDATE EMPLOYEE </li></ul><ul><li>SET SALARY = SALARY * 1.1 </li></ul><ul><li>WHERE DNO = 2; </li></ul><ul><li>EXEC SQL COMMIT; </li></ul><ul><li>GOTO THE_END; </li></ul><ul><li>UNDO: EXEC SQL ROLLBACK; </li></ul><ul><li>THE_END: …; </li></ul>Transaction Support in SQL