DB2 Introduction - 11 Con Currency

8/6/2019 DB2 Introduction - 11 Con Currency

1/38

IBM Software Group

2004 IBM Corporation

Olaf Depper ([email protected]) November 2004

Introduction To IBM Universal Database ForLinux, UNIX And Windows

11. Concurrency


2/38

IBM Software Group

2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004

Agenda

Transactions

Concurrency

Isolation Levels

Locking

Monitoring Locks


3/38

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 passdynamic SQL statements as function arguments

Used by SAP applications to access DB2 data bases


4/38

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 issuccessfully 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


5/38

IBM Software Group


Concurrency


6/38

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 theROLLBACK 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


7/38

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, whileallowing 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


8/38

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


9/38

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 whilethe first transaction accesses it

DB2 uses the following isolation levels:

Repeatable Read (RR)

Read Stability (RS)

Cursor Stability (CS)

Uncommitted Read (UR)


10/38

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 notjust 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 timesand 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


11/38

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 changedby 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 sameresults

No lost updates, dirty reads, nonrepeatable reads

phantoms, however, may be seen


12/38

IBM Software Group


Concurrency Cursor Stability

When using Cursor Stability isolation level, each row that isreferenced by a cursor being used by the isolating transaction islocked 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 cursoris positioned on itOther transactions can add new rows to the table and performupdate and/or delete operations on other rows

Transactions using the Cursor Stability isolation level will not seechanges made to other rows by other transactions until thosechanges have been committed

No lost updates and dirty reads cannot occur; nonrepeatable readsand phantoms can and may be seen


13/38


14/38

IBM Software Group


Choosing An Isolation Level

Isolation Level Uncommitted Reads Nonrepeatable Reads Phantom Reads

RR No No No

RS No No Yes

CS No Yes Yes

UR Yes Yes Yes

Transaction Type High Data Stability Required High Data Stability Not

Required

Read/ Write RS CS

Read Only RR or RS UR


15/38

IBM Software Group


Specifying The Isolation Level

Isolation levels are specified at the application level

For CLI (Call Level Interface) applications, the isolation level tobe used is set at application run time by calling theSQLSetConnectAttr() function

Isolation levels for CLI application can also be set byassigning a value to the TXNISOLATION keyword in thedb2cli.ini file

With JDBC and SQLJ applications, the isolation level is set atapplication 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]


16/38

IBM Software Group


Concurrency In A SAP Environment

DB2 oc CuNo na me a ddre ss1 Mi er E m Str 5

3 i er Main d 1

5 one B d 3

UOW 2:

UPDATE customer

SET address=?

WHERE CuNo = 7

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

UOW 1:

UPDATE customer

SET address=?WHERE CuNo = 5

DB2 Isolation Level Usage in SAP application

UR Standard isolation level: all normal SELECT statements run with UR

CS All UPDATE and DELETE statements; also certain SELECT statements

RS SELECT FOR UPDATE

RR Not used

Locking situations sometimes by the DB2 locking mechanism, when the

optimizer access plan contains a range scan (table scan, index range scan)

Lock wait /Deadlock


17/38

IBM Software Group


Locks


18/38

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 howother 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


19/38

IBM Software Group


Transactions Commit

SQL Operation

SQL Operation

SQL Operation

ROLLBACK

Miller

Jones

Smith

TIMETIME

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

START TRANSACTION END TRANSACTION


20/38

IBM Software Group


Transactions Rollback

SQL Operation

SQL Operation

SQL Operation

ROLLBACK

TIMETIME

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

START TRANSACTION END TRANSACTION


21/38

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 dataresource 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 thelocked data resource

This attribute is commonly referred to as the lock state


22/38

IBM Software Group


Lock States Types Of Locks (1/4)

LockMode Applicable Object Type Description

IN (Intent None) Table Spaces, blocks*, tables The lock owner can read any datain the object, includinguncommitted data, but cannotupdate any of it. Other concurrent

applications can read or update the

table

IS (Intent Share) Table Spaces, blocks, tables The lock owner can read data inthe locked table, but cannot updatethis data. Other applications canread or update the table

NS (Next Key Share) Rows The lock owner and all concurrentapplications can read, but notupdate, the locked row. This lock is

acquired on rows of a table, insteadof an S lock, where the isolationlevel of the application is either RSor CS. NS lock mode is not usedfor next-key locking. It is usedinstead of S mode during CS andRS scans to minimize the impact ofnext-key locking on these scans

* Blocks are used in Multi-Dimensional Clustering (MDC)


