@Sarah
2015-12-05T23:56:42.000000Z
字数 6574
阅读 1063
SQL
Transaction Management
and Concurrency Control
Logical unit of work that must be either entirely completed or aborted
Successful transaction changes 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
Create Invoice (insert)
Create Line(s) (insert)
Update product (update PROD_QOH)
Create Acct_transaction (INSERT)
What if insert acct_transaction fails? The customer paid but it isn’t recorded?
What if prod_qoh update fails?
What if prod_qoh = 1 and transaction 1 takes last product after transaction 2 already checks inventory status?
Atomicity: All operations of a transaction must be completed
Consistency: Permanence of database’s consistent state
Isolation: Data used during transaction cannot be used by second transaction until the first is completed
Durability: Once transactions are committed, they cannot be undone
Serializability: Concurrent execution of several transactions yields consistent results. Multiuser databases are subject to multiple concurrent transactions
ANSI has defined standards that govern SQL database transactions
Transaction support is provided by two SQL statements:
COMMIT and ROLLBACK
Transaction sequence must continue until:
COMMIT statement is reached
ROLLBACK statement is reached
End of program is reached
Program is abnormally terminated
Environment variable – default setting is to OFF
When AUTOCOMMIT is set to ON, every DML statement is written to the disk as soon as it is executed and there is no rollback.
If the system crashes, any statements after the last COMMIT are rolled back, so partial changes to tables are not permanently written.
Before the COMMIT is executed, data is being pulled form the database’s temporary storage area.
Other users cannot view the results of DML queries until the user commits the changes.
Other users cannot change the data in the locked rows.
After a COMMIT, the changes become permanent, all users can view the changes, locks are released.
A record for the beginning of transaction
For each transaction component:
Type of operation being performed (update, delete, insert)
Names of objects affected by transaction
“Before” and “after” values for updated fields
Pointers to previous and next transaction log entries for the same transaction
Ending (COMMIT) of the transaction
Ensures database integrity – entity integrity, referential integrity and attribute integrity.
Coordination of simultaneous transaction execution in a multiprocessing database
Objective is to ensure serializability of transactions in a multiuser environment
Three main problems:
Lost updates
Uncommitted data
Inconsistent retrievals
Lost update problem:
Two concurrent transactions update same data element
One of the updates is lost, overwritten by the other transaction
Lost Update
Uncommitted data phenomenon:
Two transactions are executed concurrently
First transaction rolled back after second already accessed uncommitted data
Uncommitted data
Inconsistent retrievals:
First transaction accesses data
Second transaction alters the data
First transaction accesses the data again
Transaction might read some data before they are changed and other data after changed
Yields inconsistent results
The Scheduler
Special DBMS program
Purpose is to establish order of operations within which concurrent transactions are executed
Interleaves execution of database operations:
Ensures serializability
Ensures isolation
Serializable schedule
Interleaved execution of transactions yields same results as serial execution
Concurrency Control
with Locking Methods
Guarantees exclusive use of a data item to a current transaction
Required to prevent another transaction from reading inconsistent data
Pessimistic locking
Use of locks based on the assumption that conflict between transactions is likely
Lock manager
Responsible for assigning and policing the locks used by transactions
Lock Granularity
Indicates level of lock use
Locking can take place at following levels:
Database
Table
Page
Row
Field (attribute)
Lock Granularity (cont’d.)
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 same table, even if rows are located on same page
Field-level lock: Allows concurrent transactions to access same row, requires use of different fields (attributes) within the row
Binary lock
Two states: locked (1) or unlocked (0)
Exclusive lock
Access is specifically reserved for transaction that locked object
Must be used when potential for conflict exists
Shared lock
Concurrent transactions are granted read access on basis of a common lock
Two-Phase Locking
to Ensure Serializability
Defines how transactions acquire and relinquish locks
Guarantees serializability, but does not prevent deadlocks
Growing phase: Transaction acquires all required locks without unlocking any data
Shrinking phase: Transaction releases all locks and cannot obtain any new lock
Governed by the following rules:
Two transactions cannot have conflicting locks
No unlock operation can precede a lock operation in the same transaction
No data are affected until all locks are obtained
Deadlocks
Condition that occurs when two transactions wait for each other to unlock data
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
Deadlocks
Three techniques to control deadlock:
Prevention
Detection
Avoidance
Choice of deadlock control method depends on database environment
Low probability of deadlock; detection recommended
High probability; prevention recommended
Locking in Oracle
User does not have to write any explicit statements to lock tables.
Oracle uses automatic locking with the least restrictions.
2 lock classes – exclusive and shared.
Exclusive prevents sharing a resource until a lock is released.
Shared allows sharing for read only purposes.
Database Recovery Management
Restores database to previous consistent state
Based on atomic transaction property
All portions of transaction are treated as single logical unit of work
All operations are applied and completed to produce consistent database
If transaction operation cannot be completed:
Write-ahead-log protocol: ensures transaction logs are written before data is updated
Redundant transaction logs: ensure physical disk failure will not impair ability to recover
Buffers: temporary storage areas in primary memory
Checkpoints: operations in which DBMS writes all its updated buffers to disk
Transaction Recovery
Deferred-write technique
Only transaction log is updated
Recovery process: identify last checkpoint
If transaction committed before checkpoint: Do nothing
If transaction committed after checkpoint: Use transaction log to redo the transaction
If transaction had ROLLBACK operation: Do nothing
Write-through technique
Database is immediately updated by transaction operations during transaction’s execution
Recovery process: identify last checkpoint
If transaction committed before checkpoint: Do nothing
If transaction committed after last checkpoint: DBMS redoes the transaction using “after” values
If transaction had ROLLBACK or was left active: Do nothing because no updates were made