パフォーマンス問題の、DB2 UDB調査・対策チェックリスト （対策2.9）

【点検項目】
実行回数の多いSQL文

		特定のSQL文の実行回数が多い場合には、それをチューニングすることにより問題が解決する場合があります。

【点検方法】

		実行回数の多いSQL文を特定するには、データベースsnapshotモニターを使用し、「動的SQLスナップショット結果」報告から、モニター出力中の「実行数」に注目します。 snapshotモニターの詳細については＠ITを参照
		チューニング作業にはexplainやdb2batchが役に立ちます。 具体的なチューニング法については、DB2パフォーマンス・チューニング・ガイド、白井徹哉他著を参照。（V7.1対応の記述ですが、おおむねV8でも適用可能です）

【点検項目】
過度なSQL文のコンパイル

		非常に単純なSQLに、アプリケーションがパラメーター・マーカーが使用されておらず過度のSQL文のコンパイルが発生している場合には、それをチューニングすることにより問題が解決する場合があります。

【点検方法】

		過度なSQL文のコンパイルを特定するには、データベースsnapshotモニターを使用し、「アプリケーション・スナップショット」報告から、「パッケージ・キャッシュ挿入」数をチェックします。　この値が急激に増えている場合、非常に単純なSQLにアプリケーションがパラメーター・マーカーを使用していないかどうか点検してみます。 snapshotモニターの詳細については＠ITを参照 スナップショット報告では、パッケージインサートは、次の例のように出力されます。 パッケージ・キャッシュ検索 パッケージ・キャッシュ挿入 パッケージ・キャッシュ・オーバーフロー = 23456 = 23398 = 0
		過度なSQL文のコンパイルが発見された場合には、アプリケーション担当者に「パラメーター・マーカーを使うようにアプリケーションを直すことを検討して欲しい」と伝えます。 具体的なコーディング方法については、Javaでの例ですが「JDBC接続を高速化する? PreparedStatementキャッシュの威力?」が参考になります。

【点検項目】
不要なデータベース接続・切断

		アプリケーションが不要なデータベース接続・切断を繰り返している場合には、それをチューニングすることにより問題が解決する場合があります。

【点検方法】

		不要なデータベース接続・切断を特定するには、データベースsnapshotモニターを使用し、「データベース・スナップショット」報告から「アプリケーション接続」数をチェックします。　この値が急激に増えている場合、アプリケーションが不要なデータベース接続・切断を繰り返していないかどうか点検してみます。 snapshotモニターの詳細については＠ITを参照 下の表のように、「アプリケーション接続」はデータベースがアクティベートされた後の接続の累積回数で、「現在のアプリケーション接続」は現在接続しているアプリケーションの数となっています。毎回接続、切断するアプリケーションは「アプリケーション接続」の値が爆発的に増えていきます。 　 接続 切断 接続 切断 接続 ・・・ 接続用最高水準点 1 1 1 1 1 ・・・ アプリケーションの接続 1 1 2 2 3 ・・・ 現在のアプリケーション接続 1 0 1 0 1 ・・・ スナップショット報告では、アプリケーション接続は、次の例のように出力されます。 接続用最高水準点 アプリケーション接続 2 次接続合計 現在のアプリケーション接続 = 25 = 123456 = 0 = 23

		不要なデータベース接続・切断が発見された場合には、アプリケーション担当者やデータベースに接続しているWebSphereの管理担当者に「接続回数が多すぎるのでJ2EEの接続プールなどを使って減らすことは出来ないか？」と伝えます。 具体的なチューニングについては、これもJavaになりますが「JDBCコネクションプールに関するチューニングポイント」が参考になります。

切り分けが必要です。　ロジックごとにtimeを出力するなど、アプリケーションのデバッグなどを行い、いずれのSQL文、またはDB2コマンドが劣化の原因となっているかを判断します。