database management system Chapter 5
Download as PPT, PDF1 like1,617 views
A transaction is a logical unit of work that transforms a database from one consistent state to another. It has four main properties: atomicity, consistency, isolation, and durability. The transaction log records the steps of transactions to support recovery in case of failures. Concurrency control techniques like locking and timestamping coordinate concurrent transactions to ensure serializability and prevent anomalies.
Ad
More Related Content
What's hot (20)
Viewers also liked (8)
Ad
Similar to database management system Chapter 5 (20)
Ad
Recently uploaded (20)
database management system Chapter 5
- 2. What is a Transaction?What is a Transaction? A logical unit of work on a database ◦ An entire program ◦ A portion of a program ◦ A single command The entire series of steps necessary to accomplish a logical unit of work Successful transactions change the database from one CONSISTENT STATE to another (One where all data integrity constraints are satisfied)
- 3. Example of a TransactionExample of a Transaction Updating a Record ◦ Locate the Record on Disk ◦ Bring record into Buffer ◦ Update Data in the Buffer ◦ Writing Data Back to Disk
- 4. 4 Properties of a Transaction4 Properties of a Transaction Atomic – All or Nothing All parts of the transaction must be completed and committed or it must be aborted and rolled back Consistent Each user is responsible to ensure that their transaction (if executed by itself) would leave the database in a consistent state
- 5. 4 Properties of a Transaction4 Properties of a Transaction Isolation The final effects of multiple simultaneous transactions must be the same as if they were executed one right after the other Durability If a transaction has been committed, the DBMS must ensure that its effects are permanently recorded in the database (even if the system crashes)
- 6. Transaction Management with SQLTransaction Management with SQL SQL Statements Commit / Rollback When a transaction sequence is initiated it must continue through all succeeding SQL statements until: 1. A Commit Statement is Reached 2. A Rollback Statement is Reached 3. The End of the Program is Reached (Commit) 4. The Program is Abnormally Terminated (Rollback)
- 7. ExampleExample BEGIN TRAN DECLARE @ErrorCode INT, @TranSuccessful INT SET @TranSuccessful = 1 INSERT INTO tblCatalog (CatalogYear) VALUES('2002') SET @ErrorCode = @@ERROR; IF (@ErrorCode <> 0) SET @TranSuccessful = 0 –False INSERT INTO tblCatalog (CatalogYear) VALUES('2003') SET @ErrorCode = @@ERROR; IF (@ErrorCode <> 0) SET @TranSuccessful = 0 –False IF @TranSuccessful = 0 BEGIN ROLLBACK TRAN RAISERROR ('Rolledback transaction: Insert Catalog Year.', 16,1) END ELSE BEGIN COMMIT TRAN PRINT 'Successfully inserted catalog years...' END GO
- 8. Transaction LogTransaction Log Keeps track of all transactions that update the database ◦ Record for the beginning of the transaction ◦ Type of operation (insert / update / delete) ◦ Names of objects/tables affected by the transaction ◦ Before and After Values for Updated Fields ◦ Pointers to Previous and Next Transaction Log Entries for the same transaction ◦ The Ending of the Transaction (Commit) Used for recovery in case of a Rollback
- 9. Concurrency ControlConcurrency Control Coordination of simultaneous transaction execution in a multiprocessing database system Ensure transaction serializability in a multi-user database Lack of Concurrency Control can create data integrity and consistency problems: ◦ Lost Updates ◦ Uncommitted Data ◦ Inconsistent Retrievals
- 10. Lost UpdatesLost Updates TimTim ee Jack’s TransJack’s Trans Jill’s TransJill’s Trans BalanceBalance T1T1 BeginBegin T2T2 Read BalanceRead Balance BeginBegin 10001000 T3T3 Read BalanceRead Balance 10001000 T4T4 Bal = Bal – 50Bal = Bal – 50 (950)(950) 10001000 T5T5 Write Bal (950)Write Bal (950) Bal = Bal + 100Bal = Bal + 100 (1100)(1100) 950950 T6T6 CommitCommit 950950 T7T7 Write Bal (1100)Write Bal (1100) 11001100 T8T8 CommitCommit 11001100
- 11. Uncommitted DataUncommitted Data TimeTime DepositDeposit InterestInterest BalBal T1T1 Begin TransactionBegin Transaction 10001000 T2T2 Read Bal (1000)Read Bal (1000) 10001000 T3T3 Bal = Bal + 1000 (2000)Bal = Bal + 1000 (2000) 10001000 T4T4 Write Bal (2000)Write Bal (2000) Begin TransactionBegin Transaction 20002000 T5T5 Read Bal (2000)Read Bal (2000) 20002000 T6T6 Bal = Bal*1.05 (2100)Bal = Bal*1.05 (2100) 20002000 T7T7 RollbackRollback 10001000 T8T8 Write Bal (2100)Write Bal (2100) 21002100 T9T9 CommitCommit 21002100
- 12. Inconsistent RetrievalsInconsistent Retrievals TimeTime SumBalSumBal TransferTransfer Bal ABal A Bal BBal B Bal CBal C SumSum T1T1 Begin TransBegin Trans 50005000 50005000 50005000 T2T2 Sum = 0Sum = 0 Begin TransBegin Trans 50005000 50005000 50005000 T3T3 Read BalA (5000)Read BalA (5000) 50005000 50005000 50005000 T4T4 Sum = Sum +Sum = Sum + BalA (5000)BalA (5000) Read BalA (5000)Read BalA (5000) 50005000 50005000 50005000 T5T5 Read BalB (5000)Read BalB (5000) BalA = BalA -1000 (4000)BalA = BalA -1000 (4000) 50005000 50005000 50005000 T6T6 Sum = Sum+BalBSum = Sum+BalB (10000)(10000) Write BalA (4000)Write BalA (4000) 40004000 50005000 50005000 T7T7 Read BalCRead BalC 40004000 50005000 50005000 T8T8 BalC =BalC + 1000 (6000)BalC =BalC + 1000 (6000) 40004000 50005000 50005000 T9T9 Write BalC (6000)Write BalC (6000) 40004000 50005000 60006000 T10T10 Read BalCRead BalC CommitCommit 40004000 50005000 60006000 T11T11 Sum=Sum + BalCSum=Sum + BalC (16000)(16000) 40004000 50005000 60006000 T12T12 Write Sum (16000)Write Sum (16000) 40004000 50005000 60006000 1600016000 T13T13 CommitCommit 40004000 50005000 60006000 1600016000
- 13. Serial Execution of TransactionsSerial Execution of Transactions Serial Execution of transaction means that the transactions are performed one after another. No interaction between transactions - No Concurrency Control Problems Serial Execution will never leave the database in an inconsistent state Every Serial Execution is considered correct (Even if a different order would cause different results)
- 14. SerializabilitySerializability If 2 Transactions are only reading data items – They do not conflict Order is unimportant If 2 Transactions operate (Read/Write) on Separate Data Items – They do not conflict Order is unimportant If 1 Transaction Writes to a Data Item and Another Reads or Writes to the Same Data Item The Order of Execution IS Important
- 15. The SchedulerThe Scheduler Special DBMS Program to establish the order of operations in which concurrent transactions are executes Interleaves the execution of database operations to ensure: Serializability Isolation of Transactions
- 16. The SchedulerThe Scheduler Bases its actions on Concurrency Control Algorithms (Locking / Time Stamping) Ensures the CPU is used efficiently (Scheduling Methods) Facilitates Data Isolation Ensure that 2 transactions do not update the same data at the same time
- 17. Concurrency Control AlgorithmsConcurrency Control Algorithms Locking A Transaction “locks” a database object to prevent another object from modifying the object Time-Stamping Assign a global unique time stamp to each transaction Optimistic Assumption that most database operations do not conflict
- 18. LockingLocking Lock guarantees exclusive use of data item to current transaction Prevents reading Inconsistent Data Lock Manager is responsible for assigning and policing the locks used by the transaction
- 19. Locking GranularityLocking Granularity Indicates the level of lock use Database Level – Entire Database is Locked Table Level – Entire Table is Locked Page Level – Locks an Entire Diskpage (Most Frequently Used) Row Level – Locks Single Row of Table Field Level – Locks a Single Attribute of a Single Row (Rarely Done)
- 20. Types of Locks:Types of Locks: BinaryBinary Binary Locks – Lock with 2 States ◦ Locked – No other transaction can use that object ◦ Unlocked – Any transaction can lock and use object All Transactions require a Lock and Unlock Operation for Each Object Accessed (Handled by DBMS) ◦ Eliminates Lost Updates ◦ Too Restrictive to Yield Optimal Concurrency Conditions
- 21. Types of Locks:Types of Locks: Shared / Exclusive LocksShared / Exclusive Locks Indicates the Nature of the Lock Shared Lock – Concurrent Transactions are granted READ access on the basis of a common lock Exclusive Lock – Access is reserved for the transaction that locked the object 3 States: Unlocked, Shared (Read), Exclusive (Write) More Efficient Data Access Solution More Overhead for Lock Manager ◦ Type of lock needed must be known ◦ 3 Operations: Read_Lock – Check to see the type of lock Write_Lock – Issue a Lock Unlock – Release a Lock ◦ Allow Upgrading / Downgrading of Locks
- 22. Problems with LockingProblems with Locking Transaction Schedule May Not be Serializable ◦ Can be solved with 2-Phase Locking May Cause Deadlocks ◦ A deadlock is caused when 2 transactions wait for each other to unlock data
- 23. Two Phase LockingTwo Phase Locking Defines how transactions Acquire and Relinquish Locks 1. Growing Phase – The transaction acquires all locks (doesn’t unlock any data) 2. Shrinking Phase – The transaction releases locks (doesn’t lock any additional data) Transactions acquire all locks it needs until it reaches locked point When locked, data is modified and locks are released
- 24. DeadlocksDeadlocks Occur when 2 transactions exist in the following mode: T1 = access data item X and Y T2 = Access data items Y and X If T1 does not unlock Y, T2 cannot begin If T2 does not unlock X, T1 cannot continue T1 & T2 wait indefinitely for each other to unlock data Deadlocks are only possible if a transactions wants an Exclusive Lock (No Deadlocks on Shared Locks)
- 25. Controlling DeadlocksControlling Deadlocks Prevention – A transaction requesting a new lock is aborted if there is the possibility of a deadlock – Transaction is rolled back, Locks are released, Transaction is rescheduled Detection – Periodically test the database for deadlocks. If a deadlock is found, abort / rollback one of the transactions Avoidance – Requires a transaction to obtain all locks needed before it can execute – requires locks to be obtained in succession
- 26. Time StampingTime Stamping Creates a specific order in which the transactions are processed by the DBMS 2 Main Properties 1. Uniqueness – Assumes that no equal time stamp value can exist (ensures serializability of the transactions) 2. Monotonicity – Ensures that time stamp values always increases All operations within the same transaction have the same time stamp If Transactions conflict, one is rolled back and rescheduled Each value in Database requires 2 Additional Fields: Last Time Read / Last Time Updated Increases Memory Need and Processing Overhead
- 27. Time Stamping SchemesTime Stamping Schemes Wait / Die Scheme The older transaction will wait The younger transaction will be rolled back Wound / Wait Scheme The older transaction will preempt (wound) the younger transaction and roll it back The younger transaction waits for the older transaction to release the locks Without time-out values, Deadlocks may be created
- 28. Optimistic MethodOptimistic Method Most database operations do not conflict No locking or time stamping Transactions execute until commit ◦ Read Phase – Read database, execute computations, make local updates (temporary update file) ◦ Validate Phase – Transaction is validated to ensure changes will not effect integrity of database If Validated Go to Write Phase If Not Validated Restart Transaction and discard initial changes ◦ Write Phase – Commit Changes to database Good for Read / Query Databases (Few Updates)
- 29. Database RecoveryDatabase Recovery Restore a database from a given state to a previous consistent state Atomic Transaction Property (All or None) Backup Levels: ◦ Full Backup ◦ Differential Backup ◦ Transaction Log Backup Database / System Failures: ◦ Software (O.S., DBMS, Application Programs, Viruses) ◦ Hardware (Memory Chips, Disk Crashes, Bad Sectors) ◦ Programming Exemption (Application Program rollbacks) ◦ Transaction (Aborting transactions due to deadlock detection) ◦ External (Fire, Flood, etc)
- 30. Transaction RecoveryTransaction Recovery Recover Database by using data in the Transaction Log Write-Ahead-Log – Transaction logs need to be written before any database data is updated Redundant Transaction Logs – Several copies of log on different devices Database Buffers – Buffers are used to increase processing time on updates instead of accessing data on disk Database Checkpoints – Process of writing all updated buffers to disk While this is taking place, all other requests are not executes ◦ Scheduled several times per hour ◦ Checkpoints are registered in the transaction log
Editor's Notes
- #9: A transaction log is a database – therefore it is managed by the DBMS like any other database. It is subject to database dangers like disk crashes. The transaction log contains some of the most critical data in a DBMS – attempts to reduce the risk of system failure should be implemented.
- #13: SumBal finds the sum of the balances of all three accounts – it does NOT UPDATE the account, but reads them Transfer will transfer 1000 from Account A to Account C Transfer Transaction executes correctly, however, the SumBal adds the same $1000 twice – once in A and Once in C
- #15: 2 Operations conflict IF ALL of the following are true: They belong to different transactions They access the same data item At least one of them writes the item
- #19: Most DBMS’s automatically initiate and enforce locking procedures through the lock manager
- #20: Database Level – Good for batch processing, bad for multiuser databases Table Level – the table is locked, no access to any rows in table with another transaction is using table. Caused problems with many transactions are waiting to access the same table – again not suitable for multi-user databases Page Level – A diskpage (page) / diskblock is a directly addressable section of a disk. A page has a fixed size (4K, 8K, etc) A table can span several pages, a page can contains several rows from one or more tables. Row Level – Much less restrictive, allows concurrent transactions to access different rows of same table However, HIGH OVERHEAD COST because a lock must exist for every row in every table of the database Field Level – Allows access to the same row as long as accessing different attributes. MOST flexible, HIGHEST overhead
- #24: 2 Transactions cannot have conflicting locks No unlock operation can precede a lock operation in the same transaction No data is modified until all locks are obtained.
- #26: Choice of best method depends on the needs and probability of deadlocks within the database