4.5 パフォーマンスアップ

• partname： パーティション名
• estimate_percent：
  サンプリングする行のパーセンテージ
  適切な統計を行うための最適なサンプルサイズを0racleで決定するためには、定数DBMS_STATS．AUTO_SAMPLE_SIZEを使用
• block_sample：
  ランダム行サンプリングの代わりにランダムブロックサンプリングを使用する
• method_opt：
  ヒストグラムのサンプリング
  FOR ALL INDEXED COLUMNS SIZE｛integer | AUTO｝
• （AUTOと指定すると、列のデータ配分とワークロードに基づいて、ヒストグラムを収集する列を判断する
• degree：
  並列度
• granualarity：
  パーティションの場合のみ指定
• subpartition：
  サブパーティションレベルの統計情報を収集

SQL統計情報を分析する場合には、以下の点に注意して確認してください。

最終的に必要とされる行数に対して、アクセスしたブロック数：
索引を使用していないと、無駄なブロックのアクセス数が増える

最終的に必要とされる行数に対してフエッチした回数：
配列による結果行の取得を行っていないと、1回のフェッチで1行の読み込みしか行っていない場合がある

アクセスしたブロック数に対して、ディスクから物理的に読み込んだブロック数：
DBバッファキャッシュ上で、ブロックの共有ができていないと、物理読み込みの回数が増える
OLTP系のアプリケーションでは、90％以上のブロック共有が理想的といわれるが、共有できない理由として、次のような理由が考えられる

DBバッファキャッシュのサイズが小さいため上書きされる

適切な索引が作成されていないため、全表検索が選択される

パインド変数などが使われず、SQLの共有ができていない

ディスクソートが必要だった回数：
大量の行データに対してソートを行うのに対して、PGAに割り当てられた領域「SORTJREA_SIZEで指定」が小さく、一時表領域への読み書きが発生したことが考えられる

CPU時間に対するELAPSED TIME：
ELAPSED TIMEがCPU時間に対して長い場合、実際に処理をしているCPU時間よりもディスクIOの読み込み待ちや、ネットワークによる待ちに時間がかかっていることが考えられる これは、並行処理を行ううえで多重度が高くなったため、ディスクIOなどで競合が起きている可能性を示す

再解析が行われたか：
OLTP系のアプリケーションでは、なるべくSQL文が共有されている方が望ましい
再解析が行われていた場合、SQL文が共有できる記述になっていない、共有するための共有プールのサイズが不足していたなどの理由が考えられる

< 前へ　｜4.5 パフォーマンスアップ｜ 次へ >