IBM Software Group

Introduction To IBM Universal Database For Linux, UNIX And Windows

11. Concurrency

Olaf Depper ([email protected])

November 2004

2004 IBM Corporation

IBM Software Group

Agenda
 Transactions  Concurrency  Isolation Levels  Locking  Monitoring Locks

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

DB2 Call Level Interface

 DB2 Call Level Interface (DB2 CLI) is a callable SQL interface to the DB2 family of database servers  It is a 'C' and 'C++' application programming interface for relational database access that uses function calls to pass dynamic SQL statements as function arguments  Used by SAP applications to access DB2 data bases

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

CLI Applications - Cursor

 A CLI application uses a cursor to retrieve rows from a result set A cursor is a moveable pointer to a row in the result table of an active query statement A cursor is opened when a dynamic SQL SELECT statement is successfully executed by SQLExecute() or SQLExecDirect()  There are two types of cursors supported by DB2 CLI: Forward-only non-scrollable cursors are the default cursor type used by the DB2 CLI driver Two types of scrollable cursors: Static: read-only cursor Keyset-driven scrollable cursor can detect and make changes to the underlying data
Introduction To DB2 11. Concurrency November 2004 2003 IBM Corporation

IBM Software Group

Concurrency

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Concurrency Transactions
 A transaction (otherwise known as a unit of work) is a recoverable sequence of one or more SQL operations grouped together as a single unit, usually within an application process  Transactions are terminated by executing either the COMMIT or the ROLLBACK statement A commit or rollback operation only affects changes that are made within the transaction that the commit or rollback operation ends As long as data changes remain uncommitted, other users and applications are usually unable to see them Once data changes are committed, they can no longer be removed by a rollback operation

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Concurrency Definition
 In a multi-user database environment transactions may execute simultaneously, and each has the potential to interfere with any other transaction that is running  Maintaining database consistency and data integrity, while allowing more than one application to access the same data at the same time, is known as concurrency  When transactions are not isolated from each other in multi-user environments, four types or phenomena can occur

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Concurrency Phenomena
 Lost Update Two transactions read and attempt to update the same data, and one of the updates is lost DB2 does NOT allow this phenomenon to occur  Dirty Read A transaction reads data that has not yet been committed  Nonrepeatable Read A transaction reads the same row of data twice, but gets different data values each time  Phantom A row of data that matches search criteria is not seen initially, but then seen in a later read operation
Introduction To DB2 11. Concurrency November 2004 2003 IBM Corporation

IBM Software Group

Concurrency Isolation Levels

 One of the ways DB2 enforces concurrency is through the use of isolation levels The isolation level determines how data used in one transaction is locked or isolated from other transactions while the first transaction accesses it  DB2 uses the following isolation levels: Repeatable Read (RR) Read Stability (RS) Cursor Stability (CS) Uncommitted Read (UR)

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Concurrency Repeatable Read

 When using Repeatable Read isolation level, all rows referenced by a single transaction are locked for the duration of that transaction Each row referenced by the isolating transaction is locked not just the rows that are actually retrieved and/or modified Other transactions are not allowed to perform insert, update, or delete operations that will affect the set of rows being used as long the isolating transaction exists  Transactions can retrieve the same set of rows multiple times and perform any number of operations on them until terminated by a commit or a rollback operation No lost updates, dirty reads, nonrepeatable reads and phantoms can occur
Introduction To DB2 11. Concurrency November 2004 2003 IBM Corporation

IBM Software Group

