任意選択として、索引に関するより詳細な統計の収集を行うと、 最適化プログラムが、その索引を使用して、 表にアクセスする際のコストをより正確に見積もることができるようになります。 これを行うには、2 つの方法のいずれかを選択できます。 1 つは、 RUNSTATS コマンドで DETAILED 文節を使用する方法で、もう 1 つは、 RUNSTATS API の呼び出し時に statsopt パラメーターに A、Y、X のいずれかを指定する方法です。 DETAILED 統計の PAGE_FETCH_PAIRS と CLUSTERFACTOR は、 表のサイズが十分に大きい (約 25 ページ以上) 場合にのみ収集されます。 この場合には、CLUSTERFACTOR の値は 0 から 1 の間になり、 CLUSTERRATIO の値は -1 (収集されないことを示す) になります。 25 ページより小さい表の場合には、CLUSTERFACTOR の値は -1 (収集されないことを示す) になり、 その表の索引に対して DETAILED 文節を指定した場合であっても、 CLUSTERRATIO の値は 0 から 100 になります。
DETAILED 統計は、簡潔な方法で、 完全な索引走査がさまざまなバッファー・サイズの下で行われるとしたときに、 表のデータ・ページにアクセスするのに必要になる物理入出力の数を把握しようとするものです。 RUNSTATS は索引のページ全体を走査するとして、 さまざまなバッファー・サイズのモデルを作り、 ページ不在が起こる頻度の見積もりを収集します。 たとえば、使用可能なバッファー・ページが 1 ページだけという場合には、 索引によって新しくページが参照されるたびに (状況によっては、 各行が異なるページを参照するたびに) ページ不在が生じることになるので、 CARDINALITY 入出力が非常に多くなります。 他方の極端な例をあげると、 バッファーが表全体を入れられるくらい大きい (ただし最大バッファー・サイズ以下) 場合には、 その表の NPAGES ページのそれぞれが、 完全に 1 回で物理的に読み取られることになります。 したがって、物理入出力の数は必ずバッファー・サイズの単調で非増加の関数になります。
RUNSTATS は、これらの見積もりに断片線形曲線を当てはめ、この曲線は、 PAGE_FETCH_PAIRS 統計の 11 対のストリングとして保管されます。 各対の最初の値は仮定バッファー・サイズを表し、2 番目の値は、 そのサイズのバッファーが全部索引の走査に使用可能であるとして、 1 回の索引走査でデータ・ページを取り出す際の物理入出力の見積数を表します。 次に、最適化プログラムは、PAGE_FETCH_PAIRS 統計を使用して、 その索引を使用した全索引走査または部分索引走査におけるデータ・ページ取り出しの物理入出力の数を見積ります。
PAGE_FETCH_PAIRS に保管されている索引の曲線の形状は、 その索引のクラスター化の動作によって異なります。
図 77. クラスター化索引および非クラスター化索引の 3 種類の曲線
![]() |
考えられる曲線には 3 つのタイプがあります。
照会において参照する列がすべて索引内に収まっているわけではない場合には、 DETAILED 索引統計を使用するようにしてください。 また、DETAILED 索引統計は以下のような場合に使用する必要があります。
以前の状況に関する知識がなく、 さらに、バッファー・サイズを変えて索引走査の施行を試行し、 その結果の物理入出力を観察するモニターを使用しなければ、 これらの状況を判別するのは非常に難しいと言えます。 これらの状況が生じているか否かを最も簡単に判別する方法は、 索引に関する DETAILED 統計を収集して、 その結果の PAGE_FETCH_PAIRS が非線形であった場合にはそれらを保存することです。