Last week we talked about transactions, and some of the trouble you can get into when multiple users are updating the database at the same time. Today we’ll see how DB2 prevents these problems.
As I explained last time, Aaron and Kathy have noted that some of our systems may lend themselves to using UR due to not being updated except during the nightly load.
You have probably experienced a lock when updating a Word doc on the lan, ie the list of new program numbers. You get a msg box saying it is being updated by someone else, would you like a read only copy, or to be notified when it is available for update. Locking can solve all the concurrent transaction problems that we saw last week. Prevents lost updates because two users can’t get the same row at the same time. Prevents uncommitted data, because a second user can’t access an update by a first user until it has been committed. May prevent non-repeatable reads and phantom inserts, depending on our chosen isolation level. However, locking introduces a new problem – it may cause a transaction to wait a long time while the data it requires are locked by other transactions.
1) If the transaction required time for human intervention, such as discussing an order with a customer, all other access to the database would be blocked during that time. 3) Like a block of disk space – some amount of contiguous storage. Our DB2 mainframe pages are 4K. A large table can consist of hundreds or thousands of pages so the chances of two users needing different pages is pretty good, allowing the 2 transactions to proceed in parallel. 4) Sounds unlikely, but happens often with small tables of small records, like code-tables, ie Tracks. Can also happen when you are keeping track of an incremental counter in a table, ie assigning order numbers, a common bottleneck. Row level locking requires more sophisticated techniques and more overhead because instead of locking fixed-size pages, it is locking variable length rows. 5)Locking schemes are very much more complicated than outlined here, and continue to be researched. The description on the following pages is just conceptual.
The chart shows which locks are compatible for 2 transactions. This is very simplified. DB2 has more than 3 types of locks and uses different techniques at different levels of the database. The goal remains the same – to prevent interference between transactions while allowing as much concurrent access as possible, all with the least amount of locking overhead possible.
This is a simple deadlock between two programs. More complex situations can occur where 3 or 4 or more programs can be caught in a cycle of locks.
The length of time it waits is an adjustable parameter. George mentioned that the Human Resources System uses a “pseudo-conversational” style to avoid the user controlling the length of locks.
For example, a bulk update program that walks through every row of the table, will eventually lock the whole table, page by page. The program can be designed to lock the table all at once and process the updates. DB2 may notice “hey, I’m going to wind up locking this whole table” and do it anyway (lock escalation), but you could avoid all the overhead. This statement should be used sparingly and with caution!!
DB2’s locking mechanism is much more complicated than this conceptual description. Latches – a type of lock that takes less overhead to manage. Claims (indicator or flag that a process is going to access a resource.) Drains (turns off prior claims.) Lock Avoidance – a technique of examining the situation, including the transaction log, to see if a lock is really necessary. So, if you ever wonder what Aaron is doing in his spare time… he has tweaked these parameters to help keep us humming happily along. There are many more parameters than are listed here.
So, what does all this mean to me, Joe or Jane Programmer? DB2 and the DBA do most of the work for us. It helps if we remember a few guidelines. Cursor with hold – if you commit in the middle of cursor processing, this holds your place in the cursor.
Example – school calendar table. It is only set up once at the beginning of the school year. Many applications access it for read only. Ie the scheduled nightly batch processing, which has dependencies set up. Ie SASI. It is loaded once per night and not updated.
Database Locking, Part 2
Database Locking, Part 2 Pam Odden
Objectives <ul><li>Understand the concept of locking data </li></ul><ul><li>Learn about the types of locks used by DB2 </li></ul><ul><li>Learn guidelines for designing programs to use locking efficiently </li></ul><ul><li>Learn guidelines for using isolation level UR </li></ul>
Locking <ul><li>All major DBMS products use sophisticated locking techniques to handle concurrent transactions. However, the basic concept is simple: </li></ul><ul><li>As transaction A accesses the database, DB2 automatically locks each part of the data that is retrieved or modified. </li></ul><ul><li>Transaction B proceeds at the same time, and DB2 also locks the parts of the data that it accesses. </li></ul><ul><li>If transaction B tries to access part of the database that has been locked by transaction A, it is blocked, and must wait for the data to be unlocked. </li></ul><ul><li>Locks held by transaction A are released when that transaction completes with a commit or rollback (or perhaps sooner, if the isolation level is CS). </li></ul><ul><li>DB2 then “unblocks” transaction B, allowing it to lock that part of the data on its own behalf. </li></ul>
Locking Levels <ul><li>Locking can be implemented at various levels of the database. </li></ul><ul><li>The entire database could be locked. This would allow the processing of only one transaction at a time, and would probably provide unacceptably slow response time! </li></ul><ul><li>Table-level locking locks only the tables accessed by a transaction. This still leads to slow performance in many applications where users need to share access to the same tables. </li></ul><ul><li>Page-level locking locks individual blocks of data (called “pages”) as they are accessed. Other transactions may lock other pages of the same table for themselves. </li></ul><ul><li>Row-level locking allows two users to access different rows on the same page at the same time. This comes at a cost of increased overhead. </li></ul><ul><li>It is theoretically possible to lock at the data item level, but no commercial database offers this. </li></ul>
Shared and Exclusive Locks <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>Transaction B Transaction A No No No Exclusive (X) No No Yes Update (U) No Yes Yes Shared (S) Exclusive Update Shared
Deadlocks <ul><li>A situation called a deadlock occurs when when two separate processes compete for resources held by one another. </li></ul>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
Timeouts <ul><li>A timeout, caused by the unavailability of a resource, can be caused by data being locked by another process. </li></ul>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
Explicit Locking <ul><li>LOCK TABLE table-name IN (SHARE, EXCLUSIVE) MODE </li></ul><ul><li>A program can explicitly lock an entire table, which may be advisable if it will repeatedly access the table. </li></ul><ul><ul><li>Eliminates the overhead of page-by-page or row-by-row locking </li></ul></ul><ul><ul><li>Eliminates the possibility that another program will lock part of the data, causing it to wait </li></ul></ul><ul><ul><li>Eliminates the possibility of a deadlock forcing the program to start over again </li></ul></ul><ul><li>The LOCK TABLE statement can be coded in a program to lock a table in shared or exclusive mode. </li></ul><ul><li>There is no UNLOCK TABLE statement. The table is unlocked when the transaction is ended by a commit or rollback. </li></ul>
Locking Parameters <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>Lock timeout. The DBA can adjust the amount of time a process waits for a lock before timing out. </li></ul>
Guidelines for Locking <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>Design all application programs to access tables in the same order. Doing so reduces the possibility of deadlock. </li></ul><ul><li>Consider what would be the appropriate isolation level for a program you are designing. </li></ul><ul><li>Avoid ambiguous cursors by specifying FOR READ ONLY or FOR UPDATE OF column-name . </li></ul><ul><li>Use the LOCK TABLE statement with caution. </li></ul><ul><li>Use caution when using the CURSOR WITH HOLD clause. This causes locks to be held across commits. </li></ul>
Guidelines for Isolation Level UR <ul><li>In general, most DB2 applications are not candidates for “dirty reads”. It may be helpful when: </li></ul><ul><li>Access is required to a code table or look-up table, whose data doesn’t change often (like the school calendar table). </li></ul><ul><li>You know your program runs at a time when no other users are accessing the same data. </li></ul><ul><li>You are accessing read-only decision-support data. </li></ul><ul><li>Statistical processing is being performed on a large amount of data. A few uncommitted rows may not be statistically significant. </li></ul><ul><li>A table is used by a single user. </li></ul><ul><li>If you think a new process you are designing, or an existing process you are modifying, qualifies for isolation level UR, ask the DBAs! </li></ul>
Summary <ul><li>Locks are used to control access to data as it is updated. </li></ul><ul><li>DB2 uses different types of locks at different levels of the database to protect data with the least delay to other processes. </li></ul><ul><li>DB2 “times out” a process that has waited for a lock past a specified amount of time. </li></ul><ul><li>DB2 breaks deadlocks by returning a –911 SQL code to one of the deadlocked processes. </li></ul><ul><li>Follow the guidelines! </li></ul><ul><li>Consult the DBA! </li></ul>