Concurrency Read Stability

 When using Read Stability isolation level, all rows that are retrieved by a single transaction are locked for the duration of that transaction Each row read by the isolating transaction cannot be changed by other transactions until the isolating transaction terminates Changes made to other rows by other transactions will not be seen by a transaction running under RS isolation level until they have been committed Therefore SELECT statements will not always yield the same results No lost updates, dirty reads, nonrepeatable reads phantoms, however, may be seen

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Concurrency Cursor Stability

 When using Cursor Stability isolation level, each row that is referenced by a cursor being used by the isolating transaction is locked as long as the cursor is positioned on that row The lock acquired remains in effect either until the cursor is repositioned or until the isolating transaction terminates No other transaction can update or delete that row while the cursor is positioned on it Other transactions can add new rows to the table and perform update and/or delete operations on other rows Transactions using the Cursor Stability isolation level will not see changes made to other rows by other transactions until those changes have been committed  No lost updates and dirty reads cannot occur; nonrepeatable reads and phantoms can and may be seen
Introduction To DB2 11. Concurrency November 2004 2003 IBM Corporation

IBM Software Group

Concurrency Uncommitted Read

 When using Uncommitted Read isolation level, rows that are retrieved by a single transaction are only locked for the duration of that transaction if another transaction attempts to drop or alter the table from which the rows were retrieved Transactions using the UR isolation level can see changes made to rows by other transactions before those changes are committed or rolled back  Commonly used for transactions that access read-only tables and/or transactions that execute SELECT statements on which uncommitted data from other transactions will have no adverse affect Dirty reads, nonrepeatable reads and phantoms can occur

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Choosing An Isolation Level

Isolation Level RR RS CS UR Uncommitted Reads No No No Yes Nonrepeatable Reads No No Yes Yes Phantom Reads No Yes Yes Yes

Transaction Type Read/ Write Read Only

High Data Stability Required RS RR or RS

High Data Stability Not Required CS UR

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Specifying The Isolation Level

 Isolation levels are specified at the application level For CLI (Call Level Interface) applications, the isolation level to be used is set at application run time by calling the SQLSetConnectAttr() function Isolation levels for CLI application can also be set by assigning a value to the TXNISOLATION keyword in the db2cli.ini file With JDBC and SQLJ applications, the isolation level is set at application run time by calling the setTransactionIsolation() method that resides within the java.sql connection interface On DB2 CLP execute the CHANGE ISOLATION command within the CLP before making a connection to a database: CHANGE ISOLATION TO [CS|RR|UR|RS]

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Concurrency In A SAP Environment

 Locking situations sometimes by the DB2 locking mechanism, when the optimizer access plan contains a range scan (table scan, index range scan)
Usage in SAP application Standard isolation level: all normal SELECT statements run with UR All UPDATE and DELETE statements; also certain SELECT statements SELECT FOR UPDATE Not used

DB2 Isolation Level UR CS RS RR

UOW 1: UPDATE customer SET address=? WHERE CuNo = 5

Lock wait /Deadlock

DB2 oc CuNo 1 3 5 name Mi er i er one address E m Str 5 Main d 1 Bd3

UOW 2: UPDATE customer SET address=? WHERE CuNo = 7

DB2 registry settings: V7.2: DB2_RR_TO_RS=ON V8.1.4: DB2_SKIP_DELETED=ON, DB2_EVALUNCOMMITTED=ON

Introduction To DB2 11. Concurrency November 2004 2003 IBM Corporation

IBM Software Group

Locks

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

How Locking Works

 DB2 isolates transactions from each other through the use of locks  A lock is a mechanism that is used to associate a data resource with a single transaction, with the purpose of controlling how other transactions interact with that resource while it is associated with the owning transaction  Once a lock is acquired, it is held until the owning transaction is terminated; at that point, the lock is released and the data resource is made available to other transactions

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Transactions Commit
START TRANSACTION END TRANSACTION

SQL Operation SQL Operation SQL Operation ROLLBACK

Miller Jones Smith

