Oracle 実行計画の読み方

コメントあれば、よろしくお願い致します。

0 recursive calls
0 db block gets
7,800,000 consistent gets --select文でアクセスしたバッファキャッシュのブロック数。ディスクとメモリへの総アクセス数　A
3,500,000 physical reads --ディスク上のデータファイルにアクセスしたデータ要求の総ブロック数　B
0 redo size
219,000,000 bytes sent via SQL*Net to client
7,100,000 bytes received via SQL*Net from client
500,000 SQL*Net roundtrips to/from client
100 sorts (memory) --メモリ内でソートした回数　C
0 sorts (disk)
9,200,000 rows processed --処理対象となった行数　D

一番、重視しなければいけないのは、A だと思っています。
780万回もアクセスされていますが、
ブロック数が 8K に設定されている環境であったとして、
1024*8*780万 = 63,897,600,000約 63GB の i/o が一つのSQLで発生

B に関しても一応計算してみると、
1024*8*350万 = 28,672,000,000約 28GB の i/o が一つのSQLで発生

D に関しては、920万行という結果は分かるが、1行辺りの幅が分からないので、
幅を別途SQLから計算し、どういった負荷を与えている文なのかを分析する必要がある。

select statement optimizer=choose
からの数十行には、
(FULL)が、(UNIQUE INDEX)に比較して、10倍ぐらい表示されていると仮定します。

それぞれの検索テーブルの件数ははっきりしていたとして(1件～2000万件ぐらい(400万件以上が5テーブル))、
何をどうするのがSQLチューニングでしょうか。

No.3 ベストアンサー 回答者： ossan_hiro 回答日時： 2006/12/04 12:28

>一番、重視しなければいけないのは、A だと思っています。

私はBだと思います。
ディスクアクセスはメモリアクセスの比較にならないくらい遅いですから。

>9,200,000 rows processed --処理対象となった行数　D
900万件も一気にクライアントに送って処理させるのですか？
こういった処理はPL/SQLなどで任せたほうがいいような気がします。

>(FULL)が、(UNIQUE INDEX)に比較して、10倍ぐらい表示されていると仮定します。
TABLE FULL SCANが悪とは言わないですが、件数の多いテーブルを
(FULL)にしないようにしたほうがいいと思います。

対象件数が多い（多すぎる）ので、どこまで絞れるのかは不明ですが、
処理的に思いのであれば一気にやろうとせずに一時表のようなものに
退避させるとかしたほうが良いのでは？

No.2 回答者： ktktkota 回答日時： 2006/12/01 19:22

PLAN_TABLEもお願いします。

No.1 回答者： MZ-80B 回答日時： 2006/11/30 16:22

SQLのチューニングは実行計画（結合順序とアクセスパス）と

統計情報で１つです。つまり一方のみ提示して
どうですか？と言われても回答するのが難しいです。
明細のない家計簿を見ているようなものです。

今、提示している統計は explain(autotrace)のものですよね？
面倒ですが explainではなく sql_traceを使用することを薦めます。

SQLチューニングを理解したい場合には
パフォーマンス・チューニング・ガイド（SQLの最適化）を読んでみてください。