~今回は前回の検証で見られた以下の現象についてもう少し調べてみたい。索を行なった時、すべてのデータをディスク上からメモリに読み込んでいるにも関わらずヒット率が高い。以下は、前回の検証で得られたAUTOTRACEの統計情報である。89%まず、上記の結果を得たSQL文のトレースファイルを見てみたい。sessionを行なうことで、初期化パラメータuser_dump_destで指定したディレクトリに出力される。altered.以下、実行したSQL文の情報に該当する部分をトレースファイルから取得した内容である。・以下同様に続く(6万行くらい。”r”はFETCHで取得された行数を表している。SQL*Plusでは最初のFETCHで1行取り出し、2行目以降は配列サイズ(arraysize)、つまり、複数行づつ取り出している。実は、2回以降のFETCHで一度に取得される15行という値はSQL*Plusのデフォルトの配列サイズなのである。以下のコマンドで変更することが可能である。下側を見ていただくと15、つまり15行になっていることが確認出来る。次に、[注目2]をみて頂きたい。gets”の値である。gets”の値が同じになることが確認できた。ほとんどのFETCHはcrが1であるが[注目2]では2になっている。これは15行を読み込む際に2つのブロックにアクセスしている為であろう。これは1回目FETCHで取得される行数が1行であることを考えるとほぼ不可能だろう。1ブロックに1行のデータなら可能だが、今回は検証外とする。方法2.配列サイズをすべての取得行が入る大きさにする。1回の読み込みですべての行数が得られればヒット率は高くなるはずである。5000)やはり怒られてしまった。5000が最大のようである。配列サイズを最大の5000に設定してもう一度ヒット率を計算してみたい。3.4%!今回だけ読んで頂いている方はあたりまえだろ!と思われるかもしれないが、arraysizeを大きくしたことによりヒット率が激減したことが分かる。変更することによって、実行時間が25秒も短縮されている。この差は大きいと言えよう。41秒59では、上記の結果のトレースファイルを見てみよう。・以下同様に続く(2000行くらい)ほとんどのFETCHで40ブロックにアクセス(cr=40)し5000行を取得(r=5000)している様子がよく分かる。PARSEを行なう際の”cr”が75加算されている事と、”cr”が41の場合がある事で、その分、読取り一貫性モードでブロックへアクセスが増えて、ヒット率が0%でなく3.4%になっていることが分かる。検証出来なかった他の条件でもヒット率が大きく変わること予想される。ヒット率が下がっても実行時間が早くなっている事を考えると、チューニングを行なう際は、単純にデータベース・バッファのヒット率だけではなく、その他の条件も考慮する必要があると言えよう。reserved.トップページ企業概要プライバシーポリシ。