23/38

IBM Software Group




S (Share) Rows, blocks, tables The lock owner and all concurrentapplications can read, but notupdate, the locked data

IX (Intent Exclusive) Table Spaces, blocks, tables The lock owner and concurrent

applications can read and updatedata. Other concurrent applicationscan both read and update the table

SIX (Share with Intent Exclusive) Tables, blocks The lock owner can read andupdate data. Other concurrentapplications can read the table

U (Update) Rows, blocks, tables The lock owner can update data.Other units of work can read thedata in the locked object, but

cannot attempt to update it


24/38

IBM Software Group




NW (Next Key Weak Exclusive) Rows When a row is inserted into anindex, an NW lock is acquired onthe next row. For type 2 indexes,this occurs only if the next row iscurrently locked by an RR scan.

The lock owner can read but notupdate the locked row. This lock

mode is similar to an X lock, exceptthat it is also compatible with Wand NS locks

X (Exclusive) Rows, blocks, tables, bufferpools The lock owner can both read andupdate data in the locked object.Only uncommitted readapplications can access the locked

object


25/38

IBM Software Group




W (Weak Exclusive) Rows This lock is acquired on the rowwhen a row is inserted into a tablethat does not have type-2 indexesdefined. The lock owner canchange the locked row. To

determine if a duplicate value hasbeen committed when a duplicate

value is found, this lock is alsoused during insertion into a uniqueindex. This lock is similar to an Xlock except that it is compatiblewith the NW lock. Onlyuncommitted read applications canaccess the locked row

Z (Super Exclusive) Table spaces, tables This lock is acquired on a table incertain conditions, such as whenthe table is altered or dropped, anindex on the table is created ordropped, or for some types of tablereorganization. No other concurrentapplication can read or update thetable.


26/38

IBM Software Group


Hierarchy Of Locks


27/38

IBM Software Group


DB2 Internal Locks

In addition to the locks mentioned, DB2 uses different internal locksfor 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)


28/38

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


29/38

IBM Software Group


Lock Type Compatibility


30/38

IBM Software Group


Lock Conversion

When a transaction attempts to access a data resource that it alreadyholds a lock on, and the mode of access needed requires a morerestrictive lock than the one already held, the state of the lock held ischanged to the more restrictive state

The operation of changing the state of a lock already held to a morerestrictive state is known as lock conversion

Lock conversion occurs because a transaction can hold only onelock 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


31/38

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)


32/38

IBM Software Group


Lock Escalation Lock Sizes

All locks require space for storage; because the space availableis not infinite, the DB2 Database Manager must limit the amountof 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 Bytes Per Lock Condition

32-bit 72 bytes First lock on an object

36 bytes Subsequent locks on an object

64-bit 112 bytes First lock on an object

6 bytes Subsequent locks on an object


33/38

IBM Software Group


Deadlocks

A deadlock is created when one application is waiting for anotherapplication to release a lock on data. Each of the waiting applicationsis locking data needed by another application. Mutual waiting for theother application to release a lock on held data leads to a deadlock

When a deadlock situation occurs, all transactions involved willwait indefinitely for a lock to be released, unless some outsideagent takes action

The DB2 deadlock detector checks at preset intervals(DLCHKTIME configuration parameter) whether or not a deadlocksituation 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


34/38

IBM Software Group


Lock Timeouts

Without some sort of lock timeout detection mechanism in place, atransaction might wait indefinitely for a lock to be released

A lock timeout value can be specified in the database configurationfile (LOCKTIMEOUT parameter)

This value controls the amount of time any transaction will wait toobtain a requested lock

If the desired lock is not acquired before the time interval specifiedelapses, the waiting application receives an SQL 911 (reason code68) error and the transaction requesting the lock is rolled back


35/38

IBM Software Group


Monitoring Locks


36/38

IBM Software Group


Levels Of Monitoring

Levels of monitoring

Snapshot monitoring at the database, application, transactionand lock levels

Event monitoring at the database, connection, transaction anddeadlock event levels

Performance considerations what to monitor

Lock escalations

Deadlocks

Lock waits and timeouts


37/38

IBM Software Group


Locks How To Monitor

For locks use the lock snapshot:db2 get snapshot for locks on

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 toolDB2 Deadlock Event monitors defined for each SAP system


38/38

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 todetermine the average wait time for a lock; If high, look for

applications with many locks or lock escalations

DB2 Introduction - 11 Con Currency

Documents

Transcript of DB2 Introduction - 11 Con Currency