View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
A shared lock is used when a transaction is reading data, but not updating it. Another transaction can also acquire a shared lock on the same data at the same time.
An exclusive lock is used when a transaction is updating data. When a transaction has an exclusive lock, no other transaction can read or update the data.
DB2 also has an update lock, used when a transaction has indicated its intention of updating data (by selecting or fetching with the FOR UPDATE OF clause). Other transactions can acquire a shared lock (for reading the data only) until the update lock is promoted to an exclusive lock at the time the update actually occurs.
Transaction B Transaction A No No No Exclusive (X) No No Yes Update (U) No Yes Yes Shared (S) Exclusive Update Shared
A situation called a deadlock occurs when when two separate processes compete for resources held by one another.
Program 1 requests a lock for a data page held by Program 2 at the same time that Program 2 requests a lock for a data page held by Program 1. Without outside intervention, each will continue to wait for the other to complete. When DB2 detects a deadlock situation, it chooses one process to be the “victim” and denies that program’s lock request, returning a –911 SQL code. Setting a standard within an organization for the order in which tables are updated can reduce deadlock occurrences. Lock (wait) Deadlock Lock (wait) Update Table A (page 1) Update Table B (page 1) Intermediate processing Intermediate processing Lock established Lock established Update Table B (page 1) Update Table A (page 1) Program 2 Program 1
A timeout, caused by the unavailability of a resource, can be caused by data being locked by another process.
DB2 waits for a specified period of time, then returns a –911 SQL code to the waiting process. Lock is suspended, -911 returned to program 2 Timeout Lock (wait) Update Table B (page 1) Intermediate processing (if a program is not carefully designed, this can include a user’s coffee break!) Lock established Update Table A (page 1) Program 2 Program 1
In reality the locking techniques used by DB2 are much more complex than the concepts described here. The Database Administrator can improve performance by manually adjusting some settings called locking parameters . This is part of a process often called tuning the database.
Locksize. The DBA can specifiy locking at the table, page, or row level. In general, letting DB2 handle the level of locking is best, by specifying LOCKSIZE ANY.
Lock escalation. DB2 can automatically “escalate” locks, replacing many small locks with a single larger lock. (For example, replacing many page locks with a table lock.) The DBA has some control over when this is done.
Number of locks. The DBA can set the number of locks a transaction may have, raising it to encourage complex transactions or lowering it to encourage earlier lock escalation.
Lock timeout. The DBA can adjust the amount of time a process waits for a lock before timing out.
Limit the number of rows accessed by a program by coding predicates to filter unwanted rows. Doing so reduces the number of locks on pages containing rows that are accessed but not required.
Design update programs so the update is as close to the commit point as possible, reducing the time that locks are held. In an online application, make sure user intervention is not required to end a transaction.
Design all application programs to access tables in the same order. Doing so reduces the possibility of deadlock.
Consider what would be the appropriate isolation level for a program you are designing.
Avoid ambiguous cursors by specifying FOR READ ONLY or FOR UPDATE OF column-name .
Use the LOCK TABLE statement with caution.
Use caution when using the CURSOR WITH HOLD clause. This causes locks to be held across commits.