TIME
Locks are acquired at the start of and throughout the life of the transaction When the COMMIT statement is executed all changes are made permanent Locks are released when the transaction is terminated (by the COMMIT statement

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Transactions Rollback
START TRANSACTION END TRANSACTION

SQL Operation SQL Operation SQL Operation ROLLBACK

TIME
Locks are acquired at the start of and throughout the life of the transaction When the ROLLBACK statement is executed all changes are backed out and the database is rolled back to the state it was in before the transaction began Locks are released when the transaction is terminated (by the ROLLBACK statement

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Lock Attributes
 All locks have the following basic attributes: Object: Identifies the data resource that is being locked, such as tablespaces, tables, and rows Size: specifies the physical size of the portion of the data resource that is being locked Duration: Specifies the length of time for which a lock is held (usually controlled by a transaction's isolation level) Mode: Specifies the type of access allowed for the lock owner as well as the type of access permitted for concurrent users of the locked data resource This attribute is commonly referred to as the lock state

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Lock States Types Of Locks (1/4)

Lock Mode IN (Intent None) Applicable Object Type Table Spaces, blocks*, tables Description The lock owner can read any data in the object, including uncommitted data, but cannot update any of it. Other concurrent applications can read or update the table The lock owner can read data in the locked table, but cannot update this data. Other applications can read or update the table The lock owner and all concurrent applications can read, but not update, the locked row. This lock is acquired on rows of a table, instead of an S lock, where the isolation level of the application is either RS or CS. NS lock mode is not used for next-key locking. It is used instead of S mode during CS and RS scans to minimize the impact of next-key locking on these scans

IS (Intent Share)

Table Spaces, blocks, tables

NS (Next Key Share)

Rows

* Blocks are used in Multi-Dimensional Clustering (MDC) Introduction To DB2 11. Concurrency November 2004 2003 IBM Corporation

IBM Software Group

Lock States Types Of Locks (2/4)

Lock Mode S (Share) Applicable Object Type Rows, blocks, tables Description The lock owner and all concurrent applications can read, but not update, the locked data The lock owner and concurrent applications can read and update data. Other concurrent applications can both read and update the table The lock owner can read and update data. Other concurrent applications can read the table The lock owner can update data. Other units of work can read the data in the locked object, but cannot attempt to update it

IX (Intent Exclusive)

Table Spaces, blocks, tables

SIX (Share with Intent Exclusive)

Tables, blocks

U (Update)

Rows, blocks, tables

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Lock States Types Of Locks (3/4)

Lock Mode NW (Next Key Weak Exclusive) Applicable Object Type Rows Description When a row is inserted into an index, an NW lock is acquired on the next row. For type 2 indexes, this occurs only if the next row is currently locked by an RR scan. The lock owner can read but not update the locked row. This lock mode is similar to an X lock, except that it is also compatible with W and NS locks The lock owner can both read and update data in the locked object. Only uncommitted read applications can access the locked object

X (Exclusive)

Rows, blocks, tables, bufferpools

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Lock States Types Of Locks (4/4)

Lock Mode W (Weak Exclusive) Applicable Object Type Rows Description This lock is acquired on the row when a row is inserted into a table that does not have type-2 indexes defined. The lock owner can change the locked row. To determine if a duplicate value has been committed when a duplicate value is found, this lock is also used during insertion into a unique index. This lock is similar to an X lock except that it is compatible with the NW lock. Only uncommitted read applications can access the locked row This lock is acquired on a table in certain conditions, such as when the table is altered or dropped, an index on the table is created or dropped, or for some types of table reorganization. No other concurrent application can read or update the table.
November 2004 2003 IBM Corporation

Z (Super Exclusive)

Table spaces, tables

Introduction To DB2 11. Concurrency

IBM Software Group

Hierarchy Of Locks

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

DB2 Internal Locks

 In addition to the locks mentioned, DB2 uses different internal locks for certain operations, for example: Internal C: catalog cache usage Internal P: RDS cached package/section Internal V: RDS cached variation Internal S: sequencing lock for managing access plans Internal J: job (used for redistribution) Internal B: online backup (DMS tablespace) Internal O: object table lock for commit sync Internal L:LOB and LF locks Internal: miscellaneous other locks (e.g. REORG, LOAD)

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Lock Compatibility
 Whenever one transaction holds a lock on a data resource and a second transaction requests a lock on the same resource, the DB2 Database Manager examines the two lock states to determine whether or not they are compatible If the state of one lock placed on a data resource enables another lock to be placed on the same resource, the two locks (or states) are said to be compatible  If the locks are compatible, the lock is granted to the second transaction  If however, the locks are incompatible, the second transaction must wait until the first transaction releases its lock before it can gain access to the resource and continue processing

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Lock Type Compatibility

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Lock Conversion
 When a transaction attempts to access a data resource that it already holds a lock on, and the mode of access needed requires a more restrictive lock than the one already held, the state of the lock held is changed to the more restrictive state  The operation of changing the state of a lock already held to a more restrictive state is known as lock conversion Lock conversion occurs because a transaction can hold only one lock on a data resource at a time  Once a lock's state has been converted, the lock stays at the highest state obtained until the transaction holding the lock is terminated

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Lock Escalation
 In order to prevent a specific database agent from exceeding the lock space limitations established, a process known as lock escalation is performed automatically whenever too many locks (of any type) have been acquired Lock escalation is the conversion of several individual row-level locks within the same table to a single table-level lock  A lock is escalated when: The total number of locks held by an application reaches the maximum amount of lock list space available to the application (MAXLOCKS) The lock list space consumed by all applications is approaching the total lock list space (LOCKLIST)
Introduction To DB2 11. Concurrency November 2004 2003 IBM Corporation

IBM Software Group

Lock Escalation Lock Sizes

 All locks require space for storage; because the space available is not infinite, the DB2 Database Manager must limit the amount of space that can be used for locks  The size of the lock is dependent on the mode of DB2 and whether it is the first lock acquired:
DB2 Word Width 32-bit Bytes Per Lock 72 bytes 36 bytes 64-bit 112 bytes 6 bytes Condition First lock on an object Subsequent locks on an object First lock on an object Subsequent locks on an object

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Deadlocks
 A deadlock is created when one application is waiting for another application to release a lock on data. Each of the waiting applications is locking data needed by another application. Mutual waiting for the other application to release a lock on held data leads to a deadlock When a deadlock situation occurs, all transactions involved will wait indefinitely for a lock to be released, unless some outside agent takes action The DB2 deadlock detector checks at preset intervals (DLCHKTIME configuration parameter) whether or not a deadlock situation exists If the deadlock detector discovers a deadlock in the locking subsystem, it selects, terminates, and rolls back one of the transactions involved The victim receives an SQL 911 reason code 2
Introduction To DB2 11. Concurrency November 2004 2003 IBM Corporation

IBM Software Group

Lock Timeouts
 Without some sort of lock timeout detection mechanism in place, a transaction might wait indefinitely for a lock to be released  A lock timeout value can be specified in the database configuration file (LOCKTIMEOUT parameter) This value controls the amount of time any transaction will wait to obtain a requested lock If the desired lock is not acquired before the time interval specified elapses, the waiting application receives an SQL 911 (reason code 68) error and the transaction requesting the lock is rolled back

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Monitoring Locks

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Levels Of Monitoring
 Levels of monitoring Snapshot monitoring at the database, application, transaction and lock levels Event monitoring at the database, connection, transaction and deadlock event levels  Performance considerations what to monitor Lock escalations Deadlocks Lock waits and timeouts

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Locks How To Monitor

 For locks use the lock snapshot: db2 get snapshot for locks on <DBSID>  In a SAP environment use db6util tool to check whether deadlocks or lock waits are occurring: db6util sl  The SAP transaction ST04 offers an single point of control for all relevant data: Lock snapshot output Results of db6util tool DB2 Deadlock Event monitors defined for each SAP system

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation

IBM Software Group

Locks What To Monitor

 Monitor lock escalations if value is high, locklist or maxlocks may need to be increased, or applications tuned  Monitor deadlocks  Monitor lock waits and lock wait time use these two to determine the average wait time for a lock; If high, look for applications with many locks or lock escalations

Introduction To DB2 11. Concurrency

November 2004

2003 IBM Corporation