Upload
keartikhajorn-charoenart
View
222
Download
0
Embed Size (px)
Citation preview
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
8/6/2019 DB2 Introduction - 11 Con Currency
2/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
Agenda
Transactions
Concurrency
Isolation Levels
Locking
Monitoring Locks
8/6/2019 DB2 Introduction - 11 Con Currency
3/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
4/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
5/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
Concurrency
8/6/2019 DB2 Introduction - 11 Con Currency
6/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
7/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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/6/2019 DB2 Introduction - 11 Con Currency
8/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
9/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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)
8/6/2019 DB2 Introduction - 11 Con Currency
10/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
11/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
12/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
13/38
8/6/2019 DB2 Introduction - 11 Con Currency
14/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
15/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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]
8/6/2019 DB2 Introduction - 11 Con Currency
16/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
17/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
Locks
8/6/2019 DB2 Introduction - 11 Con Currency
18/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
19/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
20/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
21/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
22/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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)
8/6/2019 DB2 Introduction - 11 Con Currency
23/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
Lock States Types Of Locks (2/4)
LockMode Applicable Object Type Description
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
8/6/2019 DB2 Introduction - 11 Con Currency
24/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
Lock States Types Of Locks (3/4)
LockMode Applicable Object Type Description
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
8/6/2019 DB2 Introduction - 11 Con Currency
25/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
Lock States Types Of Locks (4/4)
LockMode Applicable Object Type Description
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.
8/6/2019 DB2 Introduction - 11 Con Currency
26/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
Hierarchy Of Locks
8/6/2019 DB2 Introduction - 11 Con Currency
27/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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)
8/6/2019 DB2 Introduction - 11 Con Currency
28/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
29/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
Lock Type Compatibility
8/6/2019 DB2 Introduction - 11 Con Currency
30/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
31/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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)
8/6/2019 DB2 Introduction - 11 Con Currency
32/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
33/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
34/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
35/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
Monitoring Locks
8/6/2019 DB2 Introduction - 11 Con Currency
36/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
37/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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
8/6/2019 DB2 Introduction - 11 Con Currency
38/38
IBM Software Group
2003 IBM CorporationIntroduction To DB2 11. Concurrency November 2004
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