第５章ロック内容

by user

on 15 сентября 2016

Category: Documents

>> Downloads: 3

views

Report

Comments

Description

Download 第５章ロック内容

Transcript

第５章ロック内容

DB2 UDB (PC&Unix) デザイン・ガイド
ロック
第５章
ロック
お断り：当資料は、DB2 UDB V7.1（AIX,NT,OS2) をベースに作成されています。
＜第１．００版＞２００１年３月
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
内容
１．ロックの必要性
２．ロックのしくみ
２−１．ロックの対象
２−２．ロックの保持期間
２−３．ロックの範囲
２−４．ロックのモード
２−５．ロックの互換性
２−６．ロックの変換
３．ロック・エスカレーション
４．ロック待機とロック・タイムアウト
５．デッドロック
６．ロックに関するモニタリング
７．Next Key Locking
８．ユーティリティーにおける排他制御
９．ロックを制御する指定
１０．いろいろな機能とロック
１１．Quiesce
１２．ロックのまとめ
当資料の内容は、DB2 UDB V7.1を対象としたテスト結果からまとめたものです。
ロックの動作が将来にわたって不変であることは保証されないことを、ご了承下さい。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 1-2 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
１．ロックの必要性
ロックの目的
マルチ･ユーザー環境でデータを共用するために、データへのアクセスを制御し、望ましくない
現象を発生させないようにするため
望ましくない現象とは
更新喪失/二重更新
未コミットデータの読取り
反復不能読取り
幻像読取り
ロックの制御はロック・
マネージャーが行う
EEE環境でのロック
ロックは特定のパーティションに対して行われるものであり、他のパーティションに直接影響を
与えない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロックの必要性
DB2は、コミットされたデータは保存され、コミットされていない変更は保存されないことを保証しなければなりません。
データが変更された場合、その変更が上書きされないことを保証し、変更後の内容が次のトランザクションから照会するができる必
要があります。
さらに、SELECTを行った時には、トランザクション終了まで、全行が使用可能であることを保証することが必要な時があります。
照会条件と一致している、新規に追加された行を検索することが要求される場合もあります。
管理者/プログラマー/ユーザーはこれらの状況を理解し、データの処理方法としてどのような状態が望まれているかを判断する必
要があります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 3-4 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
更新の紛失(Lost Updates)
ある更新処理による更新データが確定される前に、他の更新処理によ
り変更されてしまう
DB2ではこの現象は発生しない
Reservations
Flight
512
Seat
7C
512
7B
P_Name
...
...
...
更新プログラム１
更新プログラム２
Update Reservations
Set P-name = 'Instruct'
Where Flight = 512
and Seat = '7C'
and P_name is NULL
512
7C
?
Instruct ...
Update Reservations
Set P-name = 'Manager'
Where Flight = 512
and Seat = '7C'
and P_Name is NULL
512
7C Manager
...
2番目の変更が1番目の変更を上書き
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：更新の紛失
更新喪失は、以下の場合に起こり得ます。
1. トランザクション1が、列の値を指定してレコードをselectする
2. トランザクション2が、列の値を指定して同じレコードをｓｅｌ
ｅ
ｃ
ｔ
する
3. トランザクション1が、レコードを更新する
4. トランザクション1は、レコードをロックしない
5. トランザクション2が、同じレコードを更新する
この場合、トランザクション1による更新は失わます。
DB2では更新喪失は起こり得ません。なぜなら、データの整合性を保証するためのロック・メカニズムを組み込んでいるからで
す。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 5-6 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
未コミットデータへのアクセス
コミット前のデータを読み取ってしまい、更新データがロールバックされ
た場合には、読取りデータは実際とは異なるデータとなる
Reservations
Flight
512
Seat
7C
512
7B
...
...
P_Name
プログラム１
1
Update
Reservations
Set P-name =
'Instruct'
Where Flight = 512
and Seat = '7C'
and P_Name is NULL
3
プログラム２
2 Select seat
From Reservations
Where P-name is NULL
512
7C
Instruct
Roll back
4 正しくない結果セット
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：未コミットデータへのアクセス
未コミットデータへのアクセスは次の状況で発生します。
1. トランザクション１が、レコードを更新する
2. トランザクション２が、非コミット読み取りを行う
述部の条件に合致しないために、ステップ1の更新行はＳＥＬＥＣＴされない
3. トランザクション１が，ロールバックを行う
4. トランザクション２は結果として、正しくない結果を得ることになる
（ロールバック後のデータは、検索条件に合致していたかもしれない。）
UNCOMMITTED READが望ましい場合もあります。
例:
予約システムで、すばやく可能な行をSELECTし、アサインし、確定は後で行ってもかまわない
今の状況をとりあえず確認したい
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 7-8 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
反復不可能読取り(Non Repeatable Reads)
１つの作業単位内で、同じSELECT文が実行された場合に、同じ照会
結果が保証されない
Reservations
Flight
512
Seat
7C
512
7B
...
...
P_Name
プログラム１
プログラム２
1
Select seat
From Reservations
Where P-name is NULL
and Flight = '512'
3
１のSELECT文を再度
実行すると、Seatが
'7C'の行は戻されない
512
7C
-------
512
7B
-------
2Update Reservations
Set P-name =
'Instruct'
Where Flight = 512
and Seat = '7C'
and P_Name is NULL
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：反復不可能読み取り
反復可能読取りは、「同一作業単位内においては、SQLの再実行が一度以上行われた場合、毎回正確に同一な結果セットを返すこ
と」を保証します。反復不可能読み取りは、これを保証しません。
反復可能読取りはその結果セットを保証するために、SQL文の結果が変わってしまう insert / update / delete は許されません。
この例で、８１４便の席８Ａが他の人にアサインされた場合、反復可能読み取りによる照会結果の保証はされなくなり、反復不可能
読み取りとなります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 9-10 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
幻像読取り(Phantom Reads)
同一作業単位内で、同じSELECT文を実行した場合に、他の更新処理
により条件に合致するようになったデータまで照会結果に入る
Reservations
Flight
512
Seat
7B
P_Name
512
7A
Dwaine
...
...
プログラム２
2 Update Reservations
Set P-name = 'NULL'
Where Flight = 512
and Seat = '7A'
and P_Name = 'Dwaine'
プログラム１
1 Select seat
From Reservations
Where P-name is NULL
512
7B
3 1のＳＱＬ文を再度実行すると、
７Aはアサイン可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：幻像読み取り
幻像読取りとは、反復不可能読取りの一種で、同一作業単位内において２回目の照会の際に、１回目と同じデータ＋追加のデータ
を戻します。
例：
ｐａｓｓｅｎｇｅｒ名がＮＵＬＬである席を照会
別のトランザクションが、別のレコードをＮＵＬＬに更新
再びステートメントを実行すると、追加のレコードも返ってくる
アプリケーションの要件によっては、こういう結果が望ましい場合もあります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 11-12 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
２．ロックのしくみ
2-1.ロックの対象
2-2.ロックの保持期間
2-3.ロックの範囲
2-4.ロックのモード
2-5.ロックの互換性
2-6.ロックの変換
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 13-14 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
2-1.ロックの対象
ロックの対象となるもの：行、表、表スペース
照会・更新のアプリケーション実行時には、行・表単位のロックが取得される
ユーティリティーの実行時には、行・表・表スペース単位のロックが取得される
索引にロックは取得しない
行ロックと表ロックの比較
アプリケーション要件により、ロックの単位を設定することが可能
ロック
CPU負荷
アプリケーションの同時
稼動性
用途
行ロック
ロックを取得・解放する回数が多くなるた
め、負荷は高い
ロックの範囲が狭いので、同時稼動性は
高い
-アプリケーションの同時稼動性を高めた
い場合
-ロックを取得する行数が少ない場合
表ロック
ロックを取得・解放する回数が少ないの
で、負荷は低い
ロックの範囲が広いので、同時稼動性は
低い
-表が照会専用の場合
-他のアプリケーションを待たせてでも、あ
るアプリケーションのみ先に処理を完了さ
せたい場合
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 15-16 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ロックの単位を制御
ロックの単位を表ごとに設定可能
ALTER TABLEステートメントの LOCKSIZEオプション
ROW ：行単位でのロック（省略時値）
TABLE ：表単位でのロック
プログラムから明示的に表ロックの取得が可能
LOCK TABLE 表名 IN SHARE MODE：表に共用ロックを取得
LOCK TABKE 表名 IN EXCLUSIVE MODE：表に排他ロックを取得
LOCKSIZEオプションとLOCK TABLEステートメントの比較
ロックを制御する方法
ALTER TABLE ...
LOCKSIZE xxxx
影響の範囲
設定の持続性
その表にアクセスする全トランザクション
永続的
考慮点
LOCK TABLE ...
IN xxxx MODE
単一のトランザクション
一時的
LOCK TABLE による活動化
COMMIT あるいは ROLLBACKによる非活
動化
表の存在する表スペースのポイント・イン・回復可能最短時間には影響を与えない
タイム回復の回復可能な最短時間に影響
を与える
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロックの単位を制御
ALTER TABLEステートメントのLOCKSIZEオプションは、V5のFixPak3で使用可能です。表をアクセスするときに使用されるロックの
サイズを指定することが可能です。省略時では、表が作成されるときに、ロックサイズは行レベルロックを取るように設定されていま
す。ALTER TABLEステートメントで表を変更し、ロックの設定を表レベルにあげることができます。表レベルのロックを設定し、取得・
解放されるロックの数を減らすことにより、照会処理のパフォーマンスが向上する可能性があります。しかし、表全体にロックが取得
されるため、同時稼動性は落ちます。
一度、設定を可能にした後は、その表に関する後続のトランザクションが表にアクセスする時に使用されるロックのサイズは、指定し
たロックモードで処理されます。表定義におけるこのオプションを使用することで、通常のロック・エスカレーションの発生を押さえるこ
とにはなりません。また、LOCK TABLEステートメントは、表スペースのポイント・イン・タイム回復が可能であることに何も影響を与え
ないのに対して、ALTER TABLEステートメントは、ポイント・イン・タイムで回復可能な時点に関連します。
ＲＯＷ
行ロックを取ることを意味します。表が作成されるときのロック・サイズの省略時値です。
ＴＡＢＬＥ
表ロックを取ることを意味します。適切な、共用または排他ロックが表に取られ、意図ロックは使用されません。この値を使用し、
取得が必要なロックの数を減らすことにより、照会のパフォーマンスを向上させる可能性があります。しかし、ロックは表全体に
取られるので、同時稼動性は落ちます。以下の場合には、表ロックを使用するほうが良いでしょう。
表が読み取りのみで、常にＳロックが必要である。他のトランザクションがその表にＳロックを取得することが可能であるた
め、表レベル・ロックはパフォーマンスを向上させます。
ある１人のユーザーが保守のために表にアクセスし、限られた時間内でＸロックを取得します。その表にALTER TABLEによ
り表レベル・ロックを定義することにより、表レベルのＸロックを取得可能にします。その人の作業が一旦終了してしまえば、
ALTER TABLEを使用して、行レベル・ロックを取得するように表の設定を戻すことができます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 17-18 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
2-2.ロックの保持期間
ロックの長さ
作業単位が完了（ＣＯＭＭＩ
Ｔ／ＲＯＬＬＢＡＣＫ）するまで保持される
WITH HOLD付きのカーソルを使用した場合には、カーソル位置へのロックは外されない
ISOLATION＝CSの照会処理では、カーソル位置のみにロックが取得される
カーソルをＣＬＯＳＥしても、ロックははずれない
RR,RSのアプリケーションによるRead Lockについては、CLOSE CURSORのWITH RELEASEオプションを使用するこ
とにより、CLOSE時に解放することが可能
NWロックだけは瞬間ロックであり、作業単位を待たずに解放される
NWロックの解放を待つためにロック待機（LOCK_WAIT)することはない
NWロック：索引のあるユーザー表にINSERTを行った時に、索引キーの次の行に取られるNext Keyロック
11 1 2
1
10
2
3
9
4
8
7
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 19-20 )
6
5
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
2-3.ロックの範囲
ISOLATION(分離）レベルによりロックが保持される範囲を設定
（注: * は対応するISO SQL Isolation Level )
RR (Repeatable Read)：反復可能読み取り
(* Serializable)
RS (Read Stability)：読み取り固定
(* Repeatable Read)
CS (Cursor Stability)：カーソル固定（省略時値） (* Read Committed)
UR (Uncommitted Read)：未コミット読み取り
(* Read Uncommitted)
ISOLATIONレベルによる照会処理時のロック取得の違い
RRの場合のロック取得行
Table1
col1
100
200
300
400
.....
.....
col2
A01
A02
A01
B00
.....
.....
col3
700
800
750
600
.....
.....
select col2 from table1
where col1 between 100 and 350
and col3 >= 750
A01
A02
A01
B00
700
800
750
600
検索行全てにロック
次の索引キーの行にもロック
RSの場合のロック取得行
結果行
200
300
100
200
300
400
200
300
A02 800
A01 750
A02 800
A01 750
結果行にロック
CSの場合のロック取得行
200
索引列
A02 800
URの場合のロック取得行
なし
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロックの範囲
ISO標準とは、ISOLATIONレベルの名前が異なります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 21-22 )
カーソル位置にロック
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ISOLATIONレベルの比較
照会処理時のロック取得
更新された行については、作業単位完了(COMMIT/ROLLBACK)までロックを取得する
照会行については、ISOLATIONによりロックの取得範囲と保持期間が異なる
ISOLATION
RR
RS
CS
UR
ロックの範囲
作業単位内で走査した全て
の行、および索引キーの次
の行
作業単位内で参照し
た結果行
カーソルがおかれた
行のみ
ロックを取得しない
未コミットデータへの
アクセス
×
×
×
〇
反復不可能読み取り
×
×
〇
〇
幻像読み取り
×
〇
〇
〇
照会行へのロック
（Read Lock)の保持
期間
他のアプリケーション
への影響
作業単位内
作業単位内
カーソルが次の行に
進むまで
更新時の照会処理
のロックはCSと同じ
作業単位内で走査した全て
の行への更新処理が不可能
同一作業単位内で実行され
たSELECT文には必ず同じ結
果行が戻される
多くの行ロックを取得し、
locklistの不足からロック・エ
スカレーションが発生する可
能性あり
カーソルがおかれた
行への更新処理は不
可能
コミット行のみを照会
する場合において最
高の同時稼動性
反復不可能読み取り
と幻像読み取りが発
生すること
更新時の照会処理
のロックはCSと同じ
長所
作業単位内で参照し
た結果行への更新処
理が不可能
高い同時稼動性と結
果行の保持
考慮点
幻像読み取りが発生
すること
ロックの負荷がない
同時稼動性が高い
更新処理時のロック
は、CSと同じ
DROP/CREATE中の
表・視点・索引には
アクセス不可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ISOLATIONレベルの比較
ISOLATIONの違いにより、ロックの動作は大きく異なります。アプリケーション要件に適したISOLATIONレベルを選択することが必要
です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 23-24 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ISOLATIONレベルの選択
アプリケーションのタイプによるISOLATIONレベルの選択
アプリケーション要件により、ISOLATIONレベルを選択する
アプリケーションのタイプ
データの保持が要求される
データの保持が要求されない
Read-Write
Read-Only
RS
RR
CS
UR
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 25-26 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ISOLATIONレベルの設定
設定方法
埋め込みSQL
PREP/BINDコマンドのISOLATIONオプション（BIND時に指定しない場合には、PREP時の設定が有効となる）
CLI、ODBCアプリケーション
db2cli.iniファイルに設定する方法
TXNISOLATION ＝１２８１６３２
（１：UR、２：CS、８：RR、１６：RS、３２：NC ＊NCはAS/400版のみ）
アプリケーションで設定する方法
SQL_SetConnectAttr() のSQL_ATTR_TXN_ISOLATIONオプションまたは
SQL_SetStmtAttr() のSQL_ATTR_STMTTXN_ISOLATIONオプション UR: SQL_TXN_READ_UNCOMMITTED
CS: SQL_TXN_READ_COMMITED
RS: SQL_TXN_REPEATABLE_READ
RR: SQL_TXN_SERIALIZABLE
NC: SQL_TXN_NOCOMMIT
JDBCアプリケーション
Connection.TRANSACTION_READ_UNCOMMITED = Uncommitted Read（非コミット読取り）
Connection.TRANSACTION_READ_COMMITTED = Cursor Stability（カーソル固定）
Connection.TRANSACTION_REPEATABLE_READ = Read Stability（読み取り固定）
Connection.TRANSACTION_SERIALIZABLE = Repeatable Read（反復可能読取り）
Connection.TRANSACTION_NONE = DB2 UDBでは、サポートされておらず、指定するとエラー
CLP（コマンド行プロセッサー）
CHANGE ISOLATION TO [ CS | RR | RS | UR | NC ]
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 27-28 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ISOLATIONレベルの確認
確認方法
SYSCAT.PACKAGES表のISOLATION列を参照する
（例） PKGNAMEにはパッケージ名、PKGSCHEMAにはパッケージのスキーマ名を英大文字で指定
SELECT ISOLATION FROM SYSCAT.PACKAGES WHERE PKGNAME='xxxxx' AND PKGSCHEMA='yyyyy'
db2bfdコマンドによりバインド・ファイルのヘッダー部分を画面出力する
（例） -bオプションにより、バインド・ファイルのヘッダー部分が表示可能
db2bfd -b ファイル名.bnd
画面出力例： Isolationの部分のみを抜粋
isol_value
Isolation option
:2: Uncommitted Read (Defined)
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ISOLATIONレベルの確認
ｄｂ２ｂｆ
ｄコマンドにより、バインド・ファイルの内容を見ることができます。バインド時に指定されたオプションを確認する際に有効で
す。
db2bfd -h によりヘルプ画面（テキスト）を表示することができます。
＜ヘルプの出力＞db2bfd -h
Usage: db2bfd [ [-b] [-h] [-s] [-v] ] <filespec>
Where: <filespec> is a bind file
Options: -b = display bind file header
-h = display this information
-s = display SQL statements
-v = display host variable declarations
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 29-30 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
2-4.ロックのモード（１）
ロックのモード
排他制御を行うために、ロックに与えられた性質
ISOLATION（分離レベル）とアクセス・
パスによりロック・
モードが決まる
大別すると、共用(Shared)ロックと排他(Exclusive)ロック
共用(Shared))ロック：照会処理時に取得されるロック
排他(Exclusive)ロック：更新処理時に取得されるロック
取得済みのロック
排他（X)
取得要求
されたロック共用（
S)
排他（X)
×
×
共用（S)
×
〇
〇：
取得可能 ×：
取得不可能
１２のロック・モード
照会系のロック：IN(Intent None), IS(Intent Share), NS(Next Key Share), S(Share)
更新系のロック：IX(Intent Exclusive), SIX(Share with Intent Exclusive), U(Update),
NX(Next Key Exclusive), NW(Next Key Weak Exclusive), X(Exclusive), W(Weak Exclusive), Z(Superxclusive)
（＊排他性の低い順に列挙）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 31-32 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ロックのモード（２）
ロックのモードと処理
厳密には、さらにISOLATIONとアクセス・パスによりロックの対象とモードが変化する
表スペースにとられるロック：
Ｉ
Ｎ，Ｉ
Ｓ，Ｉ
Ｘ，Ｚ
モード
対象
IN
IS
NS
S
IX
表
表
行
行
表
表
SIX
表
U
行
表
NX
行
NW
行
X
行
表
行
表
W
Z
このモードで表ロックが取得された時
の同一トランザクションからの行ロック
行ロックは取得しない
Ｓ，ＮＳ行ロック
行ロックは取得しない
照会行にS,NS,U
更新行にX
照会行にロックなし
更新行にX行ロック
行ロックは取得しない
行ロックは取得しない
このモードでロックが取得されるケース
URで照会時の表ロック
RR,RS,CSで照会時の表ロック
RS,CSで照会時の行ロック
RRで照会時の行ロック
表単位でロックが取得される場合の、照会時の表ロック
更新時またはFOR UPDATEカーソルでの照会時の表ロック
同一トランザクション内で、既にSを取得している表にIXロック、
または既にIXを取得している表にSロックの取得要求が発生し
た場合の表ロック
FOR UPDATEカーソルでの照会時の行または表ロック
更新時にはXロックに変わる
表単位でロックが取得される場合の、FOR UPDATEカーソルで
照会処理時の表ロック
カタログ表をUPDATE/DELETEした時に、更新行の次の行を
ロック（V5+FP7以降、V6)
ユーザー表ををUPDATE/DELETEした時に、更新行の次の行
をロック（V5+FP6)
カタログ表以外の表の索引にINSERTした行の次の行を瞬間的
にロック
更新時の行ロック
表単位でロックが取得される場合の、更新時の表ロック
カタログ表以外の表の索引にINSERTした時の行ロック
特定の状況下で取得 (表のALTER,DROP,REORG,
索引のCREATE,DROP）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：＜参考＞アクセス・パス＆処理内容とロック・モードの関係
照会処理時のロック・モードは、アクセス・パスおよび処理内容により決定されます。
以下の表は、アクセス・パスおよび処理内容と、決定されるロック・モードとの関係を示しています。
Read-Onlly: 読み取りのみの照会処理の時
Intent to change: FOR UPDATE付きのカーソルによる照会処理の時
Change: INSERT/DELETE/UPDATEの際に行われる照会処理の時
（WHERE CURRENT CURSOR OFは指定されていない）
表スキャンのロック・モード
条件節なしの表スキャン
ISOLATION LEVEL
Intent to change
(FOR UPDATE付きカー
ソルでの照会時）
U(表）
Change
（更新時）
RR
Read-Only
(読み取りのみの
照会時）
S（表）
RS
CS
UR
IS（表）／NS（行）
IS（表）／NS（行）
IN（表）
IX（表）／U（行）
IX（表）／U（行）
IX（表）／U（行）
IX（表）／X（行）
IX（表）／X（行）
IX（表）／X（行）
ISOLATION LEVEL
Read-Only
(照会時）
Change
（更新時）
RR
S（表）
Intent to change
(FOR UPDATE付きカー
ソルでの照会時）
U(表）
RS
CS
IS（表）／NS（行）
IS（表）／NS（行）
IX（表）／U（行）
IX（表）／U（行）
IX（表）／U（行）
IX（表）／U（行）
UR
IN（表）
IX（表）／U（行）
IX（表）／U（行）
X（表）
条件節ありの表スキャン
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 33-34 )
U（表）
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：＜参考＞アクセス・パス＆処理内容とロック・モードの関係
索引スキャンのロック・モード
条件節なしの索引スキャン
ISOLATION LEVEL
Read-Only
(照会時）
Change
（更新時）
S（表）
Intent to change
(FOR UPDATE付きカー
ソルでの照会時）
IX（表）／U（行）
RR
RS
CS
UR
IS（表）／NS（行）
IS（表）／NS（行）
IN（表）
IX（表）／U（行）
IX（表）／U（行）
IX（表）／U（行）
IX（表）／X（行）
IX（表）／X（行）
IX（表）／X（行）
X（表）
１行のみヒットする索引スキャン（ユニーク索引を使用した索引スキャン）
ISOLATION LEVEL
Read-Only
(照会時）
RR
RS
CS
UR
IS（表）／S（行）
IS（表）／NS（行）
IS（表）／NS（行）
IN（表）
Intent to change
(FOR UPDATE付きカー
ソルでの照会時）
IX（表）／U（行）
IX（表）／U（行）
IX（表）／U（行）
IX（表）／U（行）
Change
（更新時）
IX（表）／X（行）
IX（表）／X（行）
IX（表）／X（行）
IX（表）／X（行）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：＜参考＞アクセス・パス＆処理内容とロック・モードの関係
索引スキャンのロック・モード
範囲指定の条件節の索引スキャン
ISOLATION LEVEL
Read-Only
(照会時）
RR
RS
CS
UR
IS（表）／S（行）
IS（表）／NS（行）
IS（表）／NS（行）
IN（表）
Intent to change
(FOR UPDATE付きカー
ソルでの照会時）
IX（表）／S（行）
IX（表）／U（行）
IX（表）／U（行）
IX（表）／U（行）
Change
（更新時）
Intent to change
(FOR UPDATE付きカー
ソルでの照会時）
IX（表）／S（行）
IX（表）／U（行）
IX（表）／U（行）
IX（表）／U（行）
Change
（更新時）
IX（表）／X（行）
IX（表）／X（行）
IX（表）／X（行）
IX（表）／X（行）
条件節ありの索引スキャン
ISOLATION LEVEL
Read-Only
(照会時）
RR
RS
CS
UR
IS（表）／S（行）
IS（表）／NS（行）
IS（表）／NS（行）
IN（表）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 35-36 )
IX（表）／U（行）
IX（表）／U（行）
IX（表）／U（行）
IX（表）／U（行）
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：＜参考＞ISOLATION=RRに関するロック取得の確認
ISOLATION=RRについては、他のISOLATIONに比べて多少理解しづらい点がありますので、実際のテスト結果を参照してください。
テスト内容
Read-Only
１．条件なしの索引スキャン
２．条件ありの索引スキャン
Intent to change
３．FOR UPDATEつきカーソルによる表スキャン
４．FOR UPDATEつきカーソルによる索引スキャン
５．FOR UPDATEつきカーソルによる、ユニーク索引を使用した索引スキャン（1行のみヒットする）
６．FOR UPDATEつきカーソルによる索引スキャン + 副照会
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：＜参考＞ISOLATION=RRに関するロック取得の確認：テスト１
dynexplnの出力
テスト環境
ISOLATION=RR
Package Name = UDBV61.DYNEXPLN
Prep Date = 2000/01/21
TESTTAB1表の列COL1に昇順の索引
Prep Time = 10:32:34
条件節なしの索引スキャン
Bind Timestamp = 2000-01-21-10.32.34.505994
テスト手順
Isolation Level
= Repeatable Read
Blocking
= Block Unambiguous Cursors
export DYNEXPLN_OPTIONS='isolation RR'
Query Optimization Class = 5
dynexpln -d sample -q "select min(col1) from
Partition Parallel
= No
Intra-Partition Parallel = No
testtab1
Function Path
= "SYSIBM", "SYSFUN", "UDBV61"
ロックの取得
-------------------- SECTION --------------------------------------表にSロック
Section = 1
SQL Statement:
考察
select min(col1)
列関数により索引列を指定しても、表ロックが取得
from testtab1
される
Estimated Cost
=1
Estimated Cardinality = 1
Access Table Name = UDBV61.TESTTAB1 ID = 4,9
| #Columns = 1
| Index Scan: Name = UDBV61.COL1IX ID = 2
| | Index Columns:
| | | 1: COL1 (Ascending)
| | #Key Columns = 0
| | | Start Key: Beginning of Index
| | | Stop Key: End of Index
| | Index-Only Access
| | Index Prefetch: None
| Lock Intents
| | Table: Share
| | Row : None
Aggregation
| Single Record
| Column Function(s)
Return Data to Application
| #Columns = 1
End of section
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 37-38 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：＜参考＞ISOLATION=RRに関するロック取得の確認：テスト２
テスト環境
ISOLATION=RR
TESTTAB1表の列COL1に昇順の索引
条件節ありの索引スキャン
テスト手順
export DYNEXPLN_OPTIONS='isolation RR'
dynexpln -d sample -q "select min(col1) from
testtab1 where col1 between 3 and 6
ロックの取得
表にISロック,行にSロック
dynexplnの出力
Package Name = UDBV61.DYNEXPLN
Prep Date = 2000/01/21
Prep Time = 10:33:08
Bind Timestamp = 2000-01-21-10.33.08.854616
Isolation Level
= Repeatable Read
Blocking
= Block Unambiguous Cursors
Query Optimization Class = 5
Partition Parallel
= No
Intra-Partition Parallel = No
Function Path
= "SYSIBM", "SYSFUN", "UDBV61"
-------------------- SECTION --------------------------------------Section = 1
SQL Statement:
select min(col1)
from testtab1
where col1 between 3 and 6
Estimated Cost
=1
Estimated Cardinality = 1
Access Table Name = UDBV61.TESTTAB1 ID = 4,9
| #Columns = 1
| Index Scan: Name = UDBV61.COL1IX ID = 2
| | Index Columns:
| | | 1: COL1 (Ascending)
| | #Key Columns = 1
| | | Start Key: Inclusive Value
| | | | 1: 3
| | | Stop Key: Inclusive Value
| | | | 1: 6
| | Index-Only Access
| | Index Prefetch: None
| Lock Intents
| | Table: Intent Share
| | Row : Share
Aggregation
| Single Record
| Column Function(s)
Return Data to Application
| #Columns = 1
End of section
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：＜参考＞ISOLATION=RRに関するロック取得の確認：テスト３
dynexplnの出力
テスト環境
ISOLATION=RR
Package Name = UDBV61.DYNEXPLN
DEPARTMENT表には索引なし
Prep Date = 2000/01/19
Prep Time = 11:00:21
範囲指定の条件節ありの、FOR UPDATEつきカー
ソルによる表スキャン
Bind Timestamp = 2000-01-19-11.00.21.753626
Isolation Level
= Repeatable Read
テスト手順
Blocking
= Block Unambiguous Cursors
export DYNEXPLN_OPTIONS='isolation RR'
Query Optimization Class = 5
dynexpln -d sample -q "select ＊ from
Partition Parallel
= No
Intra-Partition Parallel = No
department where deptno > '000110' for update of
Function Path
= "SYSIBM", "SYSFUN", "UDBV61"
deptno
-------------------- SECTION --------------------------------------ロックの取得
Section = 1
SQL Statement:
表にUロック
select *
from department
where deptno > '000110'
for update of deptno
Estimated Cost
= 25
Estimated Cardinality = 10
Access Table Name = UDBV61.DEPARTMENT ID = 3,7
| #Columns = 5
| Relation Scan
| | Prefetch: Eligible
| Lock Intents
| | Table: Update
| | Row : None
| Sargable Predicate(s)
| | #Predicates = 1
Return Data to Application
| #Columns = 5
End of section
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 39-40 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：＜参考＞ISOLATION=RRに関するロック取得の確認：テスト４
dynexplnの出力
テスト環境
ISOLATION=RR
Package Name = UDBV61.DYNEXPLN
Prep Date = 2000/01/21
TESTTAB２表の列COL1に昇順の索引
Prep Time = 09:37:49
条件節ありの、FOR UPDATEつきカーソルによる
Bind Timestamp = 2000-01-21-09.37.49.118243
索引スキャン
Isolation Level
= Repeatable Read
Blocking
= Block Unambiguous Cursors
テスト手順
Query Optimization Class = 5
export DYNEXPLN_OPTIONS='isolation RR'
Partition Parallel
= No
Intra-Partition Parallel = No
dynexpln -d sample -q "select ＊ from testtab２
Function
Path
= "SYSIBM", "SYSFUN", "UDBV61"
where col1 = 1 for update of col1
-------------------- SECTION --------------------------------------ロックの取得
Section = 1
SQL Statement:
表にIXロック,行にSロック
select *
考察
from testtab2
where
col1 =1
FOR UPDATE付きカーソルによる照会でも、行にS
for update of col1
ロックを取得する
Estimated Cost
= 25
Estimated Cardinality = 3
Access Table Name = UDBV61.TESTTAB2 ID = 3,11
| #Columns = 2
| Index Scan: Name = UDBV61.TAB2COL1IX ID = 1
| | Index Columns:
| | | 1: COL1 (Ascending)
| | #Key Columns = 1
| | | Start Key: Inclusive Value
| | | | 1: 1
| | | Stop Key: Inclusive Value
| | | | 1: 1
| | Data Prefetch: Eligible
| | Index Prefetch: None
| Lock Intents
| | Table: Intent Exclusive
| | Row : Share
Return Data to Application
| #Columns = 2
End of section
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：＜参考＞ISOLATION=RRに関するロック取得の確認：テスト５
dynexplnの出力
テスト環境
ISOLATION=RR
Package Name = UDBV61.DYNEXPLN
Prep Date = 2000/01/21
TESTTAB３表の列COL1に昇順のユニーク索引
Prep Time = 10:18:12
条件節ありの、FOR UPDATEつきカーソルによる
Bind Timestamp = 2000-01-21-10.18.12.110459
索引スキャン
Isolation Level
= Repeatable Read
Blocking
= Block Unambiguous Cursors
テスト手順
Query Optimization Class = 5
export DYNEXPLN_OPTIONS='isolation RR'
Partition Parallel
= No
Intra-Partition Parallel = No
dynexpln -d sample -q "select ＊ from testtab３
Function
Path
= "SYSIBM", "SYSFUN", "UDBV61"
where col1 = ５ for update of col1
-------------------- SECTION --------------------------------------ロックの取得
Section = 1
SQL Statement:
表にIXロック,行にUロック
select *
考察
from testtab3
where col1=5
FOR UPDATE付きカーソルによる照会で、ユニーク
for update of col1
索引に対する索引スキャンであれば、行にUロック
を取得する
Estimated Cost
= 25
Estimated Cardinality = 1
Access Table Name = UDBV61.TESTTAB3 ID = 3,12
| #Columns = 2
| Single Record ＜＝＝ユニーク索引に対する索引スキャン
| Index Scan: Name = UDBV61.TAB3COL1IX ID = 1
| | Index Columns:
| | | 1: COL1 (Ascending)
| | #Key Columns = 1
| | | Start Key: Inclusive Value
| | | | 1: 5
| | | Stop Key: Inclusive Value
| | | | 1: 5
| | Data Prefetch: Eligible
| | Index Prefetch: None
| Lock Intents
| | Table: Intent Exclusive
| | Row : Update
Return Data to Application
| #Columns = 2
End of section
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 41-42 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：＜参考＞ISOLATION=RRに関するロック取得の確認：テスト６
テスト環境
ISOLATION=RR
TESTTAB1およびTESTTAB2表の列COL1に昇順
の索引
副照会による条件節ありの、FOR UPDATEつき
カーソルによる索引スキャン
テスト手順
export DYNEXPLN_OPTIONS='isolation RR'
dynexpln -d sample -q "select ＊ from testtab2
where col1 in (select col1 from testtab1 where
col1 = 'val10' update of col1
ロックの取得
副照会部分：表にIS、行にSロック
FOR UPDATE照会部分：表にIX、行にSロック
考察
副照会部分については、Read-Only扱い
dynexplnの出力
Package Name = UDBV61.DYNEXPLN
Prep Date = 2000/01/21
Prep Time = 09:43:53
Bind Timestamp = 2000-01-21-09.43.53.369425
Isolation Level
= Repeatable Read
Blocking
= Block Unambiguous Cursors
Query Optimization Class = 5
Partition Parallel
= No
Intra-Partition Parallel = No
Function Path
= "SYSIBM", "SYSFUN", "UDBV61"
-------------------- SECTION --------------------Section = 1
SQL Statement:
select * from testtab2
where col1 in (select col1 from testtab1
where col2='val10') for update of col1
（続き））
Estimated Cost
= 51
Estimated Cardinality = 3
Access Table Name = UDBV61.TESTTAB1 ID = 4,9
| #Columns = 2
| Single Record
| Index Scan: Name = UDBV61.COL2IX ID = 1
| | Index Columns:
| | | 1: COL2 (Ascending)
| | #Key Columns = 1
| | | Start Key: Inclusive Value
| | | | 1: 'val10
'
| | | Stop Key: Inclusive Value
| | | | 1: 'val10
'
| | Data Prefetch: Eligible
| | Index Prefetch: None
| Lock Intents
| | Table: Intent Share
| | Row : Share
Nested Loop Join
| Access Table Name = UDBV61.TESTTAB2 ID = 3,11
| | #Columns = 2
| | Index Scan: Name = UDBV61.TAB2COL1IX ID = 1
| | | Index Columns:
| | | | 1: COL1 (Ascending)
| | | #Key Columns = 1
| | | | Start Key: Inclusive Value
| | | | | 1: ?
| | | | Stop Key: Inclusive Value
| | | | | 1: ?
| | | Data Prefetch: Eligible
| | | Index Prefetch: None
| | Lock Intents
| | | Table: Intent Exclusive
| | | Row : Share
Return Data to Application
| #Columns = 2
End of section
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 43-44 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
アクセス・パスでのロックのモードの確認
BIND時に作成されるアクセス・
パスの中で、ロックのモードが決定され
る
EXPLAIN出力によるロック･モードの確認方法
静的SQL（
パッケージ）：db2explnツール
構文： db2expln -d データベース名 -c 作成者ID -p パッケージ名 -o 出力ファイル名
ヘルプの画面出力： db2expln -h db2explnのみを打鍵して実行した場合には、プロンプトが画面表示され、対話式に実行が可能
動的SQL：
dynexplnツール
構文：dynexpln -d データベース名 -q SQL文 -f 入力ファイル名 -g EXPLAINグラフの表示 -o 出力ファイル名
ヘルプの画面出力：dynexpln -h
dynexplnのみを打鍵して実行した場合には、プロンプトが画面表示され、対話式に実行が可能
DYNEXPLN_OPTIONS環境変数で、PREPオプションを設定することが可能
dynexplnはDYNEXPLN_OPTIONS環境変数で指定されたPREPオプションを使用して、アクセス・パスを決定する
（例）export DYNEXPLN_OPTIONS="QUERYOPT 5 ISOLATION RS"
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：アクセス・パスでのロックのモードの確認
db2explnコマンドのヘルプ・テキスト出力：db2expln -h
db2expln [-c <creator>] [-d <dbname>] [-e <escape>] [-g] [-i] [-l] [-t|-o <outfile>] [-p <pname>] [-s <sectnbr>] [-u <user> <pw>] [-h|-?]
Input Fields:
-c <creator>
= package qualifier
-d <dbname>
= database name containing packages
-e <escape>
= escape character for LIKE predicate
-g
= show optimizer plan graphs
-h
= help
-i
= show operator ID numbers
-l
= respect package name case
-o <outfile> = name of output file
-p <pname>
= package name
-s <sectnbr>
= section number of package (use zero for all sections)
-t
= terminal output desired
-u <user> <pw>
= user ID and password for connecting to database
-?
= help
dynexplnコマンドのヘルプ・テキスト出力：dynexpln -h
dynexpln [[-d <database>] [-f <input file>] [-g] [-i] [-t|-o <output file>] [-q <SQL statement>] [-u <userid> <password>] [-z <delimiter>]]
Input fields:
-d <database>
= database name to connect to
-f <input file>
= name of file containing SQL statements to describe
-g
= show optimizer plan graphs
-h
= help
-i
= show operator ID numbers
-o <output file>
= name of output file
-q <SQL statement>
= SQL statement(s) to describe
-t
= terminal output desired
-u <userid> <password>
= userid and password for connecting to database
-z <delimiter>
= character used to delimit SQL statements (default is no delimiter)
-?
= help
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 45-46 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
アクセス・パスでのロックのモードの確認 -例db2explnツールによる、パッケージのEXPLAIN出力
Package Name = UDBV61.STATICES
Prep Date = 2000/01/07
Prep Time = 15:58:15
Bind Timestamp = 2000-01-07-16.25.43.231864
Isolation Level
= Read Stability
Blocking
= Block Unambiguous Cursors
Query Optimization Class = 5
Partition Parallel
= No
Intra-Partition Parallel = No
Function Path
= "SYSIBM", "SYSFUN", "UDBV61"
------------------- SECTION --------------------------------------Section = 1
SQL Statement:
SELECT MGRNO INTO :H00001
FROM department
WHERE deptno = 'A00'
Estimated Cost
= 25
Estimated Cardinality = 1
Access Table Name = UDBV61.DEPARTMENT ID = 3,7
| #Columns = 2
| Single Record
| Index Scan: Name = UDBV61.DEPTIX ID = 1
| | Index Columns:
| | | 1: DEPTNO (Ascending)
| | #Key Columns = 1
| | | Start Key: Inclusive Value
| | | | 1: 'A00'
| | | Stop Key: Inclusive Value
| | | | 1: 'A00'
| | Data Prefetch: Eligible
| | Index Prefetch: None
| Lock Intents
| | Table: Intent Share
| | Row : Next Key Share
| Return Data to Application
| | #Columns = 1
Return Data Completion
End of section
BIND時に指定されたISOLATION
ロック・モード
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 47-48 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
2-5.ロックの互換性
互換性
ロックが取得されているDBオブジェクトに、別アプリケーションからもロックの取得が可能であ
る時、それらのロック・モードは”互換性がある” という
逆に別アプリケーションからロックの取得が不可能であり、既に取得されているロックが解放さ
れるのを待たなければならない場合、それらのロック・モードは”互換性がない” という
ロック待ちの発生を”ロックの競合”という
排他(Exclusive)ロックと共用(Shared)ロックの互換性
概して共用ロック（Sロック）同士は互換性がある
詳細には、ロック･モードにより異なる
取得済みのロック
排他（
X)
取得要求
されたロック共用（
S)
排他（X)
×
×
共用（S)
×
〇
〇：取得可能 ×：
取得不可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 49-50 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ロック・モードによる互換性
互換性一覧
〇：ロック取得可能
×：ロック取得不可能となり、ロック待ちとなる
取得要求されているロック
取得されているロック
モード None
IN
IS
NS
S
IX
SIX
U
NX
X
Z
NW
W
None
IN
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
〇
×
〇
〇
〇
〇
IS
〇
〇
〇
〇
〇
〇
〇
〇
×
×
×
×
×
NS
〇
〇
〇
〇
〇
×
×
〇
〇
×
×
〇
×
S
〇
〇
〇
〇
〇
×
×
〇
×
×
×
×
×
IX
〇
〇
〇
×
×
〇
×
×
×
×
×
×
×
SIX
〇
〇
〇
×
×
×
×
×
×
×
×
×
×
U
〇
〇
〇
〇
〇
×
×
×
×
×
×
×
×
NX
〇
〇
×
〇
×
×
×
×
×
×
×
×
×
X
〇
〇
×
×
×
×
×
×
×
×
×
×
×
Z
〇
×
×
×
×
×
×
×
×
×
×
×
×
NW
〇
〇
×
〇
×
×
×
×
×
×
×
×
〇
W
〇
〇
×
×
×
×
×
×
×
×
×
〇
×
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロック・モードによる互換性
上記の表の、横軸に書かれているロック・モードで、既にロックが取得されていた場合に、同じデータベース・オブジェクトに対して、
縦軸に書かれているモードで、ロックの取得要求があった場合に、交わる四角の中の印が○であれば、取得要求どおり、ロックは取
得可能です。この場合、２つのロック・モードは互換性があると言います。交わる四角の中の印が×であれば、取得要求はとおら
ず、既存のロックが外れるまで待たされることになります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 51-52 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
UロックとFOR UPDATE付きのカーソル
FOR UPDATE付きのカーソル
FETCH後に、WHERE CURRENT OF の指定付きで、現在行のUPDATE/DELETEを行う場合
に、排他制御を行うために使う
OPENカーソル時には行は読み込まれず、FETCH時に１行づつ読み込まれる
FOR UPDATEなしのカーソルの場合、OPENカーソル時に、ある程度の結果行が読み込まれ、クライアントに送られる
FETCH時にFETCH行に、Ｕロックが取得される (ISOLATION=RRの場合にはＳロック)
FETCH後に更新処理があることが予想されるので、行に排他制御をおこなうため
ロックの取られ方
CLP(コマンド行プロセッサー）での検証
db2 DECLARE csr CURSOR FOR select col1 col2 from tab1 for update ; db2 OPEN csr ；
db2 FETCH csr for 1 row ；＜＝FETCH行にUロックが取得される
db2 UPDATE tab1 set col1=xx where current of csr ；＜＝UPDATE行にXロックが取得される
db2 COMMIT；＜＝ロックが解放される
FOR UPDATE付きのカーソルの考慮事項
１行SELECTには使わない
単一行の更新（例：ユニーク索引列を条件にした場合など）には、直接UPDATE文を使用した方が良い
SELECT.......INTO文には、FOR UPDATEは指定できない
FETCH時に１行づつしか読み込まれないので、SELECTのみの処理には使わない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：UロックとFOR UPDATE付きのカーソル
FOR UPDATE付きのカーソルは、FETCH後に、WHERE CURRENT OFオプション付きで、現在行の更新（UPDATE/DELETE)を行
う場合に使用します。理由は、FOR UPDATE付きのカーソルでFETCHを行うことにより、行にUロックを取得し、排他制御を行うため
です。Uロックを取得中は、他のアプリケーションがその行をNSロックで読み取ることはできますが、排他的なロック（Xロック、Uロック
など）をかけることはできません。
Uロックにより排他制御されるので、デッドロックを防ぐことができます。
SELECT * from table1
where col1=2 FOR UPDATE；
Uロック
取得
table1
COL１
１
２
３
COL２
A
B
C
COL３
a
b
c
この間は、Uロック取得行に対して、他のアプリケーションからは、
読み取りのみ可能
更新は不可能
UPDATE table1 SET ...
WHERE CURRENT OF カーソル名；
Xロック
取得
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 53-54 )
COL１
１
２
３
COL２
A
B
C
COL３
a
b
c
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
FOR UPDATEあり/なしによる動作の違い
処理例：
（
ISLATION=CSと仮定）
カーソルのOPEN後に、他のアプリケーションが結果セットの行をUPDATEした場合
1. Appl1：DECLARE csr CURSOR FOR select col1,col2 from tab2 where col1 between 200 and 400 FOR UPDATE
；
2. Appl1：OPEN csr；
＝＞FOR UPDATEなしの場合、結果セットの一部がクライアントに送られる（注１）
＝＞FOR UPDATEありの場合、FETCH時に１行がクライアントに送られる
3. Appl２：UPDATE tab2 where col1=300；＝＞COL1=３００の行にXロックを取得
4. Appl1：FETCH csr for 1 row；＝＞COL1=２００の行をFETCHし、Uロックを取得、行が戻される
5. Appl1：FETCH csr for 1 row；＝＞COL1=３００の行をFETCH
上記のステップ５での動作の違い
FOR UPDATEなしのカーソル(ISOLATION=CS)の場合
COL1=300の行が戻される
FOR UPDATEありのカーソル(ISOLATION=CS)の場合
COL１=300の行は、Appl２によりXロックが取得されているため、LOCK WAITとなる
（
注１：BINDのblockingオプションがNOの場合には、結果セットの一部が
クライアントに送られることはありません。）
Ｕロック COL1
100
200
300
400
COL2
12
22
32
42
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：FOR UPDATEあり/なしによる動作の違い
FOR UPDATEありの場合には、FETCH時に１行がクライアントに送られます。そのため、次にFETCHする行に排他ロックが取得され
ている場合には、FETCHはWAITします。
FOR UPDATEなしの場合には、FETCH時にある程度の行がクライアントに送られます。これをデータのBLOCKINGと言います。その
ため、行がクライアントに送られた後、実は次にFETCHする行に排他ロックが取得されたとしても、次の行はクライアント側のメモ
リー内にあるため、FETCHすることが可能です。ただし、メモリー内の値は、その時点のデータベース・サーバーにある値とは異なる
可能性があるのです。
ただし、以下の場合には、BLOCKINGは行われません。
・BINDのBLOCKINGオプションでNOを指定した場合
・BINDのBLOCKINGオプションでUNAMBIG（省略時値）を使用した場合で、かつ、カーソルが未確定の場合
カーソルが未確定の場合とは、照会処理のみのカーソルと判別できない場合を指します。
BLOCKINGを行いたい場合で、かつSELECT文にソート処理が入っていない場合には、SELECT文に
FOR FETCH ONLYもしくはFOR READ ONLYを、明示的に指定することをお奨めいたします。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 55-56 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
OPENカーソル時のロック取得 (FOR UPDATEあり)
OPEN時には行は読み込まないので(RRを除く）、ロックは取られない
FETCH時に、１行づつ読み込まれる
FOR UPDATEは、ソート処理を含むSELECTには指定不可
ISOLATION=CS
FETCH時に、照会行にUロックを取得、カーソルが次の行に移ると前の行へのロックは外される
ISOLATION=RS
FETCH時に、照会行に、Uロックを取得し、カーソルが次の行に移ってもUロックを保持
ISOLATION=RR
ＯＰＥＮカーソル時に、走査した行全てと、High KeyにSロックを取得し、FETCH後もSロックを保持
DB2サーバー
RS
RR
走査行＋High Key
１万行
１万行
にロック
OPEN csr1；
CS
結果行
照会行
２０００行に
ロック
１行にロック
FETCH；
結果行
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：OPENカーソル時のロック取得 (FOR UPDATEあり)
FOR UPDATEがある場合で、かつ、Ｉ
ＳＯＬＡＴＩ
ＯＮがＲＳまたはＣＳの場合、カーソルのＯＰＥＮ時に行を読み込みません。従って、
ロックも取得されません。
Ｉ
ＳＯＬＡＴＩ
ＯＮがＲＲの場合には、ＯＰＥＮカーソル時に、走査行とＨＩ
ＧＨＫＥＹにＳロックが取得されます。
OPENカーソルとFETCHの処理
OPENカーソル時には、行は読み込まれません。
FETCH時に、結果行１行がクライアントに送られます。次のFETCHで、次の結果行１行がクライアントに送付されます。
OPEN
クライアント
DB2サーバー
SQLCODE＝０
FETCH
１行
FETCH
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 57-58 )
１行
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
＜参考＞OPENカーソル時のロック取得 (SORTあり)
OPEN時に、結果表が作成される
メモリー(sortheap)内に作成できない場合には、一時表スペースに作成される
ISOLATION=CS
結果表を作成する際に、照会行１行に、読み取るときのみ随時NSロックが取得される
FETCH時には、元表にはロックは取得されず、結果表にアクセスする
ISOLATION=RS
結果行全てに、ＮＳロックを取得
ISOLATION=RR
走査した行全てと、High Keyに、Ｓロックを取得
DB2サーバー
RS
RR
結果行
走査行＋High Key
１万行
１万行
にロック
CS
結果表作成時のみ：照会行
２０００行に
ロック
１行にロック
OPEN csr1；
FETCH；
結果表
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
結果セット
解説：＜参考＞OPENカーソル時のロック取得 (SORTのみあり)
OPENカーソル時のロック取得の様子は、ISOLATIONにより異なります。ただし、ソート処理がある場合と仮定します。
ISOLATION=CSの場合には、次のFETCH時にクライアントに送る結果セットの先頭行に、NSロックを取得します。
ISOLATION=RSの場合には、結果行全てにNSロックを取得します。
ISOLATION=RRの場合には、検索時に走査した行の全てにSロックを取得します。
OPENカーソルとFETCHの処理
OPENカーソル時に、結果セットがサーバー側で作られます。
FETCH時に、結果セットの最初のブロックがクライアントに送られます。クライアントで、結果セットの行がなくなるまでFETCHが
行なわれると、次のFETCHで、次の結果セットのブロックがクライアントに送付されます。
結果セットを入れるメモリー
リモート・クライアントでは、RQRIOBLK DBM CFG、ローカル・クライアントでは、ASLHEAPSZ DBM CFGがこのメモリーサイズを
決める構成パラメーターです。
クライアント
DB2サーバー
OPEN
SQLCODE＝０
FETCH
FETCH
結果セット
結果
セット
結果セットが空になると
次のFETCHで結果セットを要求......
結果
セット
結果表
FETCH
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 59-60 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
2-6.ロックの変換(Lock Conversion)
ロックは、処理に必要なモードに変換されていく
１アプリケーションから各DBオブジェクトに取得可能なロックは１つ
(例）１つのアプリケーションが、１つの行に複数のロックを取得することはできない
ロック変換の例
照会した行を更新する場合
ISOLATION = CSのプログラム
select col1,col2 from table1
where col1 = 100 ;
表にIS
行にNS
..................
.................
update table1 set col2='A01'
where col1 = 100 ;
表にIX
行にX
col1
050
100
150
col2
A20
A00
A00
col3
1
2
NS行ロック => X行ロック
3
IS表ロック=> IX表ロック
変換
変換
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロックの変換
１つのアプリケーションが、DBオブジェクトに取得できるロック・モードは1種類であるため、処理に必要なロック・モードに適宜変換し
てロックを取得します。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 61-62 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
３．ロック・エスカレーション
多数の行ロックを、一つの表ロックへ変更するプロセス
CPU負荷およびメモリー容量削減のためのしくみ
アプリケーションの並行可動性が劣化する可能性あり
他のアプリケーションが取得したロックの解放を待って、エスカレーションする
ロック・
エスカレーションの原因
maxlocks（
１アプリケーションに許されるロックの数）
の値に達した時
locklist（
ロックに使用するメモリー容量の上限）が一杯になった時
ロック・
エスカレーションの回避策
頻繁なＣＯＭＭＩ
Ｔ
ｌ
ｏｃｋｌ
iｓｔDB CFGを増やす
ｍａｘｌ
ｏｃｋｓDB CFGを増やす
ロックの範囲がより狭い分離レベルをを使用
同一表に大量の更新処理がある場合には、あらかじめ表ロックを取得し、処理後速やかに
ＣＯＭＭＩ
Ｔ
ＷＩ
ＴＨＲＥＬＥＡＳＥオプション付きのカーソルのＣＬＯＳＥ（ＲＲ・ＲＳの時のみ）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロック・エスカレーション
ロック・エスカレーションの発生と回避
ロックの制御に関する構成パラメーター
LOCKLIST DB CFG：省略時値(ページ) UNIX 100, OS2/NT(リモートクライアントあり） 50
１データベースあたりでロックに使用されるメモリーの上限。
MAXLOCKS DB CFG：省略時値(%) UNIX 10 , OS2/NT 22
ＬＯＣＫＬＩ
ＳＴの中で１アプリケーションが使用可能なメモリーの割合。
この値に達するとロック・エスカレーションが発生する。
ロック・エスカレーション発生の要因
１アプリケーションに許されるロックの数を越えて、ロックを保持しているアプリケーションがある。
トランザクションがmaxlocksを越えた場合、そのトランザクションが最も多くロックを保持している表の行ロックを、表ロックへ
変更します。
ロックに使用されているメモリー容量がＬｏｃｋｌｉ
ｓ
ｔ
の値に達した。
ロックリストが一杯になった場合、ロックリストを最も多く使用しているトランザクションが選ばれ、同じ表への行ロックを表
ロックへ変更します。
（複数行への行ロックが、１つの表ロックに入れ替わることになります）
ロック・エスカレーションの回避
ｌ
ｏ
ｃ
ｋ
ｌ
ｓ
ｔDB CFGを増やす
ｍａｘｌｏｃｋｓDB CFGを増やす
ロックの範囲がより狭い分離レベルをを使用する。
同一表に大量の更新処理がある場合には、あらかじめ表ロックを取得し、処理後速やかにＣＯＭＭＩ
Ｔを行う。
頻繁なＣＯＭＭＩ
Ｔ
ＷＩ
Ｔ
ＨＲＥＬＥＡＳＥオプション付きのカーソルのＣＬＯＳＥ（ＲＲ・ＲＳの時のみ）を使用することにより、カーソルのＣＬＯＳＥ時
に全てのＲｅａｄＬｏｃｋをはずす。
このためRepeatable Readにならない可能性があることに注意。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 63-64 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
db2diag.logのロック・エスカレーション情報
db2diag.logへの出力には、DIAGLEVELの設定が必要
DIAGLEVEL＝３（省略時値）
ロック・エスカレーションの発生情報
DIAGLEVEL＝４
ロック・エスカレーションの発生情報 + エスカレーションに起因した動的SQL
静的SQLは記録されない
エスカレーション時のdb2diag.log出力
2000-01-07-14.44.03.232595 Instance:udbv61 Node:000
PID:12754(db2agent (SAMPLE)) Appid:*LOCAL.udbv61.000107053756
data_management sqldEscalateLocks Probe:1 Database:SAMPLE
-- Start Table Lock Escalation.
-- Lock Count, Target : 12, 6
7365 6c65 6374 202a 2066 726f 6d20 6465
select * from de
7061 7274 6d65 6e74 2077 6865 7265 2064
partment where d
6570 746e 6f3d 2744 3231 27
eptno='D21'
DIAGLEVEL=４
2000-01-07-14.44.03.466212 Instance:udbv61 Node:000
PID:12754(db2agent (SAMPLE)) Appid:*LOCAL.udbv61.000107053756
data_management sqldEscalateLocks Probe:2 Database:SAMPLE
-- Lock Count, Target : 12, 6
-- Table (ID) Name
: (3;7) UDBV61 .DEPARTMENT
-- Locks, Request Type : 5, S
-- Result (0 = success): 0
DIAGLEVEL=3
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：db2diag.logのロック・エスカレーション情報
ロック・エスカレーションについては、UDBのモニター・ツールでもモニタリング可能ですが、db2diag.logで確認することも可能です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 65-66 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
４．ロック待機(Lock Wait)とロック・タイムアウト
ロック待機(Lock Wait)
互換性のないロックの解放を待つこと
ロック・
タイムアウト
ロック待機状態でいた時間がLOCKTIMEOUTに達した場合、待機していたアプリケーションの
作業単位がロールバックすること
ＳＱＬＣＯＤＥ −９１１ＲＣ６８がアプリケーションに戻される
LOCKTIMEOUT db cfg（省略時値：−１単位：
秒）
ロック待ちを行う時間を設定する
省略時値では、無制限にロック待ちを行う
１
Appl1
UPDATE
１．Appl1がレコード１をＵＰＤＡＴＥ
２．Appl2がレコード２をＵＰＤＡＴＥする際に、Lock-Wait
レコード１
Xロック
Lock-Wait
Xロック取得要求
レコード２
２
３
LOCKTIMEOUT
Appl2
UPDATE
-911 RC=68
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロック待機(Lock Wait)とロック・タイムアウト
トランザクションがＬｏｃｋ-Ｗａｉ
ｔ
状態になった場合には、次のいづれかの条件になるまで待ちます。
1. Ｌｏｃｋ−Ｗａ
ｉ
ｔ
の対象となるロックが、コミットまたはロールバックにより解放された
2. LOCKTIMEOUT DB構成パラメーターの値と同じ時間まで待たされた
省略時値では、LOCKTIMEOUTパラメーターには -1 が設定されています。これは、タイムアウトにならないことを意味ます。ロックが
解放されるまで無制限に待ち続けます。
ハングし、動作していないように見えるアプリケーションは、他の長時間トランザクションによるロックを待っている可能性があ
りますので、注意してください。
ロック・スナップショットは、これを判別するのに役立ちます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 67-68 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ロック待機のNesting
ロック待機はNestする
既にロック待機が発生しているDBオブジェクトに、互換性のないロック取得の要求があった
場合、その要求以前に存在したロック待機がすべて解消するまで、ロック取得は待たされる
ロックのスナップショット出力では、ロック待機のNestingの順番などはわからない
最初にロックを取得したアプリケーションが保持するロックに対して、その他のロック要求をしているアプリケーションが
ロック待機しているように出力される
１．Appl１がレコード１をＵＰＤＡＴＥし、Xロックを取得
２．Appl２がレコード１をＵＰＤＡＴＥする際に、Appl１のロックに対してLock-Wait
３．Appl３がレコード１をＵＰＤＡＴＥする際に、Appl２のロックに対してLock-Wait
１
Xロック取得要求
Appl1
レコード１
UPDATE
Appl2
Lock-Wait
UPDATE
Xロック
レコード２
２
Lock-Wait
Xロック取得要求
３
Appｌ
3
UPDATE
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロック待機のNesting
NestしたロックのLock Wait再現シナリオ
１．Appl１: db2 -c- "update department set deptno='A00' where deptname='Dummy'
２．Appl２: db2 -c- "update department set deptno='A00' where deptname='Dummy'
３．Appl３: db2 -c- "update department set deptno='A00' where deptname='Dummy'
４．ロックスナップショットの取得１ (SNAPSHOT1)：db2 get snapshot for locks on DB1
５．Appl１: db2 rollback
６．ロックスナップショットの取得２ (SNAPSHOT2)：db2 get snapshot for locks on DB1
SNAPSHOT1の出力結果（抜粋）
Appl１に関する出力部分
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 9 <== Appl１
= *LOCAL.udbv61.000106063339
= 0001
= db2bp
= UDBV61
= UOW Waiting
=
= 943
=5
=0
List Of Locks
Lock Object Name = 81930
Object Type
= Row
Tablespace Name = INDTBS
Table Schema
= UDBV61
Table Name
= DEPARTMENT
Mode
= X ＜＝更新行にＸ行ロックロックを保持
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 69-70 )
＜途中省略＞
Lock Object Name = 7
Object Type
= Table
Tablespace Name = INDTBS
Table Schema
= UDBV61
Table Name
= DEPARTMENT
Mode
= IX ＜＝Ｉ
Ｘ
表ロックを保持
Status
= Granted
Lock Escalation = NO
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：ロック待機のNesting
SNAPSHOT1の出力結果（続き）
Appl２に関する出力部分
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 6 <== Appl２
= *LOCAL.udbv61.000106044801
= 0001
= db2bp
= UDBV61
= Lock-wait <== ロック待機中
= 01/06/2000 15:41:28.855775
= 943
=3
= 5306
ロック待ちのサブセクション
=0
ロック保留中エージェント ID
= 9 <== Aｐｐｌ
１に対するロック待機
ロック保留中のアプリケーション ID
= *LOCAL.udbv61.000106063339
ロック・オブジェクト・タイプ
= Row
ロック・モード
= Exclusive Lock (X) <== Aｐｐｌ
１が保持するロック
要求ロック・モード
= Exclusive Lock (X) <== Aｐｐｌ
２が要求するロック
ロック保留中の表スペース名
= INDTBS
ロック保留中の表スキーマ
= UDBV61
ロック保留中の表名
= DEPARTMENT
ロック待機開始タイムスタンプ
= 01/01/1970 09:00:00.000000
自動調整結果のロック
= NO
List Of Locks
Lock Object Name = 7
Object Type
= Table
Tablespace Name = INDTBS
Table Schema
= UDBV61
Table Name
= DEPARTMENT
Mode
= IX
Status
= Granted
Lock Escalation = NO <== Ｉ
Ｘ
表ロックを保持
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロック待機のNesting
SNAPSHOT1の出力結果（続き）
Appl３に関する出力部分
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 10 <== Appl３
= *LOCAL.udbv61.000106063449
= 0001
= db2bp
= UDBV61
= Lock-wait <== ロック待機中
= 01/06/2000 15:41:29.598253
= 943
=3
= 4564
ロック待ちのサブセクション
=0
ロック保留中エージェント ID
= 9 <== Appl1に対するロック待機
ロック保留中のアプリケーション ID
= *LOCAL.udbv61.000106063339
ロック・オブジェクト・タイプ
= Row
ロック・モード
= Exclusive Lock (X) <== Aｐｐｌ
１が保持するロック
要求ロック・モード
= Next Key Share (NS) <== Aｐｐｌ
３が要求するロック
ロック保留中の表スペース名
= INDTBS
ロック保留中の表スキーマ
= UDBV61
ロック保留中の表名
= DEPARTMENT
ロック待機開始タイムスタンプ
= 01/01/1970 09:00:00.000000
自動調整結果のロック
= NO
List Of Locks
Lock Object Name = 7
Object Type
= Table
Tablespace Name = INDTBS
Table Schema
= UDBV61
Table Name
= DEPARTMENT
Mode
=X
I <== Ｉ
Ｘ
表ロックを保持
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 71-72 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：ロック待機のNesting
SNAPSHOT２の出力結果：Appl３に関する出力部分
Appl１がROLLBACKし、Appl２のロック待機がとけると、Appl３が要求するロックモードがNSからXに変わる
Appl１がROLLBACKし、Appl２のロック待機がとけると、Appl３のロック待機の相手がAppl１からAppl２に変わる
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 10 <== Appl３
= *LOCAL.udbv61.000106063449
= 0001
= db2bp
= UDBV61
= Lock-wait
= 01/06/2000 15:41:38.010643
= 943
=3
= 4646
ロック待ちのサブセクション
=0
ロック保留中エージェント ID
= 6 <== Appl２に対するロック待機
ロック保留中のアプリケーション ID
= *LOCAL.udbv61.000106044801
ロック・オブジェクト・タイプ
= Row
ロック・モード
= Exclusive Lock (X) <== Aｐｐｌ
２が保持するロック
要求ロック・モード
= Exclusive Lock (X) <== Aｐｐｌ
３
が要求するロック
ロック保留中の表スペース名
= INDTBS
ロック保留中の表スキーマ
= UDBV61
ロック保留中の表名
= DEPARTMENT
ロック待機開始タイムスタンプ
= 01/01/1970 09:00:00.000000
自動調整結果のロック
= NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 73-74 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ロック・タイムアウトの発生と回避
ロック・
タイムアウト発生の要因
ロック・エスカレーションの発生
アプリケーション内での表ロックの取得
ＢＩ
ＮＤ時の分離レベル(ISOLATION)の範囲が不必要に広い
ロック・
タイムアウト発生の回避
ｌ
ｏｃｋｌ
iｓ
ｔDB CFGを増やす
ｍａｘｌ
ｏｃｋｓDB CFGを増やす
ｌ
ｏｃｋｔ
ｉ
ｍｅｏｕｔDB CFGを増やす
ロックの範囲がより狭い ISOLATION (分離レベル)を使用
同一表への大量更新時には、あらかじめ表ロックを取得し、処理後速やかにＣＯＭＭＩ
Ｔ
頻繁なＣＯＭＭＩ
Ｔ
ＷＩ
ＴＨＲＥＬＥＡＳＥオプション付きのカーソルのＣＬＯＳＥ（
ＲＲ・ＲＳの時のみ）を使用
例外処理ルーチンの組み込み
戻り値：ＳＱＬＣＯＤＥ＝−９１１、ＳＱＬＥＲＲＤ（２）＝６８
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロック・タイムアウトの発生と回避
Lock WaitによるLock Timeout
ロックタイムアウト監視のしくみ
locktimeout DB CFG：アプリケーションがロック待ちをする時間（秒）。
省略時値 −１（時間制限なくロック待ちを行う）
関連する構成パラメーター
LOCKLIST DB CFG：省略時値(ページ) UNIX 100, OS2/NT(リモートクライアントあり） 50
１データベースあたりでロックに使用されるメモリーの上限。
MAXLOCKS DB CFG：省略時値(%) UNIX 10 , OS2/NT 22
ＬＯＣＫＬＩ
ＳＴの中で１アプリケーションが使用可能なメモリーの割合。
この値に達するとロック・エスカレーションが発生する。
ロックタイムアウト発生の要因
ロック・エスカレーションが発生している。
アプリケーション内で表ロックを取得している。
ＢＩ
ＮＤ時の分離レベル(ISOLATION)の範囲が不必要に広い。
ロックタイムアウト発生の回避
ｌ
ｏ
ｃ
ｋ
ｌ
ｓ
ｔDB CFGを増やす
ｍａｘｌｏｃｋｓDB CFGを増やす
ｌ
ｏ
ｃ
ｋ
ｔ
ｉ
ｍｅｏｕｔDB CFGを増やす
ロックの範囲がより狭い分離レベルをを使用する。
同一表に大量の更新処理がある場合には、あらかじめ表ロックを取得し、処理後速やかにＣＯＭＭＩ
Ｔを行う。
頻繁なＣＯＭＭＩ
Ｔ
ＷＩ
Ｔ
ＨＲＥＬＥＡＳＥオプション付きのカーソルのＣＬＯＳＥ（ＲＲ・ＲＳの時のみ）を使用することにより、
カーソルのＣＬＯＳＥ時に全てのＲｅａｄＬｏｃｋをはずす。
このためRepeatable Readにならない可能性があることに注意。
例外処理ルーチンの組み込み
ロックタイムアウトの発生を検知し、処理の再試行を行うルーチンを用意しておく
ロックタイムアウトの戻り値：ＳＱＬＣＯＤＥ＝−９１１、ＳＱＬＥＲＲＤ（２）＝６８
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 75-76 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
５．デッドロック
デッドロック
複数のトランザクションが互いにロック待機状態になること
１
Appl1
UPDATE
レコード１
Xロック保持
３
UPDATE
Lock-Wait
Xロック取得要求
Lock-Wait Xロック取得要求
UPDATE
レコード２
４
Xロック保持
２
UPDATE
Appl2
１．トランザクション１がレコード１をＵＰＤＡＴＥ
２．トランザクション２がレコード２をＵＰＤＡＴＥ
３．トランザクション１は、トランザクション２のＣＯＭＭＩ
Ｔ／ＲＯＬＬＢＡＣＫを待つ
４．トランザクション２は、トランザクション１のＣＯＭＭＩ
Ｔ／ＲＯＬＬＢＡＣＫを待つ
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：デッドロック
デッドロックは、最初のトランザクションが２番目のトランザクションを待ち、２番目のトランザクションが最初のトランザクションを待つ
ような条件で起こります。２つのトランザクションは、お互いに待ちあい、この状態から抜け出すことはできません。
この例では
1. トランザクション 1 はレコード1を更新します。
2. トランザクション 2 はレコード2を更新します。
3. トランザクション 1はレコード2を更新しようとしますが、そのレコードには排他ロックがかかっているので、待機状態になります。
4. トランザクション 2はレコード1を更新しようとしますが、そのレコードには排他ロックがかかっているので、待機状態になります。
5. デッドロック状態.....
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 77-78 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
デッドロックの検知
デッドロック発生をチェックする時間間隔を設定
DLCHKTIME dbm cfg(省略時値：10000 単位：ミリ秒)
デッドロック・ディテクターは指定された時間ごとに実行される
デッドロック・ディテクターはロックリストを検査し、デッドロックの存在を調べる
デッドロック検知時のエラー
デッドロック状態が見つかった場合、デッドロック・ディテクターは関連するトランザクションの中の１つをロールバック
し、ＳＱＬＣＯＤＥ −９１１ＲＣ２がアプリケーションに戻される
ロールバックされるのは、最後のトランザクションとは限らない
EEE環境でのデッドロック・ディテクター
各パーティションごとに、デッドロック・ディテクター
db2dlock (AIX環境でのプロセス名）
インスタンスに対して、１つのグローバル・ディテクター
db2glock (AIX環境でのプロセス名）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：デッドロックの検知
データベースに取得されているロック情報は、すべてロックリストの中に保存されます。
デッドロック・ディテクターは、DB2によって定期的に起動されるプロセス/スレッドです。
ＤＬＣＨＫＴＩ
ＭＥデータベース構成パラメーターで定義された、ミリ秒ごとに起動されます。
デッドロック・ディテクターが稼動すると、ロックリストをスキャンし、デッドロックの状況がないかどうかを調べます。
もし、デッドロックがDB2によって検知されると、関連するトランザクションの中の１つがロールバックされます。.
アプリケーションはSQL 911､reason code 2を受け取ります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 79-80 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
どのトランザクションがロールバックするか？
デッドロック・ディテクターはロックリストを読み、ロックのチェインを作成
デッドロックが検知された場合
デッドロック・ディテクターは、ロック・チェインへ最後に取りこまれたトランザクションをロールバック
ロールバックされるのは、必ずしも最後に開始したトランザクションではない
ロック・リス
ト
２
Appl1
UPDATE
４
UPDATE
Lock-Wait
レコード１
２
３
４
６
レコード２
レコード１０
ApplＸ
１
Lock-Wait
UPDATE
３
UPDATE
Appl2
１Ｉ
ＮＳＥＲ
Ａｐｐｌ
ｘCOMMIT
Ａｐｐｌ
１
Ａｐｐｌ
２
Ａｐｐｌ
１
５
６Ａｐｐｌ
２
空きスペース
に
入る可能性あ
り
Ｔ
５ＣＯＭＭＩ
Ｔ
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：どのトランザクションがロールバックするか？
ロック・リストを読みながら、デッドロック・ディテクターは、内部処理のためにロック・チェインを作成します。
チェインを作成されると、デッドロック・ディテクターは、デッドロックの存在を検知するために調査をします。
デッドロックがあると、チェインの中の最後のトランザクションが選ばれてロールバックされます。
例：
１．トランザクションＸが、レコード10を挿入
２．トランザクション１が、レコード１を更新
３．トランザクション２が、レコード２を更新
４．トランザクション１が、レコード２を更新しようとするが、レコード２はロックされているのでＬＯＣＫ-ＷＡＩ
Ｔ
状態になる。
５．トランザクションＸが、コミット
６．トランザクション２が、レコード１を更新しようとするが、レコード２はロックされているのでＬＯＣＫ-ＷＡＩ
Ｔ
状態になる。この時、
上記のトランザクションＸがステップ１で使用していたロックリストの場所を、再利用するかもしれません。
この場合、デッドロック・ディテクターは、ロックリストの最後にトランザクション1を見つけて、トランザクション１をロールバックする
可能性があります。
どのトランザクションがロールバックされるかを、予想することはできません。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 81-82 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
デッドロックの発生と回避
デッドロック発生の要因
ロック・エスカレーションの発生
アプリケーション内での表ロックの取得
ＢＩ
ＮＤ時の分離レベル(ISOLATION)の範囲が不必要に広い
複数アプリケーションが幾つかの同じ行に、異なる順番でロックを取得しようとしている
デッドロック発生の回避
ｌ
ｏｃｋｌ
ｓｔDB CFGを増やす
ｍａｘｌ
ｏｃｋｓDB CFGを増やす
ロックの範囲がより狭い分離レベルを使用
同一表への大量更新時には、あらかじめ表ロックを取得し、処理後速やかにＣＯＭＭＩ
Ｔを行う
頻繁なＣＯＭＭＩ
Ｔ
ＷＩ
ＴＨＲＥＬＥＡＳＥオプション付きのカーソルのＣＬＯＳＥ（
ＲＲ・ＲＳの時のみ）を使用
例外処理ルーチンの組み込み
ＳＱＬＣＯＤＥ＝−９１１、ＳＱＬＥＲＲＤ（
２）
＝２
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：デッドロックの発生と回避
デッドロックの発生と回避
デッドロック監視のしくみ
ｄｌ
ｃｈｋｔ
ｉ
ｍｅDB CFG：デッドロックを監視する時間間隔（ミリ秒）。省略時値１０秒。
関連する構成パラメーター
LOCKLIST DB CFG：省略時値(ページ) UNIX 100, OS2/NT(リモートクライアントあり） 50
１データベースあたりでロックに使用されるメモリーの上限。
MAXLOCKS DB CFG：省略時値(%) UNIX 10 , OS2/NT 22
ＬＯＣＫＬＩ
ＳＴの中で１アプリケーションが使用可能なメモリーの割合。
この値に達するとロック・エスカレーションが発生する。
デッドロック発生の要因
ロック・エスカレーションが発生している。
アプリケーション内で表ロックを取得している。
ＢＩ
ＮＤ時の分離レベル(ISOLATION)の範囲が不必要に広い。
複数アプリケーションが幾つかの同じ行に、異なる順番でロックを取得しようとしている。
デッドロック発生の回避
ｌ
ｏ
ｃ
ｋ
ｌ
ｓ
ｔDB CFGを増やす
ｍａｘｌｏｃｋｓDB CFGを増やす
ｄｌ
ｃｈｋｔ
ｉ
ｍｅDB CFGを増やす
ロックの範囲がより狭い分離レベルをを使用する。
同一表に大量の更新処理がある場合には、あらかじめ表ロックを取得し、処理後速やかにＣＯＭＭＩ
Ｔを行う。
頻繁なＣＯＭＭＩ
Ｔ
ＷＩ
Ｔ
ＨＲＥＬＥＡＳＥオプション付きのカーソルのＣＬＯＳＥ（ＲＲ・ＲＳの時のみ）を使用することにより、
カーソルのＣＬＯＳＥ時に全てのＲｅａｄＬｏｃｋをはずす。
このためRepeatable Readにならない可能性があることに注意。
例外処理ルーチンの組み込み
デッドロックの発生を検知し、処理の再試行を行うルーチンを用意しておく
デッドロックの戻り値：ＳＱＬＣＯＤＥ＝−９１１、ＳＱＬＥＲＲＤ（２）＝２
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 83-84 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
６．ロックに関するモニタリング
以下に関するモニタリング項目と使用方法
デッドロック検知のためのモニター項目
ロック待機（
Lock-Wait）検知のためのモニター項目
ロック・エスカレーション検知のためのモニター項目
モニター・ツール
スナップショット・モニター
イベント・
モニター
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロックに関するモニタリング
スナップショット・モニター
ある一時点でのデータベース活動状況を収集
カウンター･タイプのモニター項目は、前回のＲＥＳＥＴ時点から積算された値になる
コマンドおよびコントロール･センターで使用可能
スナップショット・モニターの基本的な使用手順(コマンドの場合）
1.収集するレベルの選択
Database Manager,Database,Application.Tablespace,Table,Lock
UDB V5からのレベル：Bufferpool,FCM for all nodes,Locks for applicaion (Agentid,ApplID)
2.収集する情報グループの選択
モニタースイッチＤＢＭ構成パラメーターの更新
ＵＰＤＡＴＥＤＢＭＣＦＧＵＳＩ
ＮＧＤＦＴ＿ＭＯＮ＿ｘｘｘｘＯＮ
モニタースイッチ：DFT_MON_SORT(SORT),DFT_MON_LOCK(LOCK),DFT_MON_TABLE(TABLE),
DFT_MON_BUFPOOL(BUFFERPOOL),DFT_MON_UOW(UOW),DFT_MON_STMT(STATEMENT)
3.カウンターの値をリセット
ＲＥＳＥＴＭＯＮＩ
Ｔ
ＯＲコマンド
4.収集するレベルを指定し、スナップショット・データの収集
ＧＥＴＳＮＡＰＳＨＯＴコマンド
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 85-86 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：ロックに関するモニタリング
イベント・モニター
イベント・モニター開始時点から停止時点までの、データベース活動イベント・データを収集
コマンドおよびコントロール・センターで使用可能
イベント・モニターの使用手順(コマンドの場合）
1.イベント・モニターの作成
ＣＲＥＡＴＥＥＶＥＮＴＭＯＮＩ
ＴＯＲステートメント
2.イベント・モニターの活動化
ＳＥＴＥＶＥＮＴＭＯＮＩ
ＴＯＲＳＴＡＴＥコマンド
3.イベント・トレースのフォーマット
ｄｂ２ｅｖｍｏｎコマンドによるフォーマットと標準出力先への出力
（例）db2evmon -db DBNAME -evm EVENTMON_NAME または
db2evmon -path EVMON_FILE_PATH
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロックに関するモニタリング
イベント一覧
イベント・タイプと収集情報
イベント・タイプ
収集されるタイミング
収集できる情報
Deadlock
デッドロック発生時
関連したアプリケーションとロック
Statements
ＳＱＬの終了時
ステートメントの開始／終了時刻、CPU時間、動的SQL
文、SQLCA、FETCU行数など
Statements
(パラレル環境のみ)
サブセクション終了時(パラレル環境のみ)
実行時間、表、表キュー、CPU時間(パラレル環境のみ)
Transactions
Connections
Database
ＵＯＷ終了時
接続終了時
データベース非活動化もしくは、最後の接続の
切断時
UOWの開始／終了時刻、CPU時間、ロック、ログ
アプリケーション・レベルの全カウンター情報
データベース・レベルの全カウンター情報
Bufferpools
データベース非活動化もしくは、最後の接続の
切断時
バッファープール、プリフェッチャーページクリーナー、
ダイレクトI/O
Tablespaces
データベース非活動化もしくは、最後の接続の
切断時
バッファープール、プリフェッチャーページクリーナー、
ダイレクトI/O
Tables
データベース非活動化もしくは、最後の接続の
切断時
行の読み込み／書き込み
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 87-88 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Lockに関するモニター項目一覧（１）
モニター項目
Snapshotの種類
モニター
スイッチ
基本
Eventの種類
タイプ
Locks Held
データベース
アプリケーション
ロック
データベース
N/A
ゲージ
基本
N/A
ゲージ
データベース
アプリケーション
データベース
アプリケーション
基本
ロック
基本
基本
カウンター
Exclusive Lock Escalations
データベース
アプリケーション
基本
基本
Lock Mode
アプリケーション
ロック
ロック
アプリケーション
ロック
アプリケーション
ロック
ロック
ロック
基本
ロック
ロック
ロック
ロック
データベース
接続
データベース
接続
トランザクション
データベース
接続
トランザクション
デッドロック
N/A
N/A
情報
情報
デッドロック
情報
Total Lock List Memory In
Use
Deadlocks Detected
Lock Escalation
Lock Status
Lock Object type waited
on
Lock Object Name
カウンター
カウンター
情報
注： N/A＝モニター不可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Lockに関するモニター項目一覧（１）
モニター項目のタイプ
カウンター
値が増加していく項目
DATABASE SNAPSHOTの場合、データベースへの接続が存在する間は値が増加し続ける。
RESET MONITORコマンドにより０にリセット可能。 "Deadlock Detected"など。
DATABASE EVENTの場合、イベント・モニター開始から停止までに起きたイベント数が積算される。
ゲージ
現在の値を示す項目
ウオーターマーク
最大／最小値を示す項目
カウンター・タイプの項目値のリセット
RESET MONITOR [ALL | FOR DATABASE database_name]
値を０にリセット後モニターを開始したい場合には、GET SNAPSHOTコマンドを実行する現行セッションからRESET MONITORコ
マンドを実行すること
他のセッションでのモニリングに影響を与えない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 89-90 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Lockに関するモニター項目一覧（２）
モニター項目
Snapshotの種類
Number of Lock Timeouts
データベース
アプリケーション
N/A
Maximum Number of Locks
Held
Connections involved in
Deadlock
Lock Waits
モニター
スイッチ
基本
基本
N/A
N/A N/A
データベース
アプリケーション
データベース
アプリケーション
ロック
ロック
ロック
ロック
データベース
ロック
アプリケーション
基本
基本
ＵＯＷ
アプリケーション
ロック
Agent ID Holding Lock
アプリケーション
ロック
Application ID Holding Lock アプリケーション
ロック
Rolled Back Application
N/A
ロック
ロック
ロック
ロック
ロック
ロック
N/A
Time Waited On Locks
Current Agents Waiting On
Locks
Total Time Unit of Work
Waited on Locks
Lock Wait Start Timestamp
注： N/A＝モニター不可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 91-92 )
Eventの種類
タイプ
データベース
接続
トランザクション
カウンター
デッドロック
ゲージ
データベース
接続
データベース
接続
トランザクション
N/A
カウンター
N/A
カウンター
デッドロック
N/A
タイムスタン
プ
情報
デッドロック
情報
デッドロック
情報
カウンター
カウンター
ゲージ
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Deadlock検知のためのモニター項目
Deadlock detected
発生したデッドロックの合計数
Number of applications deadlocked(Connections involved in Deadlock)
デッドロックに関係している接続の数
Rolled Back Application
DAEDLOCK発生時にロールバックされたアプリケーションＩ
Ｄ
モニター項目
Snapshotの種類
モニタースイッチ
Eventの種類
タイプ
Deadlock detected
データベース
アプリケーション
N/A
基本
ロック
N/A
データベース
接続
デッドロック
カウンター
N/A
N/A
デッドロック
情報
Number of applications
deadlocked
(Connections involved in
Deadlock)
Rolled Back Application
注： N/A＝モニター不可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 93-94 )
ゲージ
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Deadlockの例:イベント・モニターの出力（１）
Connection Header Event
接続しているアプリケーションに関する情報群
ApplID：各アプリケーションを識別するためのユニークIDで、全てのイベント出力の紐付けに使用する
3) Connection Header Event ...
Appl Handle: 37
Appl Id: *LOCAL.udbinst.980908081001
Appl Seq number: 0001
DRDA AS Correlation Token: *LOCAL.udbinst.980908081001
Program Name : db2bp_s
Authorization Id: UDBINST
Execution Id : udbinst
Codepage Id: 932
Country code: 81
Client Process Id: 27700
Client Database Alias: sample
Client Product Id: SQL05000
Client Platform: AIX
Client Communication Protocol: Local
Client Network Name:
Connect timestamp: 09/08/1998 17:10:01.044707
4) Connection Header Event ...
Appl Handle: 39
Appl Id: *LOCAL.udbinst.980908081302
Appl Seq number: 0001
DRDA AS Correlation Token: *LOCAL.udbinst.980908081302
Program Name : db2bp_s
Authorization Id: UDBINST
Execution Id : udbinst
Codepage Id: 932
Country code: 81
Client Process Id: 34158
Client Database Alias: sample
Client Product Id: SQL05000
Client Platform: AIX
Client Communication Protocol: Local
Client Network Name:
Connect timestamp: 09/08/1998 17:13:02.434329
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Deadlockの例:イベント・モニターの出力（１）
Connection Header Eventは、データベースに接続する各アプリケーションの詳細情報をモニターするイベントです。
ApplIDにより、全てのイベント・モニター出力にあるイベントの関連付けを行うことができます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 95-96 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Deadlockの例:イベント・モニターの出力（２）
Deadlock Event
デッドロック発生に関する情報群
Deadlock Event：デッドロック発生情報
Deadlocked Connection：デッドロック発生にかかわったアプリケーション情報
8)Deadlock Event ...
Number of applications deadlocked: 2
Deadlock detection time: 09/08/1998 17:20:51.689229
Rolled back Appl Id: : *LOCAL.udbinst.980908081001
Rolled back Appl seq number: : 0001
10) Deadlocked Connection ...
Appl Id: *LOCAL.udbinst.980908081302
Appl Seq number: 0001
Appl Id of connection holding the lock: *LOCAL.udbinst.980908081001
Seq. no. of connection holding the lock:
Lock wait start time: 09/08/1998 17:20:44.248569
9) Deadlocked Connection ...
Deadlock detection time: 09/08/1998 17:20:51.689229
Appl Id: *LOCAL.udbinst.980908081001
Table of lock waited on
: TEST2
Appl Seq number: 0001
Schema of lock waited on : UDBINST
Appl Id of connection holding the lock: *LOCAL.udbinst.980908081302Tablespace of lock waited on : DMSTBS1
Seq. no. of connection holding the lock:
Type of lock: Table
Lock wait start time: 09/08/1998 17:20:45.179299
Mode of lock: S
Deadlock detection time: 09/08/1998 17:20:51.689229
Lock object name: 18
Table of lock waited on
: TEST1
Schema of lock waited on : UDBINST
Tablespace of lock waited on : DMSTBS1
Type of lock: Table
Mode of lock: S
Lock object name: 17
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Deadlockの例:イベント・モニターの出力（２）
Deadlock Eventにつづいて、Deadlock Connection. Statement Eventの情報が続きます。
Deadlock Eventには、デッドロック発生に関係したアプリケーションの数、デッドロック発生時刻、ロールバックしたアプリケーションID
が入ります。
Deadlock Connectionには、デッドロック発生に関係したアプリケーション接続に関する情報が入ります。
Statement Eventには、デッドロック時にロールバックしたSQLステートメントが入ります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 97-98 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Deadlockの例:イベント・モニターの出力（３）
Statement Event
Statement Event：デッドロック発生のためにロールバックしたSQL情報
11) Statement Event ...
Appl Handle: 37
Appl Id: *LOCAL.udbinst.980908081001
Appl Seq number: 0001 Type
: Dynamic
Operation: Execute Immediate
Section : 203
Creator : NULLID
Package : SQLC3B0C
Text : delete from test1 Start Time: 09/08/1998 17:20:45.178634
Stop Time: 09/08/1998 17:20:51.690788
Number of Agents created: 1
User CPU: 0.010000 seconds
System CPU: 0.000000 seconds
＜途中省略＞
Internal rows deleted: 0
Internal rows updated: 0
Internal rows inserted: 0
SQLCA:
sqlcode: -911
sqlstate: 40001
SQL0911N デッドロックまたはタイムアウトのため，現在のトランザクションがロールバックされました。理由コードは "2"。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 99-100 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Lock Wait検知のためのモニター項目
Lock Waits
ロック待ちが起きた合計回数
Number of Lock Timeouts
ロックタイムアウトの発生回数
Time Waited on Locks
ロック待ちに要した合計時間（ｍｓ）
Total Time Unit of Works Waited on locks
ＵＯＷがロック待ちに要した時間（ｍｓ）
Current Agents waiting on Locks
ロック待ちをしているdb2agentの数
Agent ID Holding Lock
ロック待ちの対象となるロックを保持している、db2agentのアプリケーション・ハンドル。0の場合、対象となるロックは、
Indoubt transactionにより保持されているロックであるという意味。"Applocation ID Holding Lock"を使用すること。
Application ID Holding Lock
ロック待ちの対象となるロックを保持しているdb2agentのアプリケーションＩ
Ｄ。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 101-102 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Lock Waitの例：スナップショット・モニターの出力（１）
ロック・スナップショット
各アプリケーションごとのロック取得およびロック待機の状況を表示する
（例）1.applhndl-74を実行 ”select * from department”(Isolation=RR)
2.applhndl-72を実行 ”delete * from department”(Isolation=RR)
3. db2 GET SNAPSHOT FOR LOCKS ON sample
Database Lock Snapshot
Database name
= SAMPLE
Database path
= /sampledb/udbinst/NODE0000/SQL00001/
Input database alias
= SAMPLE
Locks held
=4
Applications currently connected
=2
Agents currently waiting on locks
=1
Snapshot timestamp
= 09/14/1998 14:01:58.887416
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 74
= *LOCAL.udbinst.980914050119
= 0001
= db2bp_s
= UDBINST
= UOW Waiting
= 09/14/1998 14:01:19.362541
= 932
=2
=0
Object Name Object Type Tablespace Name
Table Schema
Table Name
Mode Status
----------- --------------- -------------------- -------------------- -------------------- ---- ---------5
Table
USERSPACE1
UDBINST
DEPARTMENT
S Granted
0
Internal
S Granted
注：見やすさのためにV5.2の出力を使用しています
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Lock Waitの例：スナップショット・モニターの出力（１）
ロック・スナップショットの出力では、各アプリケーションが取得するロックについての情報（ロックを取得しているオブジェクト名、ロッ
ク・モードなど）を取得することができます。さらに、”Application Status"が"LOCK-WAIT"になっているアプリケーションについて
は、ロック待機に関する情報も表示されます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 103-104 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Lock Waitの例：スナップショット・モニターの出力（２）
ロック待機の情報
Application Stateが"Lock-wait"の場合、ロック保留状況の詳細が表示される
デッドロックの場合、"Lock-wait"状態のアプリケーションが複数存在し、互いに互いの持つロックを待つ状況になる
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 72
= *LOCAL.udbinst.980914045843
= 0001
= db2bp_s
= UDBINST
= Lock-wait
= 09/14/1998 14:01:55.417613
= 932
=2
= 3469
ロック待ちのサブセクション
=0
ロック保留中エージェント ID
= 74
ロック保留中のアプリケーション ID
= *LOCAL.udbinst.980914050119
ロック・オブジェクト・タイプ
= Tabel
ロック・モード
= Share Lock (S)
ロック保留中の表スペース名
= USERSPACE1
ロック保留中の表スキーマ
= UDBINST
ロック保留中の表名
= DEPARTMENT
ロック待機開始タイムスタンプ
= 09/14/1998 14:01:55.417616
Object Name Object Type Tablespace Name
Table Schema
Table Name
Mode Status
----------- --------------- -------------------- -------------------- -------------------- ---- ---------0
Internal
S Granted
0
Internal
S Granted
注：見やすさのためにV5.2の出力を使用しています
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 105-106 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Lock Waitの例：スナップショット・モニターの出力（３）
アプリケーション・スナップショット
アプリケーション単位に、デッドロックの発生回数、ロック・エスカレーションの発生回数、
ロック待機の発生回数などを表示する
GET SNAPSHOT FOR APPLICATIONS ON sample
Application Snapshot
Application handle
= 72
Application status
= Lock-wait
Status change time
= 09/14/1998 14:05:50.746989
Application code page
= 932
Application country code
= 81
DUOW correlation token
= *LOCAL.udbinst.980914045843
Application name
= db2bp_s
Application ID
= *LOCAL.udbinst.980914045843
Sequence number
= 0001
Connection request start timestamp
= 09/14/1998 13:58:43.109706
Connect request completion timestamp
= 09/14/1998 13:58:43.112099
＜中略＞
Last reset timestamp
= 09/14/1998 14:05:34.658874
Snapshot timestamp
= 09/14/1998 14:05:59.598448
Locks held by application
=3
Lock waits since connect
=2
Time application waited on locks (ms)
= 8852
Deadlocks detected
=0
Lock escalations
=0
Exclusive lock escalations
=0
Number of Lock Timeouts since connected = 0
Total time UOW waited on locks (ms)
= 8852
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 107-108 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Lock Waitの例：スナップショット・モニターの出力（４）
GET SNAPSHOT FOR DATABASE ON sample
データベース・
スナップショット
データベース単位に、デッドロックの発生回数、ロック・エスカレーションの発生回数、
ロック待機の発生回数などを表示する
Database Snapshot
Database name
= SAMPLE
Database path
= /sampledb/udbinst/NODE0000/SQL00001/
Input database alias
= SAMPLE
Database status
= Active
Catalog node number
=0
Catalog network node name
=
Operating system running at database server= AIX
Location of the database
= ローカル
First database connect timestamp = 09/14/1998 13:55:50.963945
Last reset timestamp
= 09/14/1998 14:05:34.658874
Last backup timestamp
= 09/08/1998 14:23:24.640849
Snapshot timestamp
= 09/14/1998 14:08:34.024562
＜中略＞
Locks held currently
=5
Lock waits
=2
Time database waited on locks (ms)
= 31039
Lock list memory in use (Bytes)
= 1296
Deadlocks detected
=0
Lock escalations
=0
Exclusive lock escalations
=0
Agents currently waiting on locks
=1
Lock Timeouts
=1
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 109-110 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Lock Escatlation検知のためのモニター項目
ロック・
エスカレーション発生の検知
Lock Escalations
Exclusive Lock Escalationsを含むロック・エスカレーションの回数
排他制御のないロック・エスカレーション回数＝ Lock Escalations − Exclusive Lock Escalations
Exclusive Lock Escalations
表の排他ロックを取得したロック・エスカレーションの回数
他の更新・照会処理の両方に影響を与えることになるため、要注意。
Maximum Number of Locks Held
ロックが保持された最大値
”１アプリケーションが保持できるロック数の上限”に近似の場合、エスカレーションの原因となった可能性あり。
１アプリケーションが保持できるロック数の上限
＝（LOCKLIST(ページ) ＊４０９６／３２）＊（MAXLOCKS(％) ／１００）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Lock Escatlation検知のためのモニター項目
ロック・エスカレーションの発生を確認するためには、既出のdb2diag.logで確認する方法か、または、モニターツールを使用して確認
することになります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 111-112 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ロックリスト使用状況のモニタリング
１ＤＢあたりのロックに使用されるメモりー（ページ）
量の算出
1アプリケーションあたりの平均ロック数を５１２個と仮定した場合の、使用ページ数
下限（ページ）＝ (512 * 32 * MAXAPPLS ) / 4096
上限（ページ）＝ (512 * 64 * MAXAPPLS ) / 4096
MAXAPPLS DB CFG：１データベースあたりの最大同時稼動アプリケーション数
(省略時値：ＵＮＩ
Ｘ４０,ＮＴ（リモートクライアントあり）２０）
１ロックあたりに必要なメモリー
６４バイト：オブジェクトへの最初のロック３２バイト：ロックのあるオブジェクトへのロック
この算出値をLOCKLIST DB CFGの値と比較し、ロックリストが十分かを検討する。
ロックリスト使用状況の確認
Total Lock List Memory In USE
使用中のロックリスト･メモリーのバイト数
使用されているロックリストの割合（％）
＝（Total Lock List Memory In USE（バイト）／４０９６バイト）／ LOCKLIST（ページ）＊１００
この値が大きい場合にはロックリスト・サイズの調整、またはアプリケーションのチューニングが必要となる。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 113-114 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ロック数のモニタリング
現在保持されているロック数の確認
Locks Held
データベース・レベルのスナップショット
データベース全体で保持されているロック数
１アプリケーション当たりの平均ロック保持数
= ( Lock Held Currently / Applications Connected Currently )
：この値が大きい場合には、アプリケーションでのロック保持に関するチューニングが必要
アプリケーション・レベルのスナップショット
特定アプリケーションが保持するロック数
１アプリケーションが保持できるロック数の上限＝ ( LOCKLIST * 4096 / 32 ) * ( MAXLOCKS / 100 )
この値に達するとロック・エスカレーションが発生する。
３２：ロックのあるオブジェクトへのロックに必要なメモりー
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ロック数のモニタリング
Lock Heldの値は、データベース・スナップショットを取った場合と、アプリケーション・スナップショットを取った場合に、数値が示す内
容が異なるので注意が必要です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 115-116 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
７．Next Key Locking
Next key locking とは：
索引のある表へのINSERT/DELETEを行った時、該当行の次のHIGH KEYを持つ行に
取得されるロック
ISOLATION=RRで索引のある表に対してSELECTを実行した場合にも、索引キーの次の行にSロックを取得する
該当行の次のHIGH KEYを持つ行が存在しない場合、仮想のHIGHEST KEY行にロックが取得
される
昇順の索引であれば、END OF TABLE行にロックが取得される
降順の索引であれば、BEGIN OF TABLE行にロックが取得される
INSERTの場合
Ｉ
ＮＳＥＲＴ処理中のみロックで、瞬間ロック（instantaneous lock）
ＣＯＭＭＩ
Ｔ／ＲＯＬＬＢＡＣＫまでロックを取得しているわけではない
ＬＯＣＫのスナップショット・モニターで確認不可能
DELETEの場合
ＣＯＭＭＩ
Ｔ／ＲＯＬＬＢＡＣＫまでロックを取得している
ＬＯＣＫのスナップショット・モニターで確認可能
索引に関する限り、UPDATEは、DELETE後にINSERTする処理と同様
Next key lockingは、表に作成された全索引のNext KeyにLOCKを取得
UDB EEEにおいて、Next Key Lockingはノードをまたがらない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Next Key Locking
Next Key lockingは、行が索引からＤＥＬＥＴＥされた時やＩ
ＮＳＥＲＴされた時に、索引の次の行にも排他ロックがかけられることです。
DB2 UDBでは、このロックは特別な排他ロック（NX,NW ロック）です。これらは特別なNext Key Share((NS)と互換性があります。ＮＳ
は、cursor stability(CS)やread stability(RS)分離レベルを使用して、表スキャンや索引スキャンを行った時に、行をロックするモード
です。
しかし、ＮＷ／ＮＸロックは，ＲＲ分離レベルで索引スキャンする場合に行をロックする時に使われる、Ｓロックとは互換性がありませ
ん。
DB2の索引では、ＵＰＤＡＴＥは、ＤＥＬＥＴＥの後でＩ
ＮＳＥＲＴが起こった場合と同じと考えられます。索引キーの一部である列の値を更
新するSQLステートメントを発行した場合、索引のキー・エントリーに対する更新処理は以下の順で行われます。
更新前のキー・エントリーが索引から削除されます。
その後、新しいキーの値が索引に挿入されます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 117-118 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Next Key Lockingの例
前提
表ｔ
ａ
ｂ
1は２列 (int, char(30))のデータをもつ
create table tab1 (col1 integer, col2 char(30) )
列１に昇順の索引あり
create index col1ix on tab1 ( col1 asc )
表と索引の内容
索引 COL1IX
COL1IX
1
2
3
5
7
20
表 TAB1
COL1
1
2
3
5
7
20
COL2
Joe
Fred
Jim
John
Ann
Albert
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 119-120 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
DELETE時のNext Key locking
カタログ表ではない表(索引あり）へのＤＥＬＥＴＥ
(例）Delete from tab1 where column1 = 3
V5.2GA版まで：DELETE行にX、次の行にNX
V5.2+Fixpack7以降、およびV6.1：DELETE行にX、次の行にX
COL1
1
2
3
5
7
20
COL2
Joe
Fred
Jim
John
Ann
Albert
DELETE行,
Xロック取得
NX lock取得(V5.2 Fixpack6まで)
Xロック取得(V5.2+Fixpack7以降およびＶ6.1）
カタログ表(索引あり）へのＤＥＬＥＴＥ
(例）Drop table tab1
SYSCAT.TABLES表のDELETE行にX、次の行にNX （V6.1まで）
SYSCAT.TABLES表のDELETE行にX、次の行にX （V7.1以降）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：DELETE時のNext Key locking
カタログ表以外の表へのDELETE
(V７．１)
db2 -c- "delete from department where deptno='D11'"
db2 get snapshot for locks on sample
Database Lock Snapshot
Database name
= SAMPLE
（途中省略）
Locks held
=6
Total wait time (ms)
=0
List Of Locks
Lock Object Name = 81929
Object Type
= Row
Tablespace Name = INDTBS
Table Schema
= UDBV61
Table Name
= DEPARTMENT
Mode
= X ＜＝＝ＮｅｘｔＫｅｙＬｏｃｋ
Status
= Granted
Lock Escalation = NO
Lock Object Name = 81928
Object Type
= Row
Tablespace Name = INDTBS
Table Schema
= UDBV61
Table Name
= DEPARTMENT
Mode
=X
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 121-122 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：DELETE時のNext Key locking
カタログ表へのDELETE (V７．１)
db2 -c- "drop table department"
db2 get snapshot for locks on sample
Database Lock Snapshot
Database name
（途中省略）
= SAMPLE
List Of Locks
Lock Object Name = 3843
Object Type
= Row
Tablespace Name = SYSCATSPACE
Table Schema
= SYSIBM
Table Name
= SYSTABLES
Mode
= X ＜＝＝Ｎｅｘｔ
ＫｅｙＬｏｃｋ
Status
= Granted
Lock Escalation = NO
Lock Object Name = 3842
Object Type
= Row
Tablespace Name = SYSCATSPACE
Table Schema
= SYSIBM
Table Name
= SYSTABLES
Mode
=X
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 123-124 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
DELETE時のNext Key lockingと表スキャン
DELETEによりNext Key Lockingがある状態で、他のアプリケーション
が表スキャンした場合
(例）Appl1 : Delete from tab1 where column1 = 3
Appl2 : Select * from tab1 where column1 >= 2
URの場合、結果セットが戻る
RR,CS,RSの場合、LOCK-ＷＡＩ
Ｔ
Appl2のSELECT
索引
ＣＯＬ１Ｉ
Ｘ
１
２
３
５
７
２０
RR,CS,RS UR
表
COL1
1
2
3
5
7
20
COL2
Joe
Fred
Bill
John
Ann
Albert
X
LOCK-WAIT
NXまたはX
Appl1のDELETE
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：DELETE時のNext Key lockingと表スキャン
他のアプリケーションが取得したDELETE行へのXロックおよびNext Key Lock（NXまたはXロック）が存在する場合、表スキャンは、
DELETE行に対するXロックでLOCK-WAITすることになります。表スキャンは、最初の行から順にデータを読んでいくしくみだからで
す。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 125-126 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
DELETE時のNext Key lockingと索引スキャン
DELETEによりNext Key Lockingがある状態で、他のアプリケーション
が索引スキャンした場合
(例）Appl1: Delete from tab1 where column1 = 3
Appl2: Select * from tab1 where column1 >= 2
データ読み取りのしくみ
１．索引キー”２”を読む
２．索引キー”２”を持つ表データを読む
３．索引キー”３”はDELETE行であり、スキップされる
４．索引キー”５”を読む
５．索引キー”５”を持つ表データを読むが、ＮＸまたはＸロックが取得されている
６．ISOLATIONにより、動作が異なる（次ページ参照）
Appl1のDELETE
Appl2のSELECT
１
３
４
ｔａｂ１
ＣＯＬ１Ｉ
Ｘ
１
２
３
５
７
２０
２
５
COL1
1
2
3
5
7
20
COL2
Joe
Fred
Bill
John
Ann
Albert
X
NXまたは
X
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：DELETE時のNext Key lockingと索引スキャン
他のアプリケーションが取得したDELETE行へのXロックおよびNext Key Lock（NXまたはXロック）が存在する場合に、索引スキャ
ンの動作は、バージョンおよびISOLATIONレベルにより異なります、。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 127-128 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
DELETE時のNext Key lockingとロック競合
照会アプリケーションとNext Key Lockの競合
UDBのバージョン、SELECTのアプリケーションのISOLATION（分離レベル）により、照会処理
の動作が異なる
UDBのバージョン
照会処理の
分離レベル
V5＋FP６
V5＋FP６
V5＋FP６
V5＋FP７、V6.1以降
V5＋FP７、V6.1以降
V5＋FP７、V6.1以降
ＲＲ
ＲＳ，ＣＳ
ＵＲ
ＲＲ
ＲＳ，ＣＳ
ＵＲ
SELECT時 SELECT行に既
のロック
に取得されてい
たNext Key
Lock
Ｓ
ＮＸ
ＮＳ
ＮＸ
Ｎ／Ａ
ＮＸ
Ｓ
Ｘ
ＮＳ
Ｘ
Ｎ／Ａ
Ｘ
結果
LOCK-WAIT
SELECT可能
SELECT可能
LOCK-WAIT
LOCK-WAIT
SELECT可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：DELETE時のNext Key lockingとロック競合
行がＤＥＬＥＴＥされると、NXロックが索引の次の行に取得されます。索引スキャンを行う他のトランザクションが、ＤＥＬＥＴＥされた行
について確認できるマーカーとなります。CS,RSトランザクションは照会行にNSロックを獲得しますが、これはNXロックと互換性があ
ります。そこで、CS,RSトランザクションはＤＥＬＥＴＥされた行をよみ飛ばすことができます。もし削除がロールバックされたとしても、
CS,RSアイソレーションは幻像読み取りが許されているので、違反をおかしたことにはなりません。
幻像読み取りは、RRの分離レベルには許されていません。そこで、索引スキャンは、NXを取得しているトランザクションがコミットさ
れるか、ロールバックされるまで、NXロックが取得された行を待たなければなりません。RR索引スキャンは、NXロックと互換性がな
いSロックを獲得するため、この動作が保証されることになります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 129-130 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
INSERT時のNext Key locking
カタログ表ではない表
（例）
Insert into tab1 values (8,'Alice')
INSERT行にＷロック、次の行にNWロック
ＮＷロックはインスタント・ロックであり、GET SNAPSHOTで確認不可能
DB2_RR_TO_RS=YESの場合
INSERT行にＸロック
ｔａｂ１
COL1
1
2
3
5
7
8
20
COL2
Joe
Fred
Jim
John
Ann
Alice
Albert
INSERT行,
Ｗロック取得
ＮＷロック取得
カタログ表
(例）Create table tbl1
INSERT行にXロック（Ｖ６．１まで）
INSERT行にＷロック（Ｖ７．１以降）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：INSERT時のNext Key locking
索引を持った表に行をＩ
ＮＳＥＲＴする場合、DB2はＩ
ＮＳＥＲＴした行にＷ，表にＩ
Ｘロックを取得し、さらに定義された全ての索引につい
て、ＩＮＳＥＲＴ行の次に高いキーを持つ行にＮＷロックを取得します。
ＮＷロックは、ユニーク索引のある列に重複したキーが発生するのを防ぐのと、ＲＲ分離レベルを保証するために行われます。
前の例では、ＩＮＳＥＲＴは以下のロックを獲得します。
Ｉ
Ｘ表ロック
Ｉ
ＮＳＥＲＴしたレコードへのＸロック
全索引のＮｅｘｔＫｅｙへのＮＷロック
索引のＮｅｘｔＫｅｙに対応するデータ行へのNW ロック
（この場合はｃｏｌ
１に対して一つの索引のみが定義されています。そこで、レコード（20,Albert)はNW ロックがかかります。）
結果を変更するような別のレコードをＩ
ＮＳＥＲＴすることはできません。
またNext Key ロックを待っているので、(8,'Annie')をＩ
ＮＳＥＲＴすることもできません。
ＮＷはインスタント・ロックです。このため、作業単位のＣＯＭＭＩ
Ｔ
／ＲＯＬＬＢＡＣＫを待たずに、Ｉ
ＮＳＥＲＴ処理の終了と共にはずされ
ます。従って、GET SNAPSHOTコマンドで取得状況を確認することはできません。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 131-132 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：INSERT時のNext Key locking
DB2_RR_TO_RS=NO(V7.1)
db2 -c- "INSERT INTO department VALUES ('C11','TEST','000010','A00',NULL)"
db2 get snapshot for locks on sample
（途中省略）
List Of Locks
Lock Object Name = 81933
Object Type
= Row
Tablespace Name = INDTBS
Table Schema
= UDBV61
Table Name
= DEPARTMENT
Mode
=W
<===== Ｉ
ＮＳＥＲＴ行へのロック
Status
= Granted
Lock Escalation = NO
Lock Object Name = 7
Object Type
= Table
Tablespace Name = INDTBS
Table Schema
= UDBV61
Table Name
= DEPARTMENT
Mode
= IX
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：INSERT時のNext Key locking
DB2_RR_TO_RS=YES(V7.1)
db2 -c- "INSERT INTO department VALUES ('C11','TEST','000010','A00',NULL)"
db2 get snapshot for locks on sample
（途中省略）
List Of Locks
Lock Object Name = 3372573671
Object Type
= Key Value
Tablespace Name = INDTBS
Table Schema
= UDBV61
Table Name
= DEPARTMENT
Mode
=X
Status
= Granted
Lock Escalation = NO
Lock Object Name = 81933
Object Type
= Row
Tablespace Name = INDTBS
Table Schema
= UDBV61
Table Name
= DEPARTMENT
Mode
=X
<=== Ｉ
ＮＳＥＲＴ行へのロック
Status
= Granted
Lock Escalation = NO
Lock Object Name = 7
Object Type
= Table
Tablespace Name = INDTBS
Table Schema
= UDBV61
Table Name
= DEPARTMENT
Mode
= IX
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 133-134 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
RRでSELECT時のNext Key locking(1)
テスト手順：Select (Isolation=RR) と Insert
１．Appl１（RR)：Select * from tab1 where column1 ＜ 10 （索引スキャン）
２．Appl２（CS)：Insert into tab1 values (8,'Alice')
Appl1:索引スキャン：Select * from tab1 where column1 ＜ 10
RRでのデータ読み取りのしくみ
１．索引キー”１”を読む
２．索引キー”１”を持つ表データ行を読み、Ｓロックを取得する
３．１０以上のキーが見つかるまで、１と２の繰り返し
４．１０以上のキーが見つかったら、ＮｅｘｔＫｅｙＬｏｃｋ（Ｓロック）を取得する
ｔ
ａｂ１
索引
１
３
４
ＣＯＬ１Ｉ
Ｘ
１
２
３
５
７
２０
２
COL1
1
2
3
5
7
20
COL2
Joe
Fred
Bill
John
Ann
Albert
Ｓ
Ｓ
Ｓ
Ｓ
Ｓ
Ｓ
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：RRでSELECT時のNext Key locking(1)
表をＳＥＬＥＣＴする際に索引スキャンが使われている場合、Ｉ
Ｓ表ロックが取得され、行にはＳロックが取得されます。
”SELECT * FROM TAB1 WHERE COL1 < 10”をRR分離レベルで実行すると、最初に表にＩ
Ｓロックを取得し、結果表の全ての行に
S ロックをかけます。索引から結果セットを作成する時に、DB2は条件に合致しない、最初の行まで索引を読みます。この場合は２０
です。
そこで、この例では全ての行にＳロックがかけられます。条件に合致しない最初の行、つまり２０を持つ行には、ＮｅｘｔＫｅｙＬｏｃｋと
してのＳロックが取得されます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 135-136 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
RRでSELECT時のNext Key locking (2)
Appl2:Insert into tab1 values (8,'Alice')
RRの保証のしくみ
１．”８、’Ａｌ
ｉ
ｃ
ｅ
’
”
をＩ
ＮＳＥＲＴするために、次の索引キーを持つ行にＮｅｘｔＫｅｙＬｏｃｋ（ＮＷ）を取得しようとする
２．既にＳロックが取得されているため、ＬＯＣＫーＷＡＩ
Ｔ
する
ｔ
ａｂ１
索引
１
ＮＷ
ＣＯＬ１Ｉ
Ｘ
１
２
３
５
７
２０
２
Ｌｏｃｋ−Ｗａｉ
ｔ
COL1
1
2
3
5
7
20
COL2
Joe
Fred
Bill
John
Ann
Albert
Ｓ
Ｓ
Ｓ
Ｓ
Ｓ
Ｓ
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：RRでSELECT時のNext Key locking(２)
新しいレコード(8,'Alice')をＩ
ＮＳＥＲＴするアプリケーションがある場合、ＲＲの照会結果を保証するようなメカニズムが存在しなければ
なりません。
前述のように、
Ｉ
ＮＳＥＲＴ時に、DB2はnext higher keyにNW ロックをかけます。この例では（20,'Alice')です。
この（20,'Alice')の行は、ＲＲでのＳＥＬＥＣＴの結果としてS ロックが保持されているので、Ｉ
ＮＳＥＲＴはＲＲのトランザクションがコミット
するかロールバックするまで、Ｌｏｃｋ-Ｗａｉ
ｔ
することになります。
ＲＲの照会では、表に存在する行数によっては、表全体にＳロックをかけることがあります。これはＲＲＲの照会では、結果行を作成
するためにアクセスした全ての行にロックをかけるためであり、大きいサイズの表では、表ロックへのロック・エスカレーションが発生
するからです。
Ｓロックは、他のトランザクションがデータ行をスキャン/読み取りをするのを許します。しかし、行を変更することは許しません。これ
により、ＲＲ分離レベルの目的が達成されることになります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 137-138 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
RRでSELECT時のNext Key locking(3)
テスト手順：該当行のないSelect (Isolation=RR) + Insert
１．Appl１（RR)：Select * from tab1 where col1 in (4, 8 ) （索引スキャン）
２．Appl２（CS)：Insert into tab1 values (8,'Alice')
RR実現のしくみ
１．SELECT文の検索条件に合致する索引キーの値が存在しない
２．このため、次のHigh Keyの値にＮｅｘｔ
ＫｅｙＬｏｃｋ（Ｓロック）を取得する
３．INSERT行の索引キー値の次のHigh ValueにNWロックを取得しようとするが、既にSロックが取得されているため、
LOCK−WAITとなる
ｔａｂ１
索引
１
ＣＯＬ１Ｉ
Ｘ
１
２
３
５
７
２０
２
COL1
1
2
3
5
7
20
COL2
Joe
Fred
Bill
John
Ann
Albert
Ｓ
Ｓ
Ｌｏｃｋ−Ｗａ
ｉ
ｔ
３
NW取得要求
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：RRでSELECT時のNext Key locking(３)
表をＳＥＬＥＣＴする際に索引スキャンが使われている場合、Ｉ
Ｓ表ロックが取得され、行にはＳロックが取得されます。
”SELECT * FROM TAB1 WHERE COL1 < 10”をRR分離レベルで実行すると、最初に表にＩ
Ｓロックを取得し、結果表の全ての行に
S ロックをかけます。索引から結果セットを作成する時に、DB2は条件に合致しない、最初の行まで索引を読みます。この場合は２０
です。
そこで、この例では全ての行にＳロックがかけられます。条件に合致しない最初の行、つまり２０を持つ行には、ＮｅｘｔＫｅｙＬｏｃｋと
してのＳロックが取得されます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 139-140 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
RRでSELECT時のNext Key locking(4)
テスト手順：索引のHighest Keyに対するSelect (Isolation=RR) + Insert
１．Appl１（RR)：Select * from tab1 where col1 ＝２０（
索引スキャン）
２．Appl２（CS)：Insert into tab1 values (２２, 'Mel')
RR実現のしくみ
１．SELECT文の検索条件に合致する索引キーの行にＳロックを取得する
２．さらの次のHigh Keyの値にＮｅｘｔＫｅｙＬｏｃｋ（Ｓロック）を取得する
この時、”COL1=20"はHighest Keyなので、End of Tableにロックを取得する
３．INSERT行の索引キー値の次のHigh ValueにNWロックを取得しようとするが、既にSロックが取得されているため、
LOCK−WAITとなる
ｔａｂ１
Ｘ
索引ＣＯＬ１Ｉ
１
１
２
３
５
７
２０
１Ｓロック取得
２
３
Ｓロック取得
COL1
1
2
3
5
7
20
End of Table
COL2
Joe
Fred
Bill
John
Ann
Albert
Ｌｏｃｋ−Ｗａ
ｉ
ｔ
NW取得要求
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：RRでSELECT時のNext Key locking(４)
ロック・スナップショット：索引のHighest Keyに対するSelect (Isolation=RR) + Insert
Appl１のロック取得状況
List Of Locks
Lock Object Name = 0
Object Type
= End of Table
<== End Of Tableへのロック
Tablespace Name = USERSPACE1
Table Schema
= UDBV61
Table Name
= EMPLOYEE3
Mode
=S
Status
= Granted
Lock Escalation = NO
Lock Object Name = 4
Object Type
= Row <== Highest Keyの行へのロック
Tablespace Name = USERSPACE1
Table Schema
= UDBV61
Table Name
= EMPLOYEE3
Mode
=S
Status
= Granted
Lock Escalation = NO
Lock Object Name = 15
Object Type
= Table
Tablespace Name = USERSPACE1
Table Schema
= UDBV61
Table Name
= EMPLOYEE3
Mode
= IS
Status
= Granted
Lock Escalation = NO
Lock Object Name = 0
Object Type
= Internal P Lock
Tablespace Name =
Table Schema
=
Table Name
=
Mode
=S
Status
= Granted
Lock Escalation = NO
Apple２のロック取得とロック待機状況
ロック待ちのサブセクション
=0
ロック保留中エージェント ID
= 24
ロック保留中のアプリケーション ID
= *LOCAL.udbv61.000130014952
ロック・オブジェクト・タイプ
= End of Table <== End Of TableへのLock Wait
ロック・モード
= Share Lock (S)
要求ロック・モード
= Next Key Weak Exclusive (NW)
ロック保留中の表スペース名
= USERSPACE1
ロック保留中の表スキーマ
= UDBV61
ロック保留中の表名
= EMPLOYEE3
ロック待機開始タイムスタンプ
= 02/01/2001 09:00:00.000000
自動調整結果のロック
= NO
List Of Locks
Lock Object Name = 5
Object Type
= Row <==
Tablespace Name = USERSPACE1
Table Schema
= UDBV61
Table Name
= EMPLOYEE3
Mode
=X
Status
= Granted
Lock Escalation = NO
Lock Object Name = 15
Object Type
= Table
Tablespace Name = USERSPACE1
Table Schema
= UDBV61
Table Name
= EMPLOYEE3
Mode
= IX
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 141-142 )
INSERT行へのロック
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
複数索引とNext Key Locking -INSERT１表に複数索引が存在する場合
全ての索引に対してNext Key Lockが取得される
例１：Insert into tab1 values (4,4)
INSERT行のキーの、次のキーに対してNext Key Lockを取得する
索引
索引
COL1IX
１
３
５
７
COL2IX
１
３
６
８
INSERT
４
４
ｔ
ａｂ１
NW
Next Key
Lock
NW
Next Key
Lock
COL1
１
３
５
７
COL2
６
３
１
８
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：複数索引とNext Key Locking -INSERT複数索引が存在する表に対してINSERTが行われた場合、全ての索引キーの次のHigh keyを持つ行に対して、Next Key Locking
が行われます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 143-144 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
複数索引とNext Key Locking -DELETE１表に複数索引が存在する場合
全ての索引に対してNext Key Lockが取得される
例１：Delete from tab1 where col1 = 4 or col2 = 4
DELETE行のキーの、次のキーに対してNext Key Lockを取得する
索引
COL1IX
１
３
４
５
７
索引
COL2IX
１
３
４
６
８
ｔ
ａｂ１
COL1
１
３
Next Key
５
Lock
７
DELETE行４
Next Key
Lock
COL2
６
３
１
８
４
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：複数索引とNext Key Locking -DELETE複数索引が存在する表に対してDELETEが行われた場合、全ての索引キーの次のHigh keyを持つ行に対して、Next Key Locking
が行われます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 145-146 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Highest keyに対するNext Key Locking
DELETE行/INSERT行のキーがHighest keyであった場合
例１：Delete from tab1 where col1 = ７
DELETEの対象となる表のＥＯＴ(End of Table)またはＢＯＴ(Begin of Table)にNext Key Lockを取得する
索引
COL1IX
１
３
４
５
７
ｔａｂ１
Next Key
Lock
COL1
１
３
５
７
４
End of Table
COL2
６
３
１
８
４
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Highest keyに対するNext Key Locking
DELETE行/INSERT行のキーがHighest keyであった場合には、End of Table （索引が昇順の場合）または Begin of Table （索引
が降順の場合）という仮想のオブジェクトにNext Key Lockを取得します。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 147-148 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
8.ユティリティーにおける排他制御
Export実行時のロック
Import実行時のロック
Load実行時のロック
Runstats実行時のロック
REORGCHK実行時のロック
Online Backup実行時のロック
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・
ページです
第５章( 149-150 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
EXPORT実行時のロック
EXPORTユーテイリティーは、ISOLATION=RRを使用
EXPORTユーティティーのパッケージをバインドし直すことにより、他のISOLATIONに変更可
能
EXPORT Lock-Wait ケース１
１．Appl1が
テーブルにIXロックを取得
レコード5をSELECTし、Uロックを取得
２．Appl2がExportする際に、Appl1のテーブルロックに対してLock-Wait
ISOLATION=RR
１
IXロック
２
Sロック取得要求
レコード1
Appl1
Lock-Wait
SELECT
FOR UPDATE OF
Appl2
EXPORT
レコード5
Uロック
TEST_SOURCE表
ユニーク索引あり
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：EXPORT実行時のロック
EXPORTがISOLATION=RRであることによる、LOCK WAITの発生
Appl1 : SELECT * FROM TEST_SOURCE WHERE ROW_NUMBER=5 FOR UPDATE OF
TEST_DATA
ISOLATION CSの為、表に対してIX-Lock,行に対してU-Lockを取得しようとする
下記表でロックモードが１つだけ表示されている場合は、表レベルのロックモードで、２つの場合は最初は表レベル、２番目は行レベルです
索引走査のロックモード(述部あり）
分離レベル
読み取り専用
RR
RS
CS
UR
Appl2 : EXPORT ..... SELECT
変更を意図
変更
IS/S
IX/S
IS/NS
IX/U
IS/NS
IX/U
IN
IX/U
* FROM TEST_SOURCE
IX/U
IX/U
IX/U
IX/U
ISOLATION RRの為、表に対してS-Lockを取得しようとする
索引走査のロックモード(述部なし）
分離レベル
RR
RS
CS
UR
読み取り専用
S
IS/NS
IS/NS
IN
変更を意図
IX/U
IX/U
IX/U
IX/U
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 151-152 )
変更
X
IX/X
IX/X
IX/X
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：EXPORT実行時のロック
Lock Wait再現シナリオ
１．Appl1: db2 -c- "select * from test_source where row_number=5 for update of test_data' (ISOLATION RR)
２．Appl2: db2 -c- "export to test.ixf of ixf select * from test_source'
ロックスナップショットの取得１ (SNAPSHOT1)：db2 get snapshot for locks on V6DB
SNAPSHOT1の出力結果（抜粋）
Appl1に関する出力部分
Application handle
<==Appl1
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
=2
= *LOCAL.db2v6.000124232048
= 0001
= db2bp
= DB2V6
= UOW Waiting
= 収集されませんでした
= 932
=3
=0
Lock Object Name = 4
Object Type
= Table
Tablespace Name = AZSP1
Table Schema
= DB2V6
Table Name
= TEST_SOURCE
Mode
= IX
<= IX表ロックを保持
Status
= Granted
Lock Escalation = NO
List Of Locks
Lock Object Name = 32776
Object Type
= Row
Tablespace Name = AZSP1
Table Schema
= DB2V6
Table Name
= TEST_SOURCE
Mode
=U
<=更新意図の行にUロックを保持
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：EXPORT実行時のロック
SNAPSHOT1の出力結果（続き）
Appl2に関する出力部分
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
機
ク
ロック待ちのサブセクション
ロック保留中エージェント ID
=3
<=Appl2
= *LOCAL.db2v6.000124232144
= 0001
= db2bp
= DB2V6
= Lock-wait
<=ロック待機中
= 収集されませんでした
= 932
=2
= 9889
=0
=2
<=Appl1に対するロツク待
ロック保留中のアプリケーション ID
= *LOCAL.db2v6.000124232048
ロック・オブジェクト・タイプ
= Tabel
ロック・モード
= Intention Exclusive Lock (IX) <=Appl1が保持するロック
要求ロック・
モード
= Share Lock (S)
<=Appl2が要求するロッ
ロック保留中の表スペース名
ロック保留中の表スキーマ
ロック保留中の表名
ロック待機開始タイムスタンプ
自動調整結果のロック
= AZSP1
= DB2V6
= TEST_SOURCE
= 01/01/1970 09:00:00.000000
= NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 153-154 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：EXPORT実行時のロック
EXPORTユーティリティーのISOLATION Levelの確認
Statement Eventの取得
15) Statement Event ...
Appl Handle: 3
Appl Id: *LOCAL.db2v6.000124232144
Appl Seq number: 0001
Record is the result of a flush: FALSE
------------------------------------------Type
: Dynamic
Operation: Describe
Section : 1
Creator : NULLID
Package : SQLUBC06 <------ EXPORTが使用しているパッケージ名
Cursor : CURSOR1
Text
: select * from test_source
------------------------------------------システムカタログ照会
SELECT PKGNAME, ISOLATION , PKGSCHEMA FROM SYSCAT.PACKAGES
WHERE PKGNAME='SQLUBC06' AND PKGSCHEMA='NULLID'
PKGNAME ISOLATION PKGSCHEMA
-------- --------- ----------------------------------------------------------SQLUBC06 RR
NULLID
1 レコードが選択されました。
ＲＲを使用することが確認できる
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・
ページです
第５章( 155-156 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
EXPORT Lock-Wait回避ケース
EXPORTユーテイリティーのISOLATIONをCSに変更する
Appl2はロック待ちにならず、EXPORTが終了する
１．Appl1が
テーブルにIXロックを取得
レコード5をSELECTし、Uロックを取得
２．Appl2がExportする際に、Appl1のテーブルロックに対してLock-Wait
ISOLATION=CS
１
IXロック
Appl1
２
ISロック
レコード1
SELECT
FOR UPDATE OF
Appl2
EXPORT
Lock-Wait
なし
Sロック
レコード5
Uロック
TEST_SOURCE表
ユニーク索引あり
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：EXPORT Lock-Wait回避ケース
Appl1 : SELECT * FROM TEST_SOURCE WHERE ROW_NUMBER=5 for Update of TEST_DATA
ISOLATION CSの為、表に対してIX-Lock,行に対してU-Lockを取得しようとする
下記表でロックモードが１つだけ表示されている場合は、表レベルのロックモードで、２つの場合は最初は表レベル、２番目は行レベルです
索引走査のロックモード(述部あり）
分離レベル
RR
RS
CS
UR
読み取り専用
IS/S
IS/NS
IS/NS
IN
変更を意図
変更
IX/S
IX/U
IX/U
IX/U
IX/U
IX/U
IX/U
IX/U
Appl2 : EXPORT ..... SELECT * FROM TEST_SOURCE
ISOLATION CSの為、表に対してISS-Lock,行にNS-LOCKを取得しようとする
索引走査のロックモード(述部なし）
分離レベル
RR
RS
CS
UR
読み取り専用
S
IS/NS
IS/NS
IN
変更を意図
IX/U
IX/U
IX/U
IX/U
変更
X
IX/X
IX/X
IX/X
表に対するIX/ISおよび行に対するU/NSは互換性があるのでEXPORTはLock-Waitにはなら
ない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 157-158 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：EXPORT Lock-Wait回避ケース
EXPORTユーティリティーをBINDする方法
１.データベースへの接続
db2 connect
データベース接続情報
データベース・サーバー
= DB2/6000 6.1.0
SQL 権限 ID = DB2V6
ローカル・データベース別名 = V6DB
２．ＢＩ
ＮＤコマンドでＩ
ＳＯＬＡＴＩ
ＯＮをＣＳで指定
db2uexpm.bnd はＥＸＰＯＲＴユーティリティーのバインド・ファイル名
db2 bind $HOME/sqllib/bnd/db2uexpm.bnd isolation cs
LINE MESSAGES FOR db2uexpm.bnd
------ -----------------------------------------------SQL0061W バインド・プログラムが処理中です。
SQL0091N バインドが、エラー "0" と警告 "0" で終了しました。
３．ISOLATIONの確認するために、システムカタログを照会する
db2 "SELECT PKGNAME, ISOLATION , PKGSCHEMA FROM SYSCAT.PACKAGES
WHERE PKGNAME='SQLUBC06' AND PKGSCHEMA='NULLID' "
PKGNAME ISOLATION PKGSCHEMA
-------- --------- --------------------------------SQLUBC06 CS
NULLID
CSを使用することが確認できる
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・
ページです
第５章( 159-160 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
IMPORT実行時のロック
排他モードの表ロックを取得
パッケージの中で、LOCK TABLE xx IN EXCLUSIVE MODEステートメントが発行されている
ISOLATION＝UR(INロック)以外は、IMPORT先の表にアクセス不可能
１．Appl1が
テーブルにISロックを取得
レコード3をSELECTし、NSロックを取得
２．Appl2がIMPORTする際に、Appl1のテーブルロックに対してLock-Wait
ISOLATION=RS
ISロック
ISOLATION=RR
１
２
レコード1
Appl1
Xロック取得要求
Lock-Wait
Appl2
IMPORT
レコード3
SELECT * FROM
TEST_SOURCE
WHERE
ROW_NUMBER=3
NSロック
レコード5
TEST_SOURCE表
ユニーク索引あり
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：IMPORT実行時のロック
Lock Wait再現シナリオ
１．Appl1: db2 -c- "select * from test_source where row_number=3' (ISOLATION RS)
２．Appl2: db2 -c- "import from test.ixf of ixf insert into test_source'
ロックスナップショットの取得１ (SNAPSHOT1)：db2 get snapshot for locks on V6DB
SNAPSHOT1の出力結果（抜粋）
Appl1に関する出力部分
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
=2
<= Appl1
= *LOCAL.db2v6.000125034143
= 0001
= db2bp
= DB2V6
= UOW Waiting
= 収集されませんでした
= 932
=3
=0
List Of Locks
Lock Object Name = 32774
Object Type
= Row
Tablespace Name = AZSP1
Table Schema
= DB2V6
Table Name
= TEST_SOURCE
Mode
= NS
Status
= Granted
Lock Escalation = NO
<= 参照した行にNS-Lockを保持
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 161-162 )
Lock Object Name = 4
Object Type
= Table
Tablespace Name = AZSP1
Table Schema
= DB2V6
Table Name
= TEST_SOURCE
Mode
= IS
<==IS表ロックを保持
Status
= Granted
Lock Escalation = NO
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：IMPORT実行時のロック
SNAPSHOT1の出力結果（続き）
Appl2に関する出力部分
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
<続き>
=3
<=Appl2
= *LOCAL.db2v6.000125034241
= 0001
= db2bp
= DB2V6
= Lock-wait
<=ロック待機中
= 収集されませんでした
= 932
=8
= 4942
ロック待ちのサブセクション
=0
ロック保留中エージェント ID
=2
<= Appl1に対するロック待機
ロック保留中のアプリケーション ID
= *LOCAL.db2v6.000125034143
ロック・オブジェクト・タイプ
= Table
ロック・モード
= Intention Share Lock (IS)
<=Appl1が保持
要求ロック・
モード
= Exclusive Lock (X)
<=Appl2が要求
ロック保留中の表スペース名
= AZSP1
ロック保留中の表スキーマ
= DB2V6
ロック保留中の表名
= TEST_SOURCE
ロック待機開始タイムスタンプ
= 01/01/1970 09:00:00.000000
自動調整結果のロック
= NO
List Of Locks
Lock Object Name = 3850
Object Type
= Row
Tablespace Name
= SYSCATSPACE
Table Schema
= SYSIBM
Table Name
= SYSTABLES
Mode
= NS
Status
= Granted
Lock Escalation
= NO
Lock Object Name = 2
Object Type
= Table
Tablespace Name
= SYSCATSPACE
Table Schema
= SYSIBM
Table Name
= SYSTABLES
Mode
= IS
Status
= Granted
Lock Escalation
= NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：IMPORT実行時のロック
IMPORTユーティリティーのLock statementの確認
Statement Eventの取得
Appl Handle: 2
Appl Id: *LOCAL.db2v6.000125033526
Appl Seq number: 0001
Record is the result of a flush: FALSE
------------------------------------------Type
: Dynamic
Operation: Execute Immediate
Section : 2
Creator : NULLID
Package : SQLUKC06
Cursor :
Text
: LOCK TABLE test_source IN EXCLUSIVE MODE <== 排他ロックを表に取得している
------------------------------------------システムカタログ照会
SELECT PKGNAME, ISOLATION , PKGSCHEMA FROM SYSCAT.PACKAGES
WHERE PKGNAME='SQLUKC06' AND PKGSCHEMA='NULLID'
PKGNAME ISOLATION PKGSCHEMA
-------- --------- ----------------------------------------------------------SQLUKC06 RR
NULLID
ＲＲを使用しているが確認できる
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 163-164 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
LOAD実行時のロック
排他モードのQUIESCEをかけている
表スペースと、表スペース内の表すべてに対してZ-LOCKを取得する
LOAD先の表と同じ表スペースにある表が参照されLOCKを保持している場合、LOADはLock-Waitになる
Zロック
TABLE SPACE
Zロック
TABLE
ROW
INDEX
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・
ページです
第５章( 165-166 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
LOADのLock-Waitケース１：LOAD実行時
LOAD先と同じ表スペースにある表にロックがあると、LOADはロック待ちに
なってしまう
１．Appl1がTEST_SOURCE2表をISOLATION RSでSELECT
２．Appl2が同じ表スペースにあるTEST_SOURCEへLOAD INSERT =>Lock-Wait
３．Appl3がTEST_SOURCEをダーティーREAD => Lock-Wait
ISOLATION=RS
表ISロック
表スペース Zロック取得
１
２
行NSロック
Appl1
SELECT
TEST_SOURCE2表
Appl2
表Zロック取得要求
LOAD .... INSERT INTO TEST_SOURCE
Lock-Wait
表 Zロック取得
TEST_SOURCE表
表スペース: AZSP1
表INロック取得要
求 Lock-Wait
3
ISOLATION=UR
Appl3
SELECT
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：LOADのLock-Waitケース１：LOAD実行時
Lock Wait再現シナリオ
１．Appl1: db2 -c- "select * from test_source2 where row_number=1' (ISOLATION RS)
２．Appl2: db2 -c- "Load from test.ixf of ixf insert into test_source'
３．Appl3. db2 -c- "select * from test_source" (ISOLATION UR)
ロックスナップショットの取得１ (SNAPSHOT1)：db2 get snapshot for locks on V6DB
SNAPSHOT1の出力結果（抜粋）
Appl1に関する出力部分
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
=2
<=Appl1
= *LOCAL.db2v6.000125043631
= 0001
= db2bp
= DB2V6
= UOW Waiting
= 収集されませんでした
= 932
=3
=0
Lock Object Name = 5
Object Type
= Table
Tablespace Name = AZSP1
Table Schema
= DB2V6
Table Name
= TEST_SOURCE2
Mode
= IS
<=表にIS-Lock保持
Status
= Granted
Lock Escalation = NO
List Of Locks
Lock Object Name = 65540
Object Type
= Row
Tablespace Name = AZSP1
Table Schema
= DB2V6
Table Name
= TEST_SOURCE2
Mode
= NS
<=SELECT行に対しNS-Lock保
持
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 167-168 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：LOADのLock-Waitケース１：LOAD実行時
SNAPSHOT1の出力結果（続き）
Appl2に関する出力部分
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
=3
<=Appl2
= *LOCAL.db2v6.000125043708
= 0001
= db2bp
= DB2V6
= Lock-wait
<=ロック待機中
= 収集されませんでした
= 932
=5
= 154875
ロック待ちのサブセクション
=0
ロック保留中エージェント ID
=2
<= Appl1に対するロック待機
ロック保留中のアプリケーション ID
= *LOCAL.db2v6.000125043631
ロック・オブジェクト・タイプ
= Table
<= 表で競合発生
ロック・モード
= Intention Share Lock (IS)
<= Appl1が保持
要求ロック・
モード
= Super Exclusive Lock (Z) <= Appl2が要求
ロック保留中の表スペース名
= AZSP1
ロック保留中の表スキーマ
= DB2V6
ロック保留中の表名
= TEST_SOURCE2
ロック待機開始タイムスタンプ
= 01/01/1970 09:00:00.000000
自動調整結果のロック
= NO
List Of Locks
Lock Object Name = 4
Object Type
= Table
Tablespace Name = AZSP1
Table Schema
=
Table Name
=
Mode
=Z
<= Z-Lockを保持
Status
= Granted
Lock Escalation = NO
Lock Object Name = 3
Object Type
= Tablespace
Tablespace Name = AZSP1
Table Schema
=
Table Name
=
Mode
=Z
<= Z-Lockを保持
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：LOADのLock-Waitケース１：LOAD実行時
SNAPSHOT1の出力結果（続き）
Appl ３に関する出力部分
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
=4
<= Appl 3
= *LOCAL.db2v6.000125043931
= 0001
= db2bp
= DB2V6
= Lock-wait
<= ロック待機
= 収集されませんでした
= 932
=6
= 12148
ロック待ちのサブセクション
=0
ロック保留中エージェント ID
= 3 <=Appl 2に対するロック待ち
ロック保留中のアプリケーション ID
= *LOCAL.db2v6.000125043708
ロック・オブジェクト・タイプ
= Table
ロック・モード
= Super Exclusive Lock (Z) <= Appl2が保持
要求ロック・モード
= Intent None Lock (IN)
<= Appl３が要求
ロック保留中の表スペース名
= AZSP1
ロック保留中の表スキーマ
=
ロック保留中の表名
=
ロック待機開始タイムスタンプ
= 01/01/1970 09:00:00.000000
自動調整結果のロック
= NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 169-170 )
List Of Locks
Lock Object Name = 3850
Object Type
= Row
Tablespace Name = SYSCATSPACE
Table Schema
= SYSIBM
Table Name
= SYSTABLES
Mode
= NS
Status
= Granted
Lock Escalation = NO
Lock Object Name = 2
Object Type
= Table
Tablespace Name = SYSCATSPACE
Table Schema
= SYSIBM
Table Name
= SYSTABLES
Mode
= IS
Status
= Granted
Lock Escalation = NO
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
LOADのLock-Waitケース２：LOAD異常終了時
LOAD異常終了時のファントムQuiesceの解消方法
ファントムQUIESCE(Phantom Quiesce)とは、所有者のいないQUIESCEのこと
QUIESCE RESETを実行することにより解消
(例）
１．Appl1がLOAD 実行中に異常終了("Phantom Quiesce"の発生）
２．Appl2が同じ表スペースにあるTEST_SOURCEをSELECTすると、SQLCODE -290となる (Lock Waitではない）
３．Appl3がQUIESCE RESETを発行 ("Phantom Quiesce"の解消）
表Zロック
表Zロック取得
SQL0290N Table space access is not allowed.
１
２
Appl2
Appl1
LOAD .... INSERT
INTO TEST_SOURCE
SELECT
TEST_SOURCE表
QUIESCE
RESET
表スペース
Zロック取得
３
Appl３
表スペース: AZSP1
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：LOADのLock-Waitケース２：LOAD異常終了時
-290再現シナリオ
１．Appl1: db2 -c- "Load from test.ixf of ixf insert into test_source copy yes to /dbland1 HOLD Quiesce"
２．Appl2: db2 -c- "select * from test_source"
SQLCODE -290
ロックスナップショットの取得１ (SNAPSHOT1)：db2 get snapshot for locks on V6DB
Lock競合は発生していない
Quiesce コマンドが発行されるとObjectに対するZ-Lockが取得され、すべて取得されるとTablespaceの状況を変えＬｏｃｋを
解放する
List Tablespaces show detaol出力結果 AZSP1に関する出力部分
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
静止: EXCLUSIVE
合計ページ数
使用可能ページ数
使用したページ
空きページ
最高水準点 (ページ) ページ・
サイズ (バイト)
エクステント・
サイズ (バイト)
プリフェッチ・サイズ (バイト)
コンテナー数
最小回復時間静止状態の数
静止状態 1:
表スペース ID
オブジェクト ID
=3
= AZSP1
= データベース管理スペース
= 任意のデータ
= 0x0004
<=== Quiesce Exclusive
= 1000
= 992
=0
=0
=0
= 4096
= 32
= 32
=1
= 2000-01-25-04.33.05.000000
=1
=3
=4
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 171-172 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：LOADのLock-Waitケース２：LOAD異常終了時
３．Appl3: db2 "quiesce tablespace for table test_source reset"
"Pantom Quiesceの解消"
４．Appl2: db2 -c- "select * from test_source"
SQLCODE 0
List Tablespaces show detaol出力結果 AZSP1に関する出力部分
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
静止: EXCLUSIVE
合計ページ数
使用可能ページ数
使用したページ
空きページ
最高水準点 (ページ) ページ・サイズ (バイト)
エクステント・サイズ (バイト)
プリフェッチ・サイズ (バイト)
コンテナー数
最小回復時間静止状態の数
静止状態 1:
表スペース ID
オブジェクト ID
=3
= AZSP1
= データベース管理スペース
= 任意のデータ
= 0x0000
<=== Normal
= 1000
= 992
=0
=0
=0
= 4096
= 32
= 32
=1
= 2000-01-25-04.33.05.000000
=1
=3
=4
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・
ページです
第５章( 173-174 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Runstats実行時のロック
RUNSTATS の構文
Schema.Table-Name
ALIAS
RUNSTATS ON TABLE
WITH DISTRIBUTION
AND
DETAILED
AND
FOR
SHRLEVEL
INDEXES ALL
index-name
INDEXES ALL
index-name
DETAILED
CHANGE
REFERENCE
２つのSHRLEVELオプション
CHANGE(省略時)の場合：
Runstats実行中でも該当表を変更可能
1. SYSTABLESに対してIS/NS-Lock
2. 該当表に対してIN-Lock(UR)でアクセス
3. カタログ更新(IX,X-Lock)
REFERENCEの場合：Runstats実行中,該当表はRead-Only
1. SYSTABLESに対してIS/NS-Lock
2. 該当表に対してS-Lock(RR)でアクセス
3. カタログ更新(IX,X-Lock)
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Runstats実行時のロック
RUNSTATS SHRLEVEL CHANGEの場合のロック取得
SHARELEVEL CHANGEは該当表をダーティーREADしているのでカタログの統計情報が実際と異なる場合もありえる
TEST_SOURCE表
１
Appl1
INSERT
4
Rollback
レコード1
レコード2
レコード3
レコード4
レコード5
挿入中レコード6
SYSTABLES表
CARD
6
２
Appl2
RUNSTATS
SHRLEVEL
CHANGE
3
Appl2
DB2CLP C:¥SQLLIB¥bin>db2 select tabname,card from syscat.tables where tabname='TEST_SOURCE'
TABNAME
CARD
--------------------------------------------TEST_SOURCE
6
1 レコードが選択されました。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 175-176 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Reorgchk実行時のロック
STATISTICSオプション
REORGCHKコマンドからRUNSTATSを呼び出す(Runstats実行中でも該当表を変更可能)
UPDATE（省略時）
先にRUNSTATSを実行してカタログ統計情報を更新した後、REORGCHKが実行される
RUNSTATSはTABLE and INDEX ALL options（SYSCAT.INDEXESの情報も更新される)
SHRLEVEL CHANGEが使用される
a. SYSTABLESに対してIS/NS-Lock
b. 該当表に対してIN-Lock(UR)でアクセス
c. カタログ更新(IX,X-Lock)
CURRENT
現在の統計情報より、REORGCHKを行う
ON TABLEオプション
USER
現在の認証IDを持つ表に対してREORGCHKを行う
SYSTEM
システム表（SYSIBM.xxx）に対してREORGCHKを行う
ALL
すべてのユーザー表およびシステム表（SYSIBM.xxx）に対してREORGCHKを行う
table-name
REORGCHKの対象の表を指定する
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Reorgchk実行時のロック
REORGCHKの構文
REORGCHK
UPDATE
CURRENT
STATISTICS
ON TABLE
table-name
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 177-178 )
USER
SYSTEM
ALL
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：Reorgchk実行時のロック
REORGCHKにより、表と索引に対して検査を行いREORG（再編成）の必要性を判断する。
REORGCHKはデフォルトではRUNSTATSを伴う処理を行う。
REORGCHKを行い、なおかつ統計情報を更新したくない場合
REORGの必要性だけを調べたい
例えば以下のような手順により実現できる
db2 +c reorgchk on table xxx
db2 rollback
表統計レポートの例:
F1: 100*OVERFLOW/CARD < 5
F2: 100*TSIZE / ((FPAGES-1) * 4020) > 70
F3: 100*NPAGES/FPAGES > 80
CREATOR NAME
CARD
OV
NP
FP
TSIZE F1 F2 F3 REORG
------------------------------------------------------------------------------SYSIBM SYSEVENTS
- - - - --SYSIBM SYSFUNCPARMS
254
0
6
6
21590 0 100 100 --SYSIBM
SYSIBM
SYSIBM
SYSIBM
SYSIBM
SYSFUNCTIONS
SYSINDEXAUTH
SYSINDEXES
SYSKEYCOLUSE
SYSPLAN
104
2
57
4
22
0
0
17
0
0
8
1
3
1
2
8
1
5
1
2
728 0 2 100 -*112 0 - 100 --9063 29 56 60 ***
268 0 - 100 --154 0 3 100 -*-
SYSIBM
SYSPLANAUTH
41
0
1
1
1804
*"のついた項目を持つ表がREORGの候補である。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・
ページです
第５章( 179-180 )
0
- 100 ---
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Online Backup時のロック
BACKUPの構文
BACKUP
database-alias
DATABASE
DB
,
TABLESPACE
username
password
USING
USER
ONLINE
table space name
USE ADSM
,
TO
LOAD
OPEN
num-sessions
target-area
library-name
OPEN
WITH
SESSIONS
num-buffers
BUFFERS
num-sessions
BUFFER
SESSIONS
buffer-size
WITHOUT PROMPTING
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Online Backup時のロック
Backupの種類
DataBase
データベース全体のバックアップを取得します。
Tablespace
データベース中の表スペースを選択して、バックアップを取得します。
ログ保存式ロギング(Archived Logging)でなければなりません。
複数の表スペースにまたがる表がある時、それらのバックアップをまとめて取得しなければなりません。
例：データと索引を別表スペースに置いている時
一時表スペースを含めると、エラーとなります。
Offline backup & Online Backup
Offline Backup
排他モードでバックアップを取得します。
バックアップ取得中、他のアプリケーションはこのデータベースに接続する事ができません。
Online Backup
通常の使用状態の中で、バックアップを取得します。
ログ保存式ロギング(Archived Logging)でなければなりません。
バックアップ取得開始時間から終了時間までのログは、ロールフォワード必須です
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 181-182 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Online Backup時のロック
Online BACKUP中には、ＤＢオブジェクトを変更することが可能
2
Backup Database
IN-Lock
(Table単位でS-Lock)
IN-Lock
IN-Lock
Table Space
Table Space
Table Space
'SYSCATSPACE'
'USERSPACE1'
'AZSP1'
Table
Index
Index
Table
1
Table
Table
Table
更新処理可
能
更新処理可
能
3
Appl2
Appl1
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Online Backup時のロック
Online Backup時のロックの取得(Get Snapshot for locks on V6DB)
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 14
= *LOCAL.db2v6.000301060818
= 0001
= db2bp
= DB2V6
= Performing a Backup
= 収集されませんでした
= 932
= 16
=0
Lock Object Name = 0
Object Type
= Tablespace
Tablespace Name = SYSCATSPACE
Table Schema
=
Table Name
=
Mode
= IN
Status
= Granted
Lock Escalation = NO
Lock Object Name = 3
Object Type
= Tablespace
Tablespace Name = AZSP1
Table Schema
=
Table Name
=
Mode
= IN
Status
= Granted
Lock Escalation = NO
Lock Object Name = 2
Object Type
= Tablespace
Tablespace Name = USERSPACE1
Table Schema
=
Table Name
=
Mode
= IN
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 183-184 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Online Backup時にロック待ちになるケース
Online BACKUP前に、ＤＢオブジェクトを変更した場合
２
Backup Database
IN-Lock
(Table単位でS-Lock)
IN-Lock
IN-Lock
Table Space
Table Space
Table Space
'SYSCATSPACE'
'USERSPACE1'
'AZSP1'
Table
Index
Index
Table
Table
Table
Table
Drop Table
Drop
Tablespace
Rebind
Create View
等
１
Appl2
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Online Backup時のロック
Drop Tablespace実行（未コミット）後のOnline BackupのLock-wait
DROP DBSPACE時に取得済みのZ-LockはIN-Lockとの互換性はない
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
=5
= *LOCAL.db2v6.000301053207
= 0001
= db2bp
= DB2V6
= Lock-wait
= 収集されませんでした
= 932
=2
= 13777
ロック待ちのサブセクション
=0
ロック保留中エージェント ID
=2
ロック保留中のアプリケーション ID
= *LOCAL.db2v6.000301051215
ロック・オブジェクト・タイプ
= Tablespace
ロック・モード
= Super Exclusive Lock (Z)
要求ロック・モード
= Intent None Lock (IN)
ロック保留中の表スペース名
= AZSP1
ロック保留中の表スキーマ
=
ロック保留中の表名
=
ロック待機開始タイムスタンプ
= 01/01/1970 09:00:00.000000
自動調整結果のロック
= NO
List Of Locks
Lock Object Name = 2
Object Type
= Tablespace
Tablespace Name = USERSPACE1
Table Schema
=
Table Name
=
Mode
= IN
Status
= Granted
Lock Escalation = NO
Lock Object Name = 0
Object Type
= Tablespace
Tablespace Name = SYSCATSPACE
Table Schema
=
Table Name
=
Mode
= IN
Status
= Granted
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 185-186 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：Online Backup時のロック
Drop Table実行（未コミット）後のOnline BackupのLock-wait(実際にはSTATUS=Lock-Waitとはならない)
Backup実行中、必要時にカタログ情報をRRでREADしようとしている(初期：IN-Lock -->情報読み込み時:S-Lock)
SYSTABLESやSYSPLAN表に既にIX-Lockを取得されていると、STATUS=ConvertingでBackupがWaitしてしまう
Drop table
----> SYSTABLESにIX-Lock
Drop Package ----> SYSPLANにIX-Lock
（Drop Table時）
Application handle
Application ID
*LOCAL.db2v6.000301060818
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
（
Drop package時）
= 14
=
= 0001
= db2bp
= DB2V6
= Performing a Backup
= 収集されませんでした
= 932
= 16
=0
List Of Locks
Lock Object Name = 7
Object Type
= Table
Tablespace Name = SYSCATSPACE
Table Schema
= SYSIBM
Table Name
= SYSPLAN
Mode
=S
Status
= Converting ＜＝＝ロック・モード変換中
Lock Escalation = NO
Application handle
Application ID
*LOCAL.db2v6.000301060818
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 14
=
= 0001
= db2bp
= DB2V6
= Performing a Backup
= 収集されませんでした
= 932
= 16
=0
List Of Locks
Lock Object Name = 7
Object Type
= Table
Tablespace Name = SYSCATSPACE
Table Schema
= SYSIBM
Table Name
= SYSPLAN
Mode
=S
Status
= Converting ＜＝＝ロック・モード変換中
Lock Escalation = NO
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・
ページです
第５章( 187-188 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
９．ロックを制御する指定
SQLステートメント
DECLARE CURSORのWITH HOLDオプション
CLOSEカーソルのWITH RELEASEオプション
SELECTのFETCH ｎ ROWS ONLY
レジストリー変数
DB2LOCK_TO_RB
DB2_RR_TO_RS
DB2_NO_PKG_LOCK
ODBC,CLI,CLPの設定
AUTOCOMMIT
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 189-190 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
DECLARE CURSORのWITH HOLDオプション
COMMITを越えて、カーソル位置およびカーソル位置のロックを保持
ROLLBACKが実行された場合
カーソルはCLOSEされる
ロックは解放される
LOB ロケーターは解放される
使用方法
埋め込みSQL
DECLARE CURSOR ｘｘｘｘ WITH HOLD
CLI SQLSetStmtAttr() のSQL_ATTR_CURSOR_HOLD属性
SQL＿CURSOR_HOLD_ON ：カーソル保留（省略時値）
SQL＿CURSOR_HOLD_OFF ：カーソル保留なし
ODBCまたはCLI
db2cli.iniファイルのCURSORHOLDキーワード [ 1 （カーソル保留：省略時値）| 0 （カーソル保留なし）]
用途
COMMITでの作業単位の完了により、ロックおよび資源の解放を行うと共に、カーソルを
OPENしたままにしておきたい場合
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：DECLARE CURSORのWITH HOLDオプション
カーソルの宣言時(DECLARE CURSORステートメント）に、WITH HOLDオプションをつけてカーソルを定義することにより、COMMIT
ポイントを越えてカーソル位置を保持することが可能です。COMMITにより、行に取得されたロックは解放されますが、現在のカーソ
ル行についてのロックは保持されます。これにより、COMMIT後にFETCHを行うと、次の行からFETCH処理を継続することができま
す。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 191-192 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
CLOSEカーソルのWITH RELEASEオプション
カーソルのCLOSE時に、Read Lockを全て解放する
RR,RSのアプリケーションにのみ有効
CS,URのアプリケーションについては無効
Read Lock： U,IS,U表ロックと S,NS,U行ロック
使用方法
埋め込みSQL
CLOSE カーソル名 WITH RELEASE
CLI SQLSetConnectAttr() のSQL_ATTR_CLOSE_BEHAVIOR 属性
SQL_CC_NO_RELEASE ：Read Lockの解放をしない（省略時値）
SQL_CC_RELEASE ：Read Lockの解放をする
用途
RR,RSのアプリケーションでの、同時稼動性を向上したい場合
ロック保持によるCPU負荷とメモリー消費を軽減したい場合
考慮点
反復不可能読み取りおよび幻像読み取りが発生する可能性がある
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：CLOSEカーソルのWITH RELEASEオプション
RRまたはRSのアプリケーションで、CLOSEステートメントでカーソルをCLOSEする際にWITH RELEASEオプションをつけることによ
り、該当するカーソルの照会処理により保持されているREADロックを全て解放します。通常は、CLOSEステートメントでは、READ
ロックは解放されず、COMMITの実行により解放されます。
作業単位を終了させずに、READロックを解放することが可能です。
ただし、反復不可能読み取りおよび幻像読み取りが発生する可能性があります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 193-194 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
SELECTのFETCH FIRST ｎ ROWS ONLY
照会結果の先頭から何行のみをアプリケーションに返すかを設定
検索条件に合致する行数にかかわらず、指定された行数のみがアプリケーションに返される
指定行数を越えてFETCHすることはできない
SQLCODE +100 （End Of File) が戻される
RSのアプリケーションでは、指定行数分の行にのみロックを取得する
使用方法
埋め込みSQL
SELECT ...... FROM 表名 FETCH FIRST n ROWS ONLY
(nは行数を指定）
CLI
SQLSetStmtAttr() のSQL_ATTR_MAX_ROWS属性で、行数を指定する。省略時値はゼロ。
DB2 V6からはこの値の設定により、ステートメントにFETCH FIRST n ROWS ONLYと、
OPTIMIZE FOR n ROWSが加えられる
用途
検索条件に合致した上位何件かのみが必要である場合
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：SELECTのFETCH FIRST ｎ ROWS ONLY
条件に合致する最初のｎ行のみを照会することができます。ORDER BYと併せて使用することにより、上位ｎ番目までの結果をクラ
イアント・アプリケーションに戻すことが可能です。
ｎに指定された行数のみをクライアントに転送し、ｎを越える行数をFETCHすることはできません。もしｎを越える行数をFETCH
した場合には、+100 （End Of Fileの意味）のSQLCODEがアプリケーションに戻されます。
これにより、クライアントとサーバー間に転送されるデータ量を絞り込むことができ、さらにクライアント・アプリケーションで最初の何
行かを選択するしくみを作成する必要はありません。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 195-196 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
DB2LOCK_TO_RBレジストリー変数
ロック・
タイムアウト時に、ロールバックする単位を設定可能
null [省略時値]：作業単位をロールバック
STATEMENT ：タイムアウトになったSQLステートメントのみをロールバック
DB2LOCK_TO_RB＝STATEMENTの場合
ロールバック時には、SQLCODE -９１３ RC ８０が戻される
ロールバックされたステートメントよりも先に実行された、同一作業単位内のステートメントは、
仕掛かり中のままになる
select col2 from table1 where col1=100
update table1 set col3=300 where col1=200
update table1 set col3=400 where col1=300
X取得要求
col1
NS 100
X 200
300
ロックタイムアウト発生
col2
D00
A00
B00
col3
700
600
500
このステートメントのみロールバック
用途複数のSQLをセットで実行する必要がない場合には、ステートメントごとの実行管理が可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：DB2LOCK_TO_RBレジストリー変数
DB2LOCK_TO_RBを Statement に設定することにより、ロック・タイムアウトによるロールバックの単位をステートメント単位に設定
することが可能です。
ロック・タイムアウトの原因になったステートメントはロールバックされますが、それ以前のステートメントについては、ロールバックさ
れません。
設定方法
db2set DB2LOCK_TO_RB=statement
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 197-198 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
DB2_RR_TO_RS レジストリー変数
Ｎext key lockingの使用／不使用の設定をする
設定後にdb2startを行うことが必要
ＯＮ：不使用
ＯＦＦ [省略時値] ：使用
DB2_RR_TO_RS＝ＯＮの場合
RRでバインドされているパッケージの分離レベル(Isolation Level)は、RSになる
RR（反復可能読み取り）は保証されない
システム・
カタログ表に対するアクセスには作用しない
用途
バインドし直すことなく、RRによるロック競合を避けることが可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：DB2_RR_TO_RS レジストリー変数
ＤＢ２がロッキングおよび索引処理を行うにあたって、next key lockingが必要になりました。ＤＢ２は、特別な索引ロックを維持管理
していません。これは、全てのロックは、表あるいは行に対して行われるということになります。（表スペースへのロックは、この説明
からは省きます。）表や、行にロックが取られると、関連する索引または索引行のエントリー（キー値あるいは、ＲＩ
Ｄ）は、同じロックを
継承します。結果として、特定の索引行エントリーをロックするためには、関連した表の行をロックしなければなりません。これは、全
てのデータを、直接索引から読み込む場合でも、同じことです。
索引行が削除された場合、削除を行ったトランザクションがコミットされる前であっても、他のトランザクションからは、削除されたこと
がわかりません。一方、基本表を表スキャンする他のトランザクションからは、削除表に対するX Lockがある為、行が削除されたと
いう事実がわかります。結果として、next key lockingなしでは、表スキャンは削除行でブロックされますが、索引スキャンをブロック
するものはありません。なぜなら索引エントリーが削除されたことがわからないからです。従って、RRの要求が満たされないことにな
ります
next key lockingを使用不可能にするメカニズムがあります。しかし、使用不可能にした場合、反復可能読取り（RR)分離レベルが使
用できなくなります。
next key lockingを使用不可能にするには、データベース・インスタンスに対して、DB2_RR_TO_RSレジストリー変数をＯＮに設定しま
す。
DB2_RR_TO_RSレジストリー変数をＯＮに設定し、インスタンスを再始動すると、DB2はユーザー・データに対するnext key lockingを
とらなくなります。
これにより、RRはサポートされなくなり、既にRRでバインドされていた全てのパッケージは、RSにグレード・ダウンされます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 199-200 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
DB2_NO_PKG_LOCK レジストリー変数
パッケージへの内部ロック取得の有無を設定する
ON ：内部ロックを取得しない
OFF [省略時値] ：内部ロックを取得する
DB2_NO_PKG_LOCK=ON Global SQL Cacheにキャッシュされている、実行中のパッケージのエントリーを保護するため
の、パッケージに対する内部ロックを取らない
パッケージの変更（BIND,REBIND）を行った場合には、SQL1803が戻され、変更不可能
用途
パッケージの変更がない本番稼動システムに使用することによる、パフォーマンスの向上
コストをが高い、パッケージへのロック要求を削減
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：DB2_NO_PKG_LOCK レジストリー変数
このレジストリー変数はV5.2から使用可能です。 Global SQL Cache について処理が行われている場合に、、既にキャッシュされて
いるパッケージのエントリーを保護するために、パッケージにロックを取得することをしません。パッケージ・ロックは内部的なシステ
ム・ロックです。パフォーマンスを向上させるために、"パッケージ・ロックを取らない"モードを選択することができます。このモードで
は、特定のデータベース処理を行うことができなくなります。以下の処理についてです。
パッケージを無効（INVALID)にする処理
パッケージを使用不可能（INOPERRATIVE)にする処理
パッケージを直接変更するような処理
この変数についての変更を有効にするためには、データベース・マネージャーは停止し、再始動する必要があります。
省略時値は OFF.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 201-202 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：DB2_NO_PKG_LOCK レジストリー変数
テストのシナリオ
１．ユーザーＡ： db2 -c- ”lock table employee on exclusive mode” (-c- : AUTOCOMMIT=OFF)
２．ユーザーＢ：ｅｍｐ
ｌ
ｏ
ｙ
ｅ
ｅ
表を照会するプログラムを実行する
３．ユーザーＣ：ユーザーＢが実行中のプログラムをＢＩ
ＮＤする
４．ユーザーＤ： db2 get snapshot for locks on sampledb
DB2_NO_PKG_LOCK=OFF(省略時)の場合
１．ユーザーＡ： db2 -c- ”lock table employee on exclusive mode” (-c- : AUTOCOMMIT=OFF)
SQLCODE 0で処理が完了
２．ユーザーＢ：ｅｍｐ
ｌ
ｏ
ｙ
ｅ
ｅ
表を照会するプログラムを実行する
ユーザーＡが、ｍｐｌｏｙｅｅ表にＸロックを取得しているため、ＬＯＣＫ−ＷＡＩ
Ｔ
になる
３．ユーザーＣ：ユーザーＢが実行中のプログラムをＢＩ
ＮＤする
ユーザーＢが、パッケージに内部ロックを取得しているため、ＬＯＣＫ−ＷＡＩ
Ｔ
になる
DB2_NO_PKG_LOCK=OＮの場合
１．ユーザーＡ： db2 -c- ”lock table employee on exclusive mode” (-c- : AUTOCOMMIT=OFF)
SQLCODE 0で処理が完了
２．ユーザーＢ：ｅｍｐ
ｌ
ｏ
ｙ
ｅ
ｅ
表を照会するプログラムを実行する
ユーザーＡが、ｍｐｌｏｙｅｅ表にＸロックを取得しているため、ＬＯＣＫ−ＷＡＩ
Ｔ
になる
３．ユーザーＣ：ユーザーＢが実行中のプログラムをＢＩ
ＮＤする
ユーザーＢが、パッケージに内部ロックを取得していないが、DB2_NO_PKG_LOCK=OＮの場合には、パッケージ
に変更を与える処理は許可されないため、ＳＱＬ１８０３が戻される。
SQL1803N 要求された操作は、 "パッケージ・ロックなし" モードでは実行されません。影響を受けるパッケージは
"UDBV61.STATIC" です。 SQLSTATE=57056
SQL0082C エラーが発生したため、処理は終了しました。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：DB2_NO_PKG_LOCK レジストリー変数
DB2_NO_PKG_LOCK=OFF(省略時)の場合の、SNAPSHOTの出力
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 127 ＜＝LOCKステートメントを実行したユーザー
= *LOCAL.udbv61.990623021604
= 0001
= db2bp
= UDBV61
= UOW Waiting
= 収集されませんでした
= 943
=5
= 収集されませんでした
List Of Locks
Lock Object Name = 6
Object Type
= Table
Tablespace Name = USERSPACE1
Table Schema
= UDBV61
Table Name
= EMPLOYEE
Mode
=X
Status
= Granted
Lock Escalation = NO
（途中省略）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 203-204 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：DB2_NO_PKG_LOCK レジストリー変数
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 130 ＜＝プログラムを実行したユーザー
= *LOCAL.udbv61.990623022415
= 0001
= static
= UDBV61
= Lock-wait
= 収集されませんでした
= 943
=1
= 収集されませんでした
List Of Locks
Lock Object Name = 0
Object Type
= Internal P Lock ＜＝パッケージに対する内部ロック
Tablespace Name =
Table Schema
=
Table Name
=
Mode
=S
Status
= Granted
Lock Escalation = NO
Application handle
Application ID
Sequence number
Application name
Authorization ID
Application status
Status change time
Application code page
Locks held
Total wait time (ms)
= 132 ＜＝BINDを実行したユーザー
= *LOCAL.udbv61.990623022517
= 0001
= db2bp
= UDBV61
= Lock-wait
= 収集されませんでした
= 943
=0
= 収集されませんでした
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 205-206 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
AUTOCOMMIT
各SQL単位に自動的にCOMMITを実行するかを設定する
使用方法
db2cli.ini
AUTOCOMMIT ( 0 ：OFF
1：省略時値で、ON）
CLI
SQLSetConnectAttr() のSQL_ATTR_AUTOCOMMIT
SQL_AUTOCOMMIT_ON ：（省略時値） SQLステートメント実行ごとに自動的にCOMMITが実行される
照会処理の場合、カーソルのCLOSE直後にCOMMITが実行される
SQL_AUTOCOMMIT_OFF ：SQLTransact()で明示的にCOMMITを実行する
CLP (コマンド行プロセッサー）
CLPコマンド・オプションで設定する
-c
：（省略時値）AUTOCOMMITはON
＋ｃまたは -c- ：AUTOCOMMITはOFF
方法１：CLP実行時に指定する
ｄｂ２ −ｃ− またはｄｂ２ +ｃを付けてSQLを実行する
（例）db2 -c- "update table2 set col2=123 where col2='ABC' "
方法2：あらかじめCLPのコマンド・オプションの設定をしておく
CLPコマンド･オプションの設定： db2set DB2OPTIONS = '+c'
CLPコマンド･オプションの確認： db2 list command options
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：AUTOCOMMIT
CLPで設定されているコマンド・オプションを、以下のコマンドにより画面表示し確認することができます。
CLPコマンド･オプションの確認： db2 list command options
（出力例）
コマンド行プロセッサーのオプション設定
バックエンド・
プロセス待ち時間 (秒)
(DB2BQTIME) = 1
バックエンド接続の再試行回数 (DB2BQTRY) = 60
要求待ち行列待ち時間 (秒) (DB2RQTIME) = 5
入力待ち行列待ち時間 (秒) (DB2IQTIME) = 5
コマンド・オプション
(DB2OPTIONS) = +c ＜＝＝ DB2OPTIONSによるコマンド・オプションの設定
オプション説明
現在の設定
------ ---------------------------------------- ---------------a
SQLCA を表示する
OFF
-c 自動コミット
OFF ＜＝＝ AUTOCOMMITの設定 -e SQLCODE/SQLSTATE を表示する OFF
-f 入力ファイルから読み込む
OFF
-l 履歴ファイルにコマンドのログをとる
OFF
-o
出力を表示する ON
-p
対話式入力プロンプトを表示する ON
-r
出力を報告書ファイルに保管する
OFF
-s コマンド・エラーで実行を停止する
OFF
-t ステートメントの終了に文字を設定する
OFF
-v 現行コマンドをエコーする
OFF
-w
FETCH/SELECT 警告メッセージを表示する
ON
-z
出力ファイルにすべての出力を保管する
OFF
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 207-208 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
解説：AUTOCOMMIT
CLPを使用したロック取得の確認テスト方法例：
１．テストしたいISOLATIONレベルを設定する
db2 "change isolation to RS"
２．データベースに接続する（データベースに接続後には、ISOLATIONレベルの変更は不可能）
db2 connect to DBNAME
３．CLP実行時に、AUTOCOMMIT＝OFFを設定しながらSQLを実行する
db2 -c- "select * from table1 where col1 = '2000'"
４．COMMITを実行する前に、ロック・スナップショットを取得する
db2 get snapshot for locks on DBNAME
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 209-210 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
１0．いろいろな機能とロック
NOT LOGGED INITIALLY使用時のロックの考慮点
Declared Temporary Table（宣言済み一時表）
とロック
Savepointとロック
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 211-212 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
NOT LOGGED INITIALLY使用時のロックの考慮点
CREATE TABLEのNOT LOGGED INITALLY属性
CREATE TABLEステートメントと同じ作業単位内の更新処理について、ログをとらない
更新処理： INSERT,DELETE,UPDATE,CREATE INDEX,DROP INDEX, ALTER TABLE
考慮点
カタログ表にロックを取得し続けることで発生する、ロックの競合を防ぐため、以下の手順での
使用が望ましい
１．NOT LOGGED INTIALLY属性付きでCREATE TABLE後にCOMMITを行う
これにより、DB2のカタログ表へのロックを外す
２．別の作業単位でALTER TABLEによりNOT LOGGED INTIALLY属性の活動化を行う
３．更新処理を行う
CREATE TABLE ......
COMMIT ;
ALTER TABLE ......
更新処理 ; COMMIT ;
NOT LOGGED INITIALLY ;
ACTIVATE NOT LOGGED INITIALLY ;
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 213-214 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Declared Temporary Table（宣言済み一時表）とロック
Declared Temporary Table（宣言済み一時表）
には、ロックは取得され
ない
１アプリケーション固有の一時表であり、排他制御の必要性がないため
ワーク領域としての一時的な表を使用するアプリケーションに有効
システム・
カタログ表にロックを取得しない
Declared Temporary Table（宣言済み一時表）にロックを取得しない
更新ログを記録しない
USER Temporary Tablespace
session.t1
appl1
appl2
session.t1
session.t1
Declare global temporary
table t1 ........
appl3
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Declared Temporary Table（宣言済み一時表）とロック
宣言済み一時表とは
宣言済み一時表とは、一時表を作成したアプリケーションによって発行された SQL ステートメントにのみアクセス可能な一時表
を表します。宣言済み一時表は、アプリケーションがデータベースに接続している間しか有効ではありません。
宣言済み一時表を使用して、アプリケーションの潜在的パフォーマンスの向上を図ってください。宣言済み一時表を作成する場
合には、 DB2 はシステム・カタログ表に項目を挿入しないため、サーバーでカタログの競合による問題が起きることはありませ
ん。通常の表の場合とは異なり、DB2 は宣言済み一時表またはその行をロックせず、宣言済み一時表またはその表の内容をロ
グしません。現行のアプリケーションで多量のデータを処理するために表を作成し、アプリケーションによるデータの操作が終了
する際にそれらの表を除去する場合には、通常の表のかわりに宣言済み一時表を使用することを検討してください。
並行ユーザー用にアプリケーションを開発する場合には、宣言済み一時表が役立ちます。通常の表とは異なり、宣言済み一時
表では名前が重複しても問題は起こりません。アプリケーション各インスタンスでは、 DB2 は同じ名前の宣言済み一時表を作
成することができます。たとえば、多量の一時データを処理するのに通常の表を使用する並行ユーザーのためにアプリケーショ
ンを作成する場合には、アプリケーションの各インスタンスが一時データを保持する通常の表に対して固有な名前を使用する必
要があります。一般的には、ある時点で使用されている表の名前をたどる別の表を作成します。しかし、宣言済み一時表を使用
すると、一時データに対して 1つの宣言済み一時表を指定するだけで済みます。 DB2 は、アプリケーションの各インスタンスで
固有な表が使用されていることを保証します。
一時表の使用例
/*一時表の作成*/
DECLARE GLOBAL TEMPORARY TABLE T1 ( ID smallint not null, DATA integer, TEXT char(30) )
ON COMMIT DELETE ROWS
NOT LOGGED
IN USR_TEMP_TS;
/*一時表へのINSERT*/
INSERT INTO SESSION.T1
SELECT c1,c2,c3 FROM REAL_T1 WHERE DEPTNO=:mydept;
/* 一時表の削除 */
DROP TABLE SESSION.T1
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 215-216 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Savepointを使用した時のロック
SavepointまでROLLBACKした後も、ロックは保持される
On rollback release locksやOn rollback close cursorsはサポートされていない
ROLLBACK TO SAVEPOINT後に、処理のやり直しを行う場合のロック競合を防ぐため
使用例：
SAVEPOINT S1 ON ROLLBACK RETAIN CURSORS;
INSERT INTO MYTAB (C1, C2) VALUES (2,3);
INSERT INTO MYTAB (C1, C2) VALUES (2,1);
INSERT INTO MYTAB (C1, C2) VALUES (245,5);
ROLLBACK TO SAVEPOINT S1;
INSERT INTO MYTAB (C1, C2) VALUES (2,300);
INSERT INTO MYTAB (C1, C2) VALUES (200,3);
COMMIT;
実行結果
Ｃ１Ｃ２２３００
２００３
SAVEPOINT A；
処理Ａ
ROLLBACK!
ROLLBACK TO SAVEPOINT A；
SAVEPOINT B；
処理Ｂ
利点
作業単位（ＵＯＷ）の最初まで戻ることなく、処理のやり直し
が可能
ROLLBACK!
ROLLBACK TO SAVEPOINT B；
ＣＯＭＭＩ
Ｔ；
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Savepointを使用した時のロック
SAVEPOINTとはデータベースへのＳＱＬ処理が失敗した場合に、あるポイントまで処理をROLLBACKするしくみです。SAVEPOINT
ステートメントは、トランザクション処理の中で現在の位置に名前を与え、マークします。ROLLBACK TO ステートメントで、マークさ
れたＳＡＶＥＰＯＩ
ＮＴ名を指定すると、トランザクション全体ではなく、一部のみをROLLBACKさせることが可能です。
構文：
>>--SAVEPOINT-----savepoint-name--*--+----------+--*------------------->
'--UNIQUE--'
.--ON ROLLBACK RETAIN LOCKS--.
>--ON ROLLBACK RETAIN CURSORS--*--+----ー------------------------+--*----><
SAVEPOINT :
UNIQUE : SAVEPOINTが活動化されている間、アプリケーションからそのSAVEPOINT名を再使用しない場合の指定
ON ROLLBACK RETAIN CURSORS : SAVEPOINTを発行した後にOpenされたカーサーに関してRollback To SAVEPOINTによ
る影響。カーサーはRollback to Savepoint発行後も影響を受けない。ただし、SAVEPOINT後DDLで変更された従属に関しての
カーサーはInvalidate (SQLCODE -910)になる。
ON ROLLBACK RETAIN LOCKS : SAVEPOINTを発行した後にLockされたカーサーにObjectに関するRollback To
SAVEPOINTによる影響。LockはRollback to Savepoint発行後も影響を受けず、保持される。
RELEASE SAVEPOINT : マークされたSAVEPOINTを解放する。明示的なRelease Savepointを発行しなければTransaction
endにて解放される。解放されたSavepointをRollbackでUndoすることはできない。
ROLLBACK TO SAVEPOINT : SAVEPOINTまでROLLBACKする。この場合以下のカーサーが影響を受ける
考慮事項
SAVEPOINT内のDDL(CREATE VIEW,ALTER,CREATE ALIAS等）で作成されたOBJECTを参照するカーサーは、ROLLBACK
後使用できない(SQLCODE -910,SQLSTATE=57007)
SAVEPOINT内で参照されているカーサーは、OPEN状態は保たれFETCH時は整合性をもった値を返す
上記以外のカーサーは、ROLLBACK後影響を受けない
LOCKはROLLBACK TO SAVEPOINT後も保持される
LOB LocatorはROLLBACK TO SAVEPOINT後も参照可能
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 217-218 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
１１．Quiesce（１）
Quiesceとは
表スペースおよび指定した表単位にとられる排他制御
表スペース：互換性のないモードでのQuiesceの取得は不可
Quiesceコマンドで指定された表：互換性のないモードでのQuiesceの取得、および処理は不可
Quiesceコマンドで指定されていない表：更新処理以外は可能
LOADユーティリティーは内部的にQUIESCE Exclusiveを取得している
HOLD QUIESCE オプションにより、明示的に取得することも可能
ロックとは異なる性質
既存のQuiesceモードに反する処理は即時エラーとなり、WAITはしない
ロック・スナップショットには表示されない
Quiesce取得状況の確認
LIST TABLESPACES （SHOW DETAIL）コマンド
Quiesceの取得方法
QUIESCE TABLESPACES FOR TABLE 表名 [ SHARE | INTENT TO UPDATE | EXCLUSIVE | RESET ] コマンド
SHARE
：共有モード
INTENT TO UPDATE：更新意図モード
EXCLUSIVE
RESET
：排他モード
：既存のQuiesceの解除
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Quiesce（１）
互換性のない処理に対するエラー
SQL０２９０N：表スペース・アクセスが許されていません
（例）既存のQuiesceモードに反するSQL処理を行おうとした場合
SQL３８０５N：アプリケーション、または指定された表の１つ以上の表スペース状態が、loadapiアクションまたは
quiescemode"y"を禁止しています理由コード='n'
（例）既存のQuiesceと互換性のないQuiesceモードを取得しようとした場合
QUIESCE取得状況の確認
1.db2 "quiesce tablespaces for table TESTTAB1 share "
2.db2 "list tablespaces show detail" の出力
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
静止: SHARE
合計ページ数
使用可能ページ数
使用したページ
空きページ
最高水準点 (ページ) ページ・
サイズ (バイト)
エクステント・
サイズ (バイト)
プリフェッチ・サイズ (バイト)
コンテナー数
最小回復時間静止状態の数
静止状態 1:
表スペース ID
オブジェクト ID
=4
= TBLTBS
= データベース管理スペース
= 任意のデータ
= 0x0001
= 1000
= 992
= 736
= 256
= 736
= 4096
= 32
= 32
=1
= 2000-01-20-08.28.15.000000
=1
=4
=9
オブジェクトID：SYSCAT.TABLESのTABLEID列にある、表の識別番号
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
第５章( 219-220 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
Quiesce（２）
Phantom Quiesce
Quiesceを取得したユーザーのデータベース接続が無くなり、所有者がいなくなったQuiesce
以下の処理が可能
別のユーザーが同じモードのQuiesceをコマンド実行により取得する
別のユーザーがRESETする
互換性
Share
取得要求の
Intent to update
Quiesceモード
Exclusive
既存のQuiesceモード
Share
Intent to update
〇
〇
〇
×
×
×
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 221-222 )
Exclusive
×
×
×
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
１２．ロックのまとめ（１）
同時稼動性を高めるには
作業単位の区切りには必ずCOMMITを入れ、できるだけ早くロックを解放する
照会処理でもロック（Read Lock)は取得されるため、RR、RSのアプリケーションでも作業単位の区切りに必ず
COMMITを入れる
CLOSEカーソル WITH RELEASEを利用する
URのアプリケーションでも、動的SQLの場合にはカタログへのロックが取得される
COMMITされていない更新データは、他のアプリケーションからアクセスすることはできない
URのアプリケーションを除く
アプリケーション要件を満たすロックの制御を行うには
アプリケーションに適切なISOLATIONレベルを選択する
ロックの単位を用途に応じて設定する
LOCK TABLEにより表全体にロックを取得することが可能
ALTER TABLEによりロックの単位をROWまたはTABLEに設定することが可能
パフォーマンスを向上させるには
ロックに関する構成パラメーターのチューニング
モニタリング・ツールによる監視
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 223-224 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ロックのまとめ（２）
問題判別を行うには
イベント・モニター、ロック・スナップショットによる原因究明
UDB/EEEのdb2_call_stackユーティリティ
全てのDB2プロセスにシグナル３６を送信し、それぞれのコーリング・スタックをDIAGPATH上の、ファイル（txxxx.yyy）
にダンプさせる
ハング・タイプの状況で役立つ
２、３分のコール・スタックの変更を見るのに役立つ
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
ブランク・ページです
第５章( 225-226 )
DB2 UDB (PC&Unix) デザイン・ガイド
ロック
ブランク・ページです
ブランク・ページです
第５章( 227-228 )

第５章 ロック 内容

Comments

Description

Transcript

第５章ロック内容