db2batchスナップショット・モニター出力の着眼点(5)
db2batchユーティリティはSQL文を実行させ応答時間を表示すると共に実行期間中のスナップショット・モニターも出力できます(-o
p 3オプション)。 アクセス・プランはオプティマイザーが統計情報と構成パラメーターにもとづいて生成した実行計画です。SQL文を実行する時はDB2カーネルがアクセス・プランにもとずいて実行します。実際に動いた時の挙動はスナップショット・モニターの各種カウンターから読み取れます。統計情報からオプティマイザーは動いた時の中間の行数やアクセスするページ数など見積もりを算出しますが、スナップショット・モニターでは実際に動いた時の実績を見ることができます。
上側：リスト・プリフェッチ
アクセス・プランで操作は[1]IXSCAN->[2]SORT->[3]RIDSCN->[4]FETCHの順でした。ここで[
]内の番号は操作順に振りなおしました。これに対応したモニター・エレメントは次の通りです。
[1]IXSCANの要したページ数Buffer pool index logical reads =14 つまり、索引階層を下がってリーフページの8000
<= D1を満たす最初のページからD1<=9000を満たす最後のページまでの読み取りページ数が14ページあった。
[2]SORTではTotal sorts=1 ソートは１回だけで、Total sort time(ms)=2 ２ミリ秒を要した。
[3]RIDSCN 取り出すべきページのリストに従ってdb2非同期IOサーバーが非同期データページ読み取りを行った：
Asynchronous pool data page reads =9
[4]FETCH データページの論理読み取が12ページ要求された： Buffer pool data
logical reads =12
このようにアクセス・プランに従った実行がなされていることがわかります。
下側：順次プリフェッチ
上と比較してBuffer pool index logical reads = 0 です。つまり索引は全く読んでいません。代わりにBuffer
pool data logical read =9265で、この値は(3)の下で出てきた表の統計情報にある表のページ数Number
of buffer pool pagesです。これが実際に読み取ったページ数です。さらにAsynchronous
pool data page reads = 5871ページは非同期IOサーバーで非同期並列読取りされたことがわかります。このことは順次プリフェッチが実際に動いたことを示しています。
上下、二つのアクセス・プランを見ました。逆にこれらのスナップショット出力を見て、先に見たアクセス・プランの流れを思い出しましょう。下の特徴は索引論理READがなくてasynchronous
pool data reads があるのは表スキャンの特徴です。このようなスナップショットのSQLは表スキャンの可能性が非常に高いと見ましょう。同様に上のスナップショットはリスト・プリフェッチを思い出すに足りる兆候を持っています。
まず、これを再現するSQL文の例を見ます。上下のSQLはそっくりです。上は範囲検索で他の列max()を得ています。下は同様に範囲検索で他の列のmax()を得ていますが、上はwhere条件が索引列のひとつc1列、下は索引ではない列d1列を範囲指定しています。上でリスト・プリフェッチが使われ、下では順次プリフェッチが使われていることが以降でわかります。応答時間は上の方がずっと短くなっています。
