Oracle 10g でクエリのパフォーマンスを客観的に測定する良い方法はありますか? 数日間チューニングしてきた特定のクエリが 1 つあります。(少なくとも最初のテストに基づくと)より高速に動作しているように見えるバージョンを入手しましたが、EXPLAIN のコストはほぼ同じです。
EXPLAIN コストに何かが欠けている可能性はどのくらいありますか?
非常にありそうもない。実際、それはレベルの1バグです:)
実際には、 を実行した時点から統計が大幅に変化した場合EXPLAIN、実際のクエリ プランは異なります。ただし、クエリがコンパイルされるとすぐに、計画は同じままになります。
発生する可能性が高いが、実際のクエリでは決して発生しない可能性EXPLAIN PLANがあることを示していることに注意してください。
EXPLAIN PLAN同様に、階層クエリでを実行すると、次のようになります。
SELECT *
FROM table
START WITH
id = :startid
CONNECT BY
parent = PRIOR id
idと の両方にインデックスがある場合、実際にはほとんど発生しない可能性が高いparent余分な情報が表示されます。FULL TABLE SCAN
を使用STORED OUTLINEして、何があっても計画を保存して再利用します。
EXPLAIN のコストがクエリの実際のパフォーマンスと著しく異なる特定の状況はありますか?
はい、複雑なクエリで非常に頻繁に発生します。
CBO(コストベースのオプティマイザー) は、計算された統計を使用してクエリ時間を評価し、最適なプランを選択します。
クエリ内のものに多数JOINの 、サブクエリ、およびこれらの種類がある場合、そのアルゴリズムは、特にメモリ制限に達したときに、どのプランがより高速になるかを正確に予測できません。
あなたが尋ねた特定の状況は次のとおりHASH JOINです。たとえば、 はprobe table、ハッシュ テーブルが に適合しない場合にを何度かパスする必要がありますpga_aggregate_tableが、 の時点でOracle 10g、 がこれを考慮したことは覚えていませんCBO。
そのため、最悪の場合でも数秒以上実行されると予想されるすべてのクエリをヒントにしています。2
このクエリでは first_rows ヒントを使用しました。これは影響がありますか？
このヒントにより、オプティマイザーは応答時間が短い計画を使用するようになります。全体的なクエリ時間は長くなりますが、できるだけ早く最初の行が返されます。
実際には、ほとんどの場合、NESTED LOOPの代わりに を使用することを意味しHASH JOINます。
NESTED LOOPは、大規模なデータセットで全体的なパフォーマンスが低下しますが、最初の行をより速く返します (ハッシュ テーブルを構築する必要がないため)。
Q: Oracle 10g でクエリのパフォーマンスを客観的に測定する良い方法はありますか?
http://asktom.oracle.com/tkyte/article1/autotrace.html (記事移動)
http://tkyte.blogspot.com/2007/04/when-explanation-doesn-sound-quite.html
http:// asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:5671636641855
また、他の環境で Oracle トレースを有効にすることはそれほど難しくありません。
Q:数日間チューニングしてきた特定のクエリが 1 つあります。(少なくとも最初のテストに基づくと)より高速に動作しているように見えるバージョンを入手しましたが、EXPLAIN のコストはほぼ同じです。
Q: > 1 . EXPLAIN コストに何かが欠けている可能性はどれくらいありますか?
Q: > 2 . EXPLAIN のコストがクエリの実際のパフォーマンスと著しく異なる特定の状況はありますか?
Q: > 3 . このクエリでは first_rows ヒントを使用しました。これは影響がありますか？
/*+ FIRST_ROWS */) は、オプティマイザーによって選択されるプランに影響を与える可能性があります。EXPLAIN PLAN によって返される「コスト」は相対的です。これはパフォーマンスの指標ですが、正確な指標ではありません。コストの数値を、ディスク操作の数、CPU 秒数、または待機イベントの数に変換することはできません。
通常、EXPLAIN PLAN コストが 1 と表示されているステートメントは「非常に速く」実行され、EXPLAIN PLAN コストが 5 ～ 6 桁程度のステートメントは実行に時間がかかります。しかしいつもではない。
オプティマイザーが行っているのは、考えられる多くの実行プラン (全テーブル スキャン、インデックスの使用、ネストされたループ結合など) を比較することです。オプティマイザーは、各プランに番号を割り当ててから、番号が最も小さいプランを選択します。
EXPLAIN PLAN によって示されるオプティマイザ プランが、ステートメントの実行時に使用される実際のプランと一致しないケースを見てきました。10 年前の Oracle8 で、特に文にリテラルではなくバインド変数が含まれる場合に、それを見ました。
ステートメント実行の実際のコストを取得するには、ステートメントのトレースをオンにします。これを行う最も簡単な方法は、SQLPlus AUTOTRACE を使用することです。
[http://asktom.oracle.com/tkyte/article1/autotrace.html][4]
SQLPlus 環境の外では、Oracle トレースをオンにすることができます。
セッション セット timed_statistics = true を変更します。
セッション セット tracefile_identifier = here_is_my_session を変更します。
セッション セット イベント '10046 トレース名コンテキストを永久に変更、レベル 12'
--alter session set events '10053 trace name context forever, level 1'
select /*-- your_statement_here --*/ ...
セッション セット イベント '10046 トレース名コンテキスト オフ' を変更します。
--alter session set events '10053 trace name context off'
これにより、トレース ファイルがサーバーの user_dump_dest ディレクトリに配置されます。作成されたトレース ファイルには、ステートメント計画とすべての待機イベントが含まれます。(割り当てられたトレースファイル識別子はファイル名に含まれ、udump ディレクトリでファイルを見つけやすくなります)
'user_dump_dest' のような名前の v$parameter から値を選択します
tracefile にアクセスできない場合は、データベース管理者にアクセスしてもらう必要があります。(dba は、開発者が .trc ファイルに対して実行して tkprof を実行できる単純なシェル スクリプトを作成し、トレース ファイルと tkprof 出力のアクセス許可を変更できます。また、新しい trcanlzr を使用することもできます。両方。
私の知る限り、EXPLAINはいくつかのデータベース統計を使用してコストを計算しているため、実際のパフォーマンスとは明らかに異なる場合があります.
私の経験では、EXPLAIN は正確で有益でした。そうでなければ、それは有用なツールではないかもしれません。最後にテーブルを分析したのはいつですか? 分析の前後で Explain プランがほぼ同じであるのを見てきましたが、分析によってパフォーマンスが大幅に向上しました。