問題タブ [db2-zos]

z/OS 上の DB2 データベースのインスタンスを指す 2 つの DbVisualizer インスタンスから開始された 2 つのトランザクションの動作を調べたところ、テーブルからレコードを削除する際に次のような動作があることに気付きました。

MYTABLE主キーを持つテーブルがMYIDあり、実行するとします

select MYID from MYTABLE

次のようなものを与えます（数字は任意であり、物事を具体的にするために書き留められます）

トライアル Aでは、最初のトランザクション (最初の DBVisualizer インスタンスを使用) から、コミットせずに実行します。

次に、2 番目のトランザクションから実行します (2 番目の DBVisualizer インスタンスを使用)。

ただし、これにより2番目のトランザクションがブロックされ、しばらくするとエラーが発生します

同様の試行である試行 BMYIDで、 sを使用112し、789代わりに ( 789is "not near" 112) を使用すると、2 番目のトランザクションはブロックされません。https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/codes/src/tpc/db2z_resourcetypes.htmlで、「表スペース・ページ」(リンクは DB2 用です)の意味をTYPE OF RESOURCE 00000302調べると、z/OS で)。

したがって、トライアル AMYID 112では、最初の DELETE がとの両方のレコードが「属している」いくつかの「ページ」を「ロック」し119、このロックが 2 番目のトランザクションをブロックしたように見えます。試行 Bでは、2 つのレコードは異なる「ページ」に属し、最初の DELETE は 2 番目のレコードをブロックしません。

DB2 に関するよく知られた本を読んで、「要求された操作に応じて、データベース マネージャーはテーブル行、テーブル ブロック、テーブル、テーブル スペース、バッファー プール、およびデータベースのロックを取得できます」を読みました。次に、さまざまな「ロックモード」があることを説明します。

私の質問は次のとおりです。上記の引用の「テーブルブロックのロック」は、トライアルAで観察された「テーブルスペースページのロック」を指していますか、それとも引用に記載されていない他のロックタイプですか? そして、使用されるロックが「テーブルスペースページロック」であり、試行 A中に 2 番目のトランザクションがブロックされないと思われる行レベルのロックではないのはなぜですか? (DB2 でのロックのエスカレーションについて読んだことがありますが、私が知る限り、その時点で実行されていたトランザクションはありませんでしたMYTABLE)

関連する DB2 バージョンは、「互換モード」で 10 であり、DB2 バージョン 8 のようなものにダウングレードされます。それ以外の場合、構成は「デフォルト」または「標準」にする必要があると思います。

(この質問は、以前の質問Can one delete statement that delete multiple rows cause deadlock?で説明されている問題を理解しようとした結果です。 )

編集

Windows ノートブックの DB2 Express で試してみたところ、動作が異なります。ロックは、期待どおりの行ロックです (したがって、2 番目の DELETE は、同じ行を削除しようとした場合にのみブロックされます)。では、これは実際に z/OS 上の DB2 に関するものなのでしょうか? それともDB2の古いバージョンですか？それとも、この観察結果は、DB2 の特別な構成を暗示しているのでしょうか?

これは私を困惑させます。DB2 自体からのプルは高速であり、テーブルからのプルも高速ですが、それらがうまく連携しない理由はわかりません。DB2 テーブルまたはそこにあるサーバーのインデックスにアクセスできません。

このクエリには 0.017 秒かかります。

20 万近くの部品番号を照会する必要があるため、すべての部品番号をハードコーディングしたくないことは明らかです。

これを機能させるために、ここに部品番号を残しました。同じ 6 つの部品番号を選択するこのクエリには、1.23 秒かかります。

問題は、これらを組み合わせる場合です。

私の考えでは、このクエリには約 3 秒程度かかるはずです。492 秒かかります。

これを行うより良い方法はありますか？PARTS_REPORT テーブルにインデックスを付ける必要がありますか? ここでの鍵は何ですか？

編集: 200k っぽい部品番号をすべて実行するには、同じクエリに 564 秒かかります。これは、上記の実行にかかる時間とほぼ同じです。

編集 2: 以下のユーザーは、何が起こっているのかを知るのに役立ちました - リモートテーブル全体をプルダウンする必要があり、それは遅いです。今何が起こっているのか理解できたと思います - ありがとう。