共有メモリということは、
変更したパラメータは「SGA_TARGET」？
それとも個々のパラメータ（shared_pool_size、db_cache_size）？
このあたりは、リソースのチューニングの問題になってきます。
SGA（共有メモリ）は各セッション共有の用途で使用されるもの、
例えば、ディスクから読み出したデータだったり、すでに誰かが
実行済みで、解析済みのSQLだったり、ディクショナリーだったり、
そういった共有用途で使用される領域で、DB起動時に、
物理メモリー、仮想メモリーから事前に決めたサイズを割り当てて、
OracleDBの共有用途専用として確保する領域です。
もし、SGA_TARGETを広げて、全体のパフォーマンスが遅くなったのだとしたら、
物理メモリでは不足し、スワップ（ディスクの仮想メモリ）を使用している
可能性があります。当然、物理メモリとディスクで代用した仮想メモリでは、
処理スピードは段違いです。
個々のパラメータを変更して遅くなったと感じた場合は、
たとえば、バッファキャッシュを大きくするため、最低値として、
「db_cache_size」の値をかなり大きくし、SGA_TARGETにかなり近い値に
したとすると、SGAでは他の用途、共有プールだったり、redoバッファだったり、
いろいろな用途でのも使用していますから、他の用途用のメモリが
不足し、パフォーマンスが遅延する可能性があります。
また、個々に値を設定した状態で、自動メモリ管理(10g)を使用している場合には、
通常の用途よりも1ステップ作業が増えるので、何か不具合に該当することが
あるかもしれません。
ま、不具合であったら、サポートに確認しましょう。
処理全体が遅いのか、特定の処理が遅いのか、
遅くなった時期は毎回遅いのか、ある時だけ遅く感じたのか
問題切り分けをしましょう。
処理する対象のデータが増えれば、処理が遅くなるのは当然ですし、
索引などのメンテナンスなどがきちんとされていなければ、
ある日突然、実行計画が変わって遅くなることだってあります。
DBのパフォーマンスがあがり、処理可能量が増加し、
いままで発生しなかったような遅延が発生しているかもしれません。
また、DB上の処理の問題ではなく、APServerやNetworkの問題だったり、
H/W上の問題だったりするかもしれません。
こういった問題を切り分けするために、StatsPackやDiagnosticsPack
といったツールがあり、OS上のパフォーマンス情報を収集しておくと
いったことも、ある日突然パフォーマンスダウンといった場合に有効です。
まずは、何事も問題切り分けからです。
もし、難しそうであるなら、サポートの指示を仰ぐのも一つの手です。
バッファキャッシュは物理メモリのサイズなどの条件などを全く考えないなら、
大きければ、大きいほどよいです。
ただし、32bit版だとSGAのメモリ上限は通常、2GBまでです。
このあたりは、「32bit Oracle メモリ上限」とかでgoogleで
調べれば情報はあるはずです。
Oracleでは、データのやりとりは、ディスクと直接行うのではなく、
ディスク内から、必要なデータの入っているブロックを、
メモリ上に確保したSGAの中のバッファキャッシュ用の領域に読み込み、
その読み込んだデータを元に、SQLPLUSなどのユーザープロセスに対し
結果を返しています。
つまり、バッファキャッシュとは、
ディスクの中から、SQLが処理に必要なデータをためておくための領域のことになります。
お礼
ありがとうございます！参考にさせていただきます