バッファの意味についてお聞きしたいです。バッファ取得の削減により、必要な I/O が削減されたと推測できますが、実行時間にも関係があると言えますか? ほとんどの場合、バッファ取得を減らすと実行時間の短縮に影響することがわかりましたが、いくつかのケースでは、バッファ取得が増えても実行時間も短縮されることが示されました。それは可能ですか?前もって感謝します!
PS:私はOracle 11g RDBMSを使用しています
バッファの意味についてお聞きしたいです。バッファ取得の削減により、必要な I/O が削減されたと推測できますが、実行時間にも関係があると言えますか? ほとんどの場合、バッファ取得を減らすと実行時間の短縮に影響することがわかりましたが、いくつかのケースでは、バッファ取得が増えても実行時間も短縮されることが示されました。それは可能ですか?前もって感謝します!
PS:私はOracle 11g RDBMSを使用しています
バッファーの削減は一般に取得されますが、常に高速な実行時間と相関するとは限りません。確かに相関関係はありますが、相関関係は完全ではありません。
バッファ取得にかかる時間は、データベースが単純に SGA キャッシュからブロックをプルできるかどうか、ファイル システム キャッシュから読み取ることができるかどうか、SAN キャッシュから読み取ることができるかどうか、または実際にブロックを読み取れるかどうかによって、大きく異なります。物理的な読み取りが必要です。また、物理的な読み取りに必要な時間は、SAN の構造と、異なるブロックを高速または低速のディスクに格納するかどうかに大きく依存します。多くの最新の SAN では、最も頻繁に読み取られるブロック用に少量のソリッド ステート ディスク、一般的に読み取られるブロック用に高速なハード ドライブ、あまり頻繁に読み取られないブロック用に低速のハード ドライブがそれぞれ独自のパフォーマンス特性を持つ場合があります。
クエリが実行する論理 I/O の量を減らすことは十分に可能ですが、キャッシュされる可能性が高くなるように I/O の性質を変更できます。たとえば、常にインデックス スキャンを実行しているネストされたループがある場合、インデックスの大部分が比較的迅速に SGA にキャッシュされる可能性が高くなります。つまり、論理 I/O のほとんどは、そのインデックスに対する do は、SGA からブロックを取得するだけでよい比較的高速なバッファ取得によって満たされることになります。たとえば、完全なテーブル スキャンを実行する代替プランでは、論理 I/O が少なくなる可能性がありますが、キャッシュされるテーブルのブロックは比較的少ないため、その I/O のほとんどは物理読み取りを必要とする可能性があります。この種の状況では、
ただし、実際には、物理的な読み取りが必要になる可能性が高いバッファー取得と、一般的にキャッシュから処理されるバッファー取得を人間が正確に予測できることは比較的まれです。非実稼働環境では、実稼働環境と同じ種類のワークロードを実行していないため、ほとんどの場合、実稼働環境と同じパターンのキャッシュ使用率はありません。実稼働システムでも、キャッシュされるブロックのセットは 1 日の間に大きく変化し、人間の開発者がそれらの変化を知ったり理解したりする理由はほとんどありません。したがって、クエリをテストしているときに、同等のクエリよりも多くのバッファ取得を行い、実行速度が速いことがわかったからといって、本番環境で同様のパターンが見られるとは限りません。
さらに、クエリは I/O 以外にも待機します。クエリは CPU で待機し、ネットワーク イベントで待機し、ロックとラッチ、およびその他のシリアル化デバイスで待機します。バッファは I/O だけを測定し、他のタイプの待機を考慮しようとしません。そのため、1 つのプランが実行する I/O は大幅に減るが、CPU、ネットワーク、RAC キャッシュ フュージョン、またはその他のイベントで待機する時間が大幅に長くなり、I/O の待機時間が大幅に短縮されるにもかかわらず、実行時間が大幅に長くなるという状況も発生する可能性があります。