Oracleバッファキャッシュの増加が遅くなる
そこで、Oracle 11gR2のバッファキャッシュを増やすことを検討しています。彼らは過去にそれを試みた、そして物事は悪化するように見えたので、彼らは変更を元に戻したと彼らは言った。しかし、彼らはなぜ事態が悪化したのか理解していません。
可能性としては、それらがプリエンプティブであり、サーバーの完全な再起動であることを考慮して時間が与えられなかっただけですが、キャッシュを増やすと結果が悪化する状況は何ですか？私は このページ（状況B） を見てきましたが、それを主張している人を見つけることができません。実行する必要のあるクエリの種類を考えると、「通常」よりも確実に分散読み取りを行っています。
どのシステムでも、システムのボトルネックにならない部分をより効率的にすると、システム全体の効率が低下する可能性があります。たとえば、システムのボトルネックがCPUである場合、バッファキャッシュのサイズを大きくしてI/Oをより効率的にすると、CPUで待機するスレッドが多くなり、システム全体が次のように遅くなる可能性があります。オペレーティングシステムは、競合するスレッド間でスワッピングに多くの時間を費やしており、CPUキャッシュが圧倒され、「ニー」に到達すると、もう少し負荷を増やすと、応答時間の古典的なホッケースティックグラフが表示されます。システムの応答時間。
I/O要求の相関性が非常に低いシステムの場合、キャッシュのサイズを大きくすると、Oracleは特定のブロックのキャッシュを調べるのに多くの時間を費やす前に、物理的な読み取りを強制される可能性があります。 OLTPアプリケーションでは、これは比較的ありそうにありませんが、他のレポートでは再利用したくないブロックをさまざまなレポートが要求しているデータウェアハウジングタイプシステムでは可能です。
もちろん、これが実際に彼らが過去に遭遇した問題であるかどうかはまだ未解決の問題です。ウォームアップが必要なコールドキャッシュの問題か、誰かが以前のテストまたは不適切に構築されたテスト（たとえば、誰かが誤ってサイズを増やした）から誤った結論を出したという認識の問題であった可能性がありますオペレーティングシステムのI/Oキャッシュを犠牲にするのではなく、PGAを犠牲にしてバッファキャッシュを使用します。いくつかのニースAWRレポートで裏付けられていない過去の人間の記憶に対するあなたの不信を共有する傾向があるので、上記の説明のいずれかが、人間の記憶が正しければ潜在的な説明であるだけだとは主張していません。
私が考えることができる唯一の理由は、システムが物理メモリの限界にあり、少しの仮想メモリ（Windowsではページングファイル）を使用していたことです。 Oracleにメモリを追加すると、そのバッファの多くが物理メモリからプッシュされ、ページングが原因で応答時間が大幅に増加します。
Oracleデータベースのホストで多くのページングが行われているのは、NO NOです。 Windowsはこれに悪影響を与える可能性がありますが、独自の「並列」大容量ファイルシステムキャッシュを備えているUnix/Linuxも同様です。システムが、二重キャッシング効果を伴うクロールまで遅くなるのを見てきました。