Question & Answer
Question
複数のデータベース・パーティションを持つシステムで、ALTER TABLE や統計更新などシステム・カタログを更新する作業中に、非カタログ・パーティションから該当テーブルを含む SQL を実行すると、カタログ・キャッシュのロック競合によるデッドロック (SQL0911N RC=2) が発生することがあります。
Cause
Db2 はシステム・カタログ表の参照によるオーバーヘッドを削減するために、システム・カタログ表の内容をカタログ・キャッシュに保管し、SQL のコンパイルなどのパフォーマンスを向上させています。
カタログ・キャッシュの新規作成、更新、削除の競合を管理するために、各キャッシュ・エントリーにはカタログ・キャッシュ・ロックが設定されます。また、複数のデータベース・パーティションを持つシステム (DPF) では、各データベース・パーティション上にキャッシュが保持されます。
カタログ・キャッシュは複数のシステム・カタログ表の情報をキャッシュします。表やビューのカタログ情報を管理する SYSTABLES 表のキャッシュ・エントリーは、以下のように Loading Lock と Usage Lock で管理されます。
キャッシュ・エントリーにアクセスする場合、まず Loading Lock の排他ロックを取得し、キャッシュ参照の場合は Usage Lock の共有ロックを、キャッシュ更新の場合は Usage Lock の排他ロックを取得します。
非カタログ・パーティションで SQL をコンパイルする場合、エージェントは以下のようにシステム・カタログの情報にアクセスします。
ALTER TABLE など、システム・カタログ表を更新する操作を行う場合、エージェントは以下のようにキャッシュ・エントリーの無効化を行います。
このため、非カタログ・パーティションから照会を実行中にカタログ表の更新操作を行うと、以下のようなデッドロックが発生する可能性があります。
カタログ・キャッシュの新規作成、更新、削除の競合を管理するために、各キャッシュ・エントリーにはカタログ・キャッシュ・ロックが設定されます。また、複数のデータベース・パーティションを持つシステム (DPF) では、各データベース・パーティション上にキャッシュが保持されます。
カタログ・キャッシュは複数のシステム・カタログ表の情報をキャッシュします。表やビューのカタログ情報を管理する SYSTABLES 表のキャッシュ・エントリーは、以下のように Loading Lock と Usage Lock で管理されます。
$ db2pd -db <データベース名> -catalogcache
Catalog Cache:
SYSTABLES:
Address Schema Name Type CatalogCacheLoadingLock CatalogCacheUsageLock
0x077000008AA321A0 DB2INST1 T1 T 00010000077000008AA321A043 00000005000060008AA321A043
上の例では、SYSIBM.SYSTABLES システム・カタログ表にある DB2INST1.T1 表の行の内容が、カタログ・キャッシュのアドレス 0x077000008AA321A0 に格納され、このキャッシュ・エントリーの排他制御に使われる Loading Lock 名は 00010000077000008AA321A043、Usage Lock 名は 00000005000060008AA321A043 であることを示します。キャッシュ・エントリーにアクセスする場合、まず Loading Lock の排他ロックを取得し、キャッシュ参照の場合は Usage Lock の共有ロックを、キャッシュ更新の場合は Usage Lock の排他ロックを取得します。
非カタログ・パーティションで SQL をコンパイルする場合、エージェントは以下のようにシステム・カタログの情報にアクセスします。
- ローカル・パーティションのカタログ・キャッシュから該当表のエントリーを探します。
- 有効なキャッシュ・エントリーがあれば、Loading lock に排他ロックを取得し、Usage Lock に共有ロックを取って情報を読み取ります。
- 有効なキャッシュ・エントリーがない場合、Loading lock に排他ロックを取得し、カタログ・パーティションの情報を読み込みます。
- カタログ・パーティション上のサブ・エージェントは、カタログ・パーティションのカタログ・キャッシュから該当表のエントリーを探します。
- 有効なキャッシュ・エントリーがあれば、Loading lock に排他ロックを取得し、Usage Lock に共有ロックを取って情報を読み取ります。
- 有効なキャッシュ・エントリーがない場合、Loading lock に排他ロックを取得し、システム・カタログ表を照会して有効なキャッシュ・エントリーを作成します。
- カタログ・パーティションに有効なキャッシュ・エントリーが作成できると、Usage Lock に共有ロックを取って情報を読み取り、コーディネーター・エージェントに情報を戻します。
ALTER TABLE など、システム・カタログ表を更新する操作を行う場合、エージェントは以下のようにキャッシュ・エントリーの無効化を行います。
- システム・カタログ表の更新操作は、カタログ・パーティションに転送されます。
- システム・カタログ表の該当行の排他ロックを取得し、行を更新します。
- カタログ・パーティションで該当行のキャッシュ・エントリーに対する Loading Lock の排他ロックを取得し、キャッシュ無効フラグを設定します。
- 関連する他のパーティションのカタログ・キャッシュ・エントリーに対し、キャッシュの無効化要求をブロードキャストします。
- 各パーティションのサブ・エージェントは、カタログ・キャッシュ・エントリーの Loading lock に排他ロックを取得し、キャッシュ無効フラグを設定します。
このため、非カタログ・パーティションから照会を実行中にカタログ表の更新操作を行うと、以下のようなデッドロックが発生する可能性があります。
|
カタログ・パーティション
|
非カタログ・パーティション
|
|
|
照会
|
Loading Lock 待ち
|
Loading Lock 取得
|
|
カタログ更新
|
Loading Lock 取得
|
Loading Lock 待ち
|
Answer
上記のシナリオでのロック要求と、ロック要求に伴うデッドロックの発生は、現時点の Db2 のデザインに基づく制限事項です。
ALTER TABLE や RUNSTATS などでシステム・カタログ表を更新する場合、更新対象の表を含む SQL の実行は避けてください。
運用上の考慮点
ALTER TABLE や統計更新などのメンテナンス作業と、非カタログ・パーティションでのメンテナンス対象表を含む SQL の同時実行を行わないようにしてください。
関連情報
catalogcache_sz - カタログ・キャッシュ・サイズ構成パラメーター
ALTER TABLE や RUNSTATS などでシステム・カタログ表を更新する場合、更新対象の表を含む SQL の実行は避けてください。
運用上の考慮点
ALTER TABLE や統計更新などのメンテナンス作業と、非カタログ・パーティションでのメンテナンス対象表を含む SQL の同時実行を行わないようにしてください。
関連情報
catalogcache_sz - カタログ・キャッシュ・サイズ構成パラメーター
[{"Type":"MASTER","Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"ARM Category":[{"code":"a8m0z0000001kF0AAI","label":"Catalog"},{"code":"a8m500000008PmMAAU","label":"Performance-\u003ELocks"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
25 August 2023
UID
swg21587116