どのように私はベンチマークのためのOracleの実行計画キャッシュをクリアするのですか？

Question

oracle 10gr2には、パフォーマンスを比較しているいくつかのSQL問合せがありますが、最初の実行後にv $ sql表にキャッシュ用に格納された実行計画があるため、問合せのうち最初の実行から28秒.5秒後。

私は試しました

ALTER SYSTEM FLUSH BUFFER_CACHE; - これを実行した後、クエリは5秒で一貫して実行されますが、これは正確ではないと思います。

v $ sqlのwhere sql_textは 'select * from ....'のように削除されますが、ビューから削除できないというエラーが表示されることがあります。

Answer 1

私はOracleと仕事をしてからしばらくしていますが、実行計画は共有プールにキャッシュされていると思います。 Oracleの店は最近、ディスクIOを最小限にするために、データを使用した場合、バッファ・キャッシュがある

alter system flush shared_pool; 

：これを試してみてください。

Answer 2

ピーターはあなたに質問した質問に対する答えを教えてくれました。

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を始めました。大きなテーブルに対してこのクエリを実行しました。 Iバッファキャッシュを「フラッシュ」と再びそれを実行します。

< /抜粋>

を私はトム・カイトが正確に正しいと思います。パフォーマンスの問題に対処するために、私は「Oracleの実行計画キャッシュをクリアする」ことは、通常、信頼できるベンチマークのためのステップだとは思わない。

パフォーマンスに関する懸念に対処しましょう。

フラッシング（すべてのインデックスとデータブロックから）が実行されても、クエリの最初の実行にはその後の実行（〜5秒）に比べてかなり長い時間（〜28秒）バッファキャッシュ。

私には、ハードパースが多少重労働していることが示唆されています。それはたくさんの仕事か、多くの待っていることです。これは調査し調整することができます。

統計情報が存在しない可能性があり、オプティマイザがクエリプランを作成する前に統計収集に多くの時間を費やしているのだろうかと思います。これは、最初にチェックするものの1つで、参照されているすべてのテーブル、インデックス、およびインデックス付きカラムで統計が収集されます。

クエリが多数のテーブルに参加する場合、CBOは結合順序の膨大な数の並べ替えを検討している可能性があります。

Oracleトレースの説明は、この回答の対象外ですが、次のステップです。

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:63445044804318

：

私はあなたがおそらく10053ここで

10046.はあなたが役に立つかもしれトム・カイトによる「イベント10053」の議論へのリンクのイベントをトレースしたいしようとしていると思っています

---

接線方向に関連した逸話ストーリー再：ハード解析性能

数年前に、私は最初の実行時にMINUTESという言葉で経過時間があった1つのクエリを見ました。その後の実行は秒単位でした。私たちが見つけたのは、最初の実行時間の大部分がハード解析に費やされたということでした。

この問題のクエリは、CrystalReportsの開発者によって作成されました。この開発者は、2つの巨大なレポートビューに無邪気に（素朴に）参加しました。

ビューの1つは62テーブルの結合で、もう1つのビューは42テーブルの結合でした。

クエリはコストベースオプティマイザを使用しました。トレースすると、待機時間ではなく、すべてのCPU時間が可能な結合パスを評価するのに費やされました。

ベンダーが提供するそれぞれの「レポート」ビューはそれ自体悪くはありませんでしたが、2人が参加したときには辛抱強く遅かったです。問題は、オプティマイザが検討していた膨大な数の結合パーミュテーションであったと思います。オプティマイザによって考慮される置換の数を制限するインスタンス・パラメータがありますが、我々の修正はクエリを書き直すことでした。改善されたクエリは、クエリによって実際に必要とされたダースなどのテーブルにのみ参加しました。

（初期の短期的な「バンド支援」修正は、レポート作成タスクが実行される前に朝早くクエリの実行をスケジュールすることでした。

バンドアシストフィックスは実際の解決策ではなく、長い実行時間がなかったときに問題を仮実行に移したばかりです。

私たちの次のステップは、おそらく、クエリ用の「格納されたアウトライン」を実装して、安定したクエリプランを得ることでした。

もちろん、ステートメントの再利用（バインド変数を使用したハード解析を避ける）はOracleの規範的パターンです。パフォーマンス、スケーラビリティ、yada、yada、yadaを向上させます。

この事例は、観察している問題とはまったく異なる場合があります。

---

HTH

Answer 3

我々はパフォーマンスチューニングクエリで最近多くの作業を行ってきた、と一貫性のないクエリのパフォーマンスのための1つの犯人は、Oracleが上に座っているファイルシステムキャッシュです。

それは、Oracleのキャッシュをフラッシュしている間、ファイルシステムがまだあなたのクエリは、クエリがまだ速く返すことを意味するために求めているデータを持っている可能性があります。

残念ながら私はファイルシステムのキャッシュをクリアする方法がわかりません。とても役に立つシステム管理者のスクリプトを使用しています。