Windows上のWebSphere 6.1を使用して、別のWindowsマシン上のDB2データベースに接続しています。私たちはアプリケーションで準備文を使用しています。データベースインデックスを調整する際（インデックスの最後に列を追加する）、実際にデータベースサーバー上のプロセッサが固定されているインデックスを変更した後、同じクエリを使用したテストデータベースでパフォーマンスが向上することはありません。JNDIキャッシュには何が格納されていますか？
準備された文クエリプランは実際にJNDIに格納されていますか？もしそうなら、どうやってクリアすることができますか？そうでない場合、DB2サーバー上のキャッシュをクリアするにはどうすればよいですか？
クエリプランはRDBMS自体によってデータベース内に「通常」保持されていますが、正確なライフサイクルはベンダーによって異なります。彼らは間違いなくJNDIレジストリに保持されていません。
両方のデータベースに同じ量のデータがあるとしますか？
両方のデータベースのEXPLAIN PLANを見て、それらが一致していることを確認しましたか？これらの両方の質問への答えがある場合
はい私はアイデアの出だし、それは、データベース・サーバを再起動する時間です。
プリペアド・ステートメントの実行計画は、DB2パッケージ・キャッシュに保管されます。索引が追加された後、パッケージ・キャッシュは依然として最適ではない古いアクセス・プランを保持している可能性があります。
索引を追加した後、適切なアクセス計画を選択するために必要な情報をDB2オプティマイザーに提供するために、少なくとも索引でRUNSTATSステートメントを出すことが必要です。
新しい索引のRUNSTATS統計が存在したら、FLUSH PACKAGE CACHEステートメントを発行して、影響を受ける表に関係するすべてのアクセス・プランを解放します。これの欠点は、他の動的SQLステートメントのアクセス・プランも取り出され、それぞれの個別のSQLステートメントが最適化されてキャッシュされるため、オプティマイザーの使用が一時的に増加することです。
は、WebSphereでの接続プールの設定で、ステートメント・キャッシュのサイズを制御することができます。 jdbcドライバ自体は、プリペアドステートメントキャッシングもサポートしています。 – Ron