DBMS2
DBMS2
What is a Transaction?
Any action that reads from and/or writes to a database may consist of
Simple SELECT statement to generate a list of table contents A series of related UPDATE statements to change the values of attributes in various tables A series of INSERT statements to add rows to one or more tables A combination of SELECT, UPDATE, and INSERT statements
What is a Transaction?
A logical unit of work that must be either entirely completed or aborted Successful transaction changes the database from one consistent state to another
One in which all data integrity constraints are satisfied
Most real-world database transactions are formed by two or more database requests
The equivalent of a single SQL statement in an application program or transaction
Transaction Processing
For example, a transaction may involve
The creation of a new invoice Insertion of an row in the LINE table Decreasing the quantity on hand by 1 Updating the customer balance Creating a new account transaction row
If the system fails between the first and last step, the database will no longer be in a consistent Figure 9.2 state
Transaction Properties
Atomicity
Requires that all operations (SQL requests) of a transaction be completed; if not, then the transaction is aborted A transaction is treated as a single, indivisible, logical unit of work
Indicates permanence of databases consistent state When a transaction is complete, the database reaches a consistent state. That state can not be lost even if the system fails
Durability
Transaction Properties
Serializability
Ensures that the concurrent execution of several transactions yields consistent results Multiple, concurrent transactions appear as if they executed in serial order (one after another)
Isolation
Data used during execution of a transaction cannot be used by second transaction until first one is completed
ANSI standards require that, when a transaction sequence is initiated by a user or an application program,it must continue through all succeeding SQL statements until one of four events occurs
Increases processing overhead but the ability to restore a corrupted database is worth the price
A Transaction Log
Concurrency Control
The coordination of the simultaneous execution of transactions in a multiprocessing database is known as concurrency control The objective of concurrency control is to ensure the serializability of transactions in a multiuser database environment
Concurrency Control
Important simultaneous execution of transactions over a shared database can create several data integrity and consistency problems The three main problems are:
lost updates uncommitted data inconsistent retrievals
Lost Updates
Inconsistent Retrievals
The Scheduler
Special DBMS program: establishes order of operations within which concurrent transactions are executed Interleaves the execution of database operations to ensure serializability and isolation of transactions
To determine the appropriate order, the scheduler bases its actions on concurrency control algorithms such as locking and time stamping
Facilitates data isolation to ensure that two transactions do not update the same data element at the same time
Transactions T1 and T2 are executing concurrently over the same data When they both access the data and at least one is executing a WRITE, a conflict can occur
Lock
Lock manager
T2 does not have access to a data item that is currently being used by T1 Transaction acquires a lock prior to data access; the lock is released when the transaction is complete
Responsible for assigning and policing the locks used by the transactions
Indicates the level of lock use Locking can take place at the following levels:
Lock Granularity
Database-level lock Entire database is locked Table-level lock Entire table is locked Page-level lock Entire diskpage is locked Row-level lock Allows concurrent transactions to access different rows of the same table, even if the rows are located on the same page Field-level lock Allows concurrent transactions to access the same row, as long as they require the use of different fields (attributes) within that row
Good for batch processing but unsuitable for online multi-user DBMSs T1 and T2 can not access the same database concurrently even if they use different tables
Table-Level Lock
T1 and T2 can access the same database concurrently as long as they use different tables Can cause bottlenecks when many transactions are trying to access the same table (even if the transactions want to access different parts of the table and would not interfere with each other) Not suitable for multi-user DBMSs
Page-Level Lock
An entire disk page is locked (a table can span several pages and each page can contain several rows of one or more tables) Most frequently used multi-user DBMS locking method
Row-Level Lock
Concurrent transactions can access different rows of the same table even if the rows are located on the same page Improves data availability but with high overhead (each row has a lock that must be read and written to)
Field-Level Lock
Allows concurrent transactions to access the same row as long as they require the use of different fields with that row Most flexible lock buy requires an extremely high level of overhead
Binary Locks
Has only two states: locked (1) or unlocked (0) Eliminates Lost Update problem the lock is not released until the write statement is completed
Can not use PROD_QOH until it has been properly updated
Considered too restrictive to yield optimal concurrency conditions as it locks even for two READs when no update is being done
Exclusive lock
Shared/Exclusive Locks
Access is specifically reserved for the transaction that locked the object Must be used when the potential for conflict exists when a transaction wants to update a data item and no locks are currently held on that data item by another transaction Granted if and only if no other locks are held on the data item
Shared lock
Concurrent transactions are granted Read access on the basis of a common lock Issued when a transaction wants to read data and no exclusive lock is held on that data item
Multiple transactions can each have a shared lock on the same data item if they are all just reading it
Shared/Exclusive Locks
Increased overhead
The type of lock held must be known before a lock can be granted Three lock operations exist: READ_LOCK to check the type of lock WRITE_LOCK to issue the lock UNLOCK to release the lock A lock can be upgraded from share to exclusive and downgraded from exclusive to share
Defines how transactions acquire and relinquish locks Guarantees serializability, but it does not prevent deadlocks
Growing phase, in which a transaction acquires all the required locks without unlocking any data Shrinking phase, in which a transaction releases all locks and cannot obtain any new lock
Condition that occurs when two transactions wait for each other to unlock data
T1 needs data items X and Y; T needs Y and X Each gets the its first piece of data but then waits to get the second (which the other transaction is already holding) deadly embrace
Deadlocks
Possible only if one of the transactions wants to obtain an exclusive lock on a data item
No deadlock condition can exist among shared locks
Control through
Prevention Detection Avoidance
Produces an explicit order in which transactions are submitted to the DBMS Uniqueness
Ensures that no equal time stamp values can exist
Monotonicity
Ensures that time stamp values always increase
Disadvantage
Each value stored in the database requires two additional time stamp fields last read, last update
Wait/die
Older transaction waits and the younger is rolled back and rescheduled
Wound/wait
Older transaction rolls back the younger transaction and reschedules it
In the situation where a transaction is requests multiple locks, each lock request has an associated time-out value. If the lock is not granted before the time-out expires, the transaction is rolled back
Validation phase transaction is validated to ensure that the changes made will not affect the integrity and consistency of the database
If the validation test is positive, the transaction goes to the writing phase. If negative, the transaction is restarted and the changes discarded
If transaction operation cannot be completed, transaction must be aborted, and any changes to the database must be rolled back (undone)
Transaction Recovery
The database recovery process involves bringing the database to a consistent state after failure. Transaction recovery procedures generally make use of deferred-write and write-through techniques
Transaction Recovery
Deferred write
Transaction operations do not immediately update the physical database Only the transaction log is updated Database is physically updated only after the transaction reaches its commit point using the transaction log information If the transaction aborts before it reaches its commit point, no ROLLBACK is needed because the DB was never updated A transaction that performed a COMMIT after the last checkpoint is redone using the after values of the transaction log
Transaction Recovery
Write-through
Database is immediately updated by transaction operations during the transactions execution, even before the transaction reaches its commit point If the transaction aborts before it reaches its commit point, a ROLLBACK is done to restore the database to a consistent state
A transaction that committed after the last checkpoint is redone using the after values of the log A transaction with a ROLLBACK after the last checkpoint is rolled back using the before values in the log