Oracle 10gr2 では、パフォーマンスを比較している SQL クエリがいくつかあります。しかし、最初の実行後、v$sql テーブルにはキャッシュ用に実行計画が格納されているため、クエリの 1 つで、最初の実行の 28 秒から 0.5 秒後に実行されます。
私はもう試した
ALTER SYSTEM FLUSH BUFFER_CACHE;
これを実行した後、クエリは一貫して 5 秒で実行されますが、これは正確ではないと思います。
キャッシュからラインアイテム自体を削除する可能性があると考えました:
delete from v$sql where sql_text like 'select * from....
ビューから削除できないというエラーが表示されます。
ピーターは、あなたが尋ねた質問に答えました。
alter system flush shared_pool;
これは、「準備されたステートメントをキャッシュから削除する」ために使用するステートメントです。
(共有プールからフラッシュされるオブジェクトは準備済みステートメントだけではありません。ステートメントはそれ以上のことを行います。)
以前のコメント (あなたの質問について) で示したように、v$sqlはテーブルではありません。これは動的なパフォーマンス ビューであり、Oracle の内部メモリ構造を便利なテーブルのように表現したものです。動的パフォーマンス ビューに対する SELECT 権限のみがあり、それらから行を削除することはできません。
共有プールとバッファキャッシュをフラッシュしますか?
以下はあなたの質問に直接答えません。代わりに、根本的に異なる (そしておそらくもっと重要な) 質問に答えます。
クエリのパフォーマンスを測定するために、通常は共有プールやバッファ キャッシュをフラッシュする必要がありますか?
要するに、答えはノーです。
トム・カイトはこれをかなりうまく扱っていると思います：
http://www.oracle.com/technology/oramag/oracle/03-jul/o43asktom.html
http://www.oracle.com/technetwork/issue-archive/o43asktom-094944.html
<抜粋>
実際には、チューニング ツールがそれを行わないことが重要です。テストを実行し、結果を無視してから、2 ～ 3 回実行してそれらの結果を平均することが重要です。現実の世界では、バッファ キャッシュに結果がないことは決してありません。一度もない。チューニングするときの目標は、論理 I/O (LIO) を削減することです。これは、物理 I/O (PIO) がそれ自体を処理するためです。
これを考慮してください: 共有プールとバッファ キャッシュをフラッシュすることは、それらをフラッシュしないよりも人工的です。ほとんどの人はこれに懐疑的であるように思われます。これを行う方法を説明しますが、テストに使用できるようにするためではありません。むしろ、それが無益で完全に人為的な演習である理由を示すために使用します (したがって、間違った仮定につながります)。PC を起動したばかりで、大きなテーブルに対してこのクエリを実行しました。バッファ キャッシュを「フラッシュ」して、もう一度実行します。
</抜粋>
トム・カイトはまさにその通りだと思います。パフォーマンスの問題に対処するという点では、「オラクルの実行計画のキャッシュをクリアする」ことは、通常、信頼できるベンチマークのためのステップではないと思います。
パフォーマンスに関する懸念に対処しましょう。
クエリの最初の実行は、バッファ キャッシュから (すべてのインデックスとデータ ブロックを) フラッシュする場合でも、後続の実行 (~5 秒) と比較して大幅に長い (~28 秒) かかることを確認したとのことです。
私には、これは、ハード パースが何らかの重労働を行っていることを示唆しています。それは大変な作業であるか、多くの待機に遭遇するかのいずれかです。これは、調査して調整することができます。
おそらく統計が存在しないのではないかと考えています。オプティマイザは、クエリ プランを準備する前に、統計の収集に多くの時間を費やしています。これは、私が最初に確認することの 1 つであり、参照されているすべてのテーブル、インデックス、およびインデックス付きの列について統計が収集されていることです。
クエリが多数のテーブルを結合する場合、CBO は結合順序について膨大な数の順列を検討している可能性があります。
Oracle トレースの議論はこの回答の範囲を超えていますが、次のステップです。
おそらく、イベント 10053 と 10046 をトレースしたいと思うでしょう。
Tom Kyte による "event 10053" ディスカッションへのリンクを次に示します。
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:63445044804318
接線的に関連する逸話 re: ハード解析パフォーマンス
数年前、最初の実行では MINUTES 単位で経過し、その後の実行では秒単位で経過したクエリを 1 つ見ました。私たちが発見したのは、最初の実行時間の大部分がハード解析に費やされたということです。
この問題のクエリは、CrystalReports の開発者によって作成されました。CrystalReports の開発者は、2 つの巨大なレポート ビューに無邪気に (単純に?) 参加しました。
ビューの 1 つは 62 テーブルの結合で、もう 1 つのビューは 42 テーブルの結合でした。
クエリでは、Cost Based Optimizer が使用されました。トレースにより、これは待機時間ではなく、考えられる結合パスの評価に費やされたすべての CPU 時間であることが明らかになりました。
ベンダーが提供する「レポート」ビューのそれぞれは、それ自体はそれほど悪くはありませんでしたが、そのうちの 2 つが結合されると、非常に遅くなりました。問題は、オプティマイザーが検討していた膨大な数の結合順列にあったと思います。オプティマイザーによって考慮される順列の数を制限するインスタンス パラメーターがありますが、私たちの修正はクエリを書き直すことでした。改善されたクエリは、クエリで実際に必要とされた十数個のテーブルのみを結合しました。
(最初の即時の短期的な「応急処置」の修正は、レポート生成タスクが実行される前に、早朝にクエリの実行をスケジュールすることでした。これにより、レポート生成の実行が既にハード解析を回避して、共有プール内の準備済みステートメント。
バンドエイドの修正は実際の解決策ではありませんでした。実行時間が長いことに気付かなかったときに、問題をクエリの予備実行に移しただけです。
次のステップは、安定したクエリ プランを取得するために、クエリの "格納されたアウトライン" を実装することだったでしょう。
もちろん、ステートメントの再利用 (ハード解析を回避し、バインド変数を使用する) は、Oracle の規範的なパターンです。パフォーマンス、スケーラビリティ、ヤダ、ヤダ、ヤダを改善します。
この逸話的な事件は、あなたが観察している問題とはまったく異なるかもしれません。
HTH
Oracle を使用してからしばらく経ちましたが、実行計画は共有プールにキャッシュされていると思います。これを試して：
alter system flush shared_pool;
バッファ キャッシュは、ディスク IO を最小限に抑えるために、Oracle が最近使用したデータを格納する場所です。
最近、パフォーマンス調整クエリで多くの作業を行っています。クエリのパフォーマンスに一貫性がない原因の1つは、Oracleが使用しているファイルシステムキャッシュです。
Oracleキャッシュをフラッシュしている間、ファイルシステムにクエリが要求しているデータが残っている可能性があります。これは、クエリが引き続き高速に返されることを意味します。
残念ながら、ファイルシステムのキャッシュをクリアする方法がわかりません。非常に役立つシステム管理者からの非常に役立つスクリプトを使用しています。