O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Dbms ii mca-ch9-transaction-processing-2013

.......................................................................................................

  • Entre para ver os comentários

Dbms ii mca-ch9-transaction-processing-2013

  1. 1. By C.Aruna (DSCASC) 1 Transaction Processing Concepts Chapter 9 UNIT V Data Base Management System [DBMS]
  2. 2. By C.Aruna (DSCASC) 2 Intoduction Transaction Processing Concepts 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.
  3. 3. By C.Aruna (DSCASC) 3 Single user Versus Multiuser Systems Single-User: At most one user at a time can use the system  Multi-User: 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.
  4. 4. By C.Aruna (DSCASC) 4 Transactions, Read and Write Operations 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 as 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.
  5. 5. Read and Write Operations of a Transaction  read_item(X): reads a database item named X into a program variable also named X. Execution of the command includes the following steps:  find the address of the disk block that contains item X  copy that disk block into a buffer in the main memory  copy item X from the buffer to the program variable named X  write_item(X): writes the value of program variable X into the database item named X. Execution of the command includes the following steps:  find the address of the disk block that contains item X  copy that disk block into a buffer in the main memory  copy item X from the program variable named X into its current location in the buffer  store the updated block in the buffer back to disk (this step updates the database on disk) 5By C.Aruna (DSCASC)
  6. 6. By C.Aruna (DSCASC) 6 Two sample transactions a) Transaction T1 read_item(X); X:=X-N; write_item(X); read_item(Y); Y:=Y+N; write_item(Y); Transfer N reservations from 1st flight to 2nd flight b) Transaction T2 read_item(x); X:=X+M; write_item(X); Reserve M seats on the 1st flight X & Y refers to number of reserved seats for specific flight.
  7. 7. Transactions - examples T1 Read-item(my-account) my-account := my-account - 2000 Write-item(my-account) Read-item(other-account) Other-account := other-account + 2000 Write-item(other-account) T2 Read-item(my-account) my-account := my-account +1000 Write-item(my-account) By C.Aruna (DSCASC) 7 Example T1: Rs.2000 is deducted from my-account and added into other-account Example T2: Rs.1000 is added to my-account
  8. 8. By C.Aruna (DSCASC) 8 Why Concurrency Control is needed Several problems can occur when concurrent transactions execute in an uncontrolled manner. Eg: Airlines reservation database. Types of problems: Types of problem occur when the two transaction run concurrently. 1) The Lost Update Problem. 2) The temporary Update (or Dirty read) problem. 3) The Incorrect Summary Problem. 4) Unrepeatable Read problem.
  9. 9. By C.Aruna (DSCASC) 9 Why Concurrency Control is needed  The Lost Update Problem: This problem occurs when two transactions access the same database items concurrently. T1 T2 Read_item(X); X=:X-N; Time Read_item(X); X=:X+M; Write_item(X); Read_item(Y); Y=:Y+N; Write_item(X); Item X has incorrect value because its update by T1 is “lost” (overwritten) Write_item(Y); Pg:635 Navathe Eg. X=80 at the start, N=5 (T1 transfers 5 seat reservations from flight corresponding to X to the flight corresponding to Y) & M=4
  10. 10. Ex: Lost update problem T1 Read-item(my-account) my-account := my-account – 2000 Write-item(my-account) Read-item(other-account) Other-account := other-account + 2000 Write-item(other-account) T2 Read-item(my-account) my-account := my-account +1000 Write-item(my-account) By C.Aruna (DSCASC) 10 Example T1: Rs.2000 is deducted from my-account Example T2: Rs.1000 is added to my-account Time
  11. 11. By C.Aruna (DSCASC) 11 Why Concurrency Control is needed  The temporary Update (or Dirty read) problem: This problem occurs when one transaction updates a database item and then the transaction fails for some reason. The update item is accessed by another transaction before it is changed back to its original value. T1 T2 Read_item(X); X=:X-N; write_item(X); Time Read_item(X); X=:X+M; write_item(X);read_item(Y); Transaction T1 fails and must change the value of X back to its old value, meanwhile T2 has read the temporary value ie. Incorrect value of X Writing fails before completion.
  12. 12. Ex: Dirty read problem T1 Read-item(my-account) My-account := my-account - 2000 Write-item(my-account) Read-item(other-account) T2 Read-item(my-account) My-account := my-account +1000 Write-item(my-account) By C.Aruna (DSCASC) 12 Writing fails before completion. Time
  13. 13. By C.Aruna (DSCASC) 13 Why Concurrency Control is needed (continued)  The Incorrect Summary Problem: If one transaction is calculating an aggregated summary function on a number of records while other transaction are updating some of these records, the aggregate function may calculate some values before they are updated and others after they are updated.
  14. 14. By C.Aruna (DSCASC) 14 Why Concurrency Control is needed (continued) 3. The Incorrect Summary Problem: T1 T3 Read_item(X); X=:X-N; write_item(X); Time Read_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; . . .
  15. 15. Ex: Incorrect Summary Problem T1 Read-item(my-account1) My-account1 := my-account1 - 2000 Write-item(my-account1) Read-item(my-account2) My-account2 := my-account2 + 2000 Write-item(my-account2) T2 sum := 0 Read-item(my-account1) sum := sum + my-account1 Read-item(my-account2) sum := sum + my-account2 By C.Aruna (DSCASC) 15
  16. 16. Why Concurrency Control is needed (continued) 4. Unrepeatable Read problem: A transaction reads items twice with two different values because it was changed by another transaction between the two reads. By C.Aruna (DSCASC) 16 T1 Read-item(my-account) Read-item(my-account) T2 Read-item(my-account) My-account:= my-account + 1000 Write-item(my-account) Eg: Bank, Flight Reservation – A customer enquires about seat availability in diff. flights. When he decides to book, the no. of seats will be different because of T2 updates the no.of seats.
  17. 17. By C.Aruna (DSCASC) 17 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.
  18. 18. By C.Aruna (DSCASC) 18 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.
  19. 19. By C.Aruna (DSCASC) 19 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
  20. 20. By C.Aruna (DSCASC) 20 Transaction states BEGIN_TRANSACTION: This marks the beginning of transaction execution. READ OR WRITE: Specifies READ or WRITE transaction operations on the database items that are executed as part of a transaction. END_TRANSACTION: Specifies the READ and WRITE transaction operations have ended and marks the end of transaction execution. COMMIT_TRANSACTION: This signals a successful end of the transaction. ROLLBACK (or ABORT): This signals that the transaction has ended unsuccessfully, so that any changes or effects that the transaction may have applied to the database must be undone.
  21. 21. By C.Aruna (DSCASC) 21 ACTIVE PARTIALLY COMMITTED FAILED TERMINATED COMMITTED BEGIN TRANSACTION END TRANSACTION COMMIT ABORT ABORT Figure 19.4 State transition diagram illustrating the states for transaction execution READ/ WRITE Transaction states
  22. 22. By C.Aruna (DSCASC) 22 Transaction states  A state transition diagram that describes how a transaction moves through its execution states.  A transaction goes into active state immediately after it starts execution, where it can issue READ and WRITE operations.  When the transaction ends it moves to the partially committed state.  At this point some recovery protocols need to ensure that a system failure will not result in an inability to record the changes of the transaction permanently.  Once this check is successful the transaction is said to have reached its commit point and enters the committed state.  A transaction can go to failed state if one of the checks fails or if the transaction is aborted during its active state.  The transaction may then have to be rolled back to undo the effect of its WRITE operations on the database.  The terminated state corresponds to the transaction leaving the system.
  23. 23. Properties of transactions Properties of transactions: ACID  Atomicity Consistency preservation Isolation  Durability By C.Aruna (DSCASC) 23
  24. 24. By C.Aruna (DSCASC) 24 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)
  25. 25. By C.Aruna (DSCASC) 25 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)
  26. 26. • Atomicity – Recovery system • Consistency – Programmer + DBMS • Isolation – Concurrency control • Durability – Recovery system By C.Aruna (DSCASC) 26
  27. 27. Serial and serializability of schedules • A schedule S is serial if in the operations in each transaction in S are executed directly after each other. • A schedule S is serializable if there is an equivalent serial schedule S'. • Equivalent: conflict equivalence By C.Aruna (DSCASC) 27
  28. 28. Transactions T1 Read-item(my-account) My-account := my-account - 2000 Write-item(my-account) Read-item(other-account) Other-account := other-account + 2000 Write-item(other-account) By C.Aruna (DSCASC) 28 T2 Read-item(my-account) My-account := my-account +1000 Write-item(my-account)
  29. 29. Example of Serial Schedules T1 Read-item(my-account) My-account := my-account - 2000 Write-item(my-account) Read-item(other-account) Other-account := other-account + 2000 Write-item(other-account) By C.Aruna (DSCASC) 29 T2 Read-item(my-account) My-account := my-account +1000 Write-item(my-account)
  30. 30. Example of Serial Schedules T1 Read-item(my-account) My-account := my-account - 2000 Write-item(my-account) Read-item(other-account) Other-account := other-account + 2000 Write-item(other-account) By C.Aruna (DSCASC) 30 T2 Read-item(my-account) My-account := my-account +1000 Write-item(my-account)
  31. 31. Example of Non-serial Schedules time T1: T2: read_item(X); X:= X - N; read_item(X); X:= X + M; write_item(X); read_item(Y); write_item(X); Y:=Y + N; write_item(Y); Schedule A 31By C.Aruna (DSCASC)

×