ベンチマークのためにOracle実行プランのキャッシュをクリアするにはどうすればよいですか？
Oracle 10gr2では、パフォーマンスを比較しているいくつかのSQLクエリがありますが、最初の実行後、v $ sqlテーブルにはキャッシュ用の実行プランが保存されているため、最初の実行の28秒から0.5秒後。
私はもう試した
ALTER SYSTEM FLUSH BUFFER_CACHE; -これを実行した後、クエリは一貫して5秒で実行されますが、これは正確ではないと思います。
キャッシュから広告申込情報自体を削除することを考えました：vselectからv $ sqlを削除します。
ピーターは、あなたが尋ねた質問に対する答えをあなたに与えました。
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を起動したばかりで、このクエリを大きなテーブルに対して実行しました。バッファキャッシュを「フラッシュ」して、再度実行します。
</ excerpt>
トム・カイトはまさに正しいと思います。パフォーマンスの問題に対処するという点では、「Oracle実行プランのキャッシュをクリアする」ことは、通常、信頼できるベンチマークのためのステップではないと思います。
パフォーマンスに関する懸念に対処しましょう。
クエリの最初の実行には、バッファキャッシュ（すべてのインデックスとデータブロック）をフラッシュする場合でも、後続の実行（〜5秒）に比べて大幅に長い（〜28秒）ことを観察したことがわかります。
私にとって、それはhard parseが重いリフティングをしていることを示唆しています。それは多くの作業、または多くの待機に遭遇しています。これは調査して調整できます。
統計情報が存在しない可能性があり、オプティマイザはクエリプランを準備する前に統計情報の収集に多くの時間を費やしているのではないかと考えています。それは私がチェックする最初の事柄の1つです。統計は、参照されるすべてのテーブル、インデックス、インデックス付きカラムで収集されます。
クエリが多数のテーブルを結合する場合、CBOは結合順序の膨大な数の置換を検討している可能性があります。
Oracleトレースの説明はこの回答の範囲を超えていますが、次のステップです。
おそらくイベント10053と10046をトレースしたいと思うと思います。
以下は、Tom Kyteによる「イベント10053」ディスカッションへのリンクです。
http://asktom.Oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:63445044804318
接線方向に関連する逸話物語re：ハード解析パフォーマンス
数年前、最初の実行でMINUTESの観点から経過時間を持ち、その後の実行を秒で表したクエリが1つありました。私たちが見つけたのは、最初の実行時間の大半がハード解析に費やされたことです。
この問題クエリは、2つの巨大なレポートビューに無邪気に（単純に？）参加したCrystalReports開発者によって作成されました。
ビューの1つは62個のテーブルの結合であり、他のビューは42個のテーブルの結合でした。
クエリはコストベースのオプティマイザーを使用しました。トレースにより、待機時間ではなく、可能な結合パスの評価に費やされるすべてのCPU時間であることが明らかになりました。
各ベンダーが提供する「レポート」ビューはそれ自体ではそれほど悪くはありませんでしたが、それらの2つが結合されたとき、それは非常に遅くなりました。問題は、オプティマイザーが検討していた膨大な数の結合順列であったと思います。オプティマイザーによって考慮される順列の数を制限するインスタンスパラメーターがありますが、修正はクエリを書き直すことでした。改善されたクエリは、クエリで実際に必要な数十個程度のテーブルのみを結合しました。
（最初の短期的な「バンドエイド」の修正は、レポート生成タスクが実行される前に、早朝にクエリの実行をスケジュールすることでした。それにより、レポート生成の実行はハード解析を回避する、共有プール内の準備済みステートメント。
バンドエイドの修正は実際の解決策ではなく、長い実行時間が気付かなかったときに、問題をクエリの予備実行に移しただけです。
次のステップは、おそらくクエリの「保存されたアウトライン」を実装して、安定したクエリプランを取得することです。
もちろん、文の再利用（ハード解析の回避、バインド変数の使用）は、Oracleの規範的なパターンです。パフォーマンス、スケーラビリティ、yada、yada、yadaを改善します。
この逸話的な事件は、あなたが観察している問題とはまったく異なる場合があります。
HTH
Oracleを使用してからしばらく経ちましたが、実行計画は共有プールにキャッシュされていると思います。これを試して：
alter system flush shared_pool;
バッファキャッシュは、ディスクioを最小化するために、Oracleが最近使用したdataを保存する場所です。
最近、パフォーマンスチューニングクエリで多くの作業を行ってきましたが、クエリパフォーマンスの一貫性の原因の1つは、Oracleが置かれているファイルシステムキャッシュです。
Oracleキャッシュをフラッシュしている間、ファイルシステムにクエリがまだ高速で返されることを意味するように求めているデータが残っている可能性があります。
残念ながら、ファイルシステムキャッシュをクリアする方法がわかりません。非常に役立つシステム管理者の非常に役立つスクリプトを使用しています。