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

調査2を実施してみて、Goodケースに比較して、Badケースは業務に支障をきたさない程度に改善しましたか？

発生し始めたのはいつからか、正確な日時をお答えください。

		今日突然ですか？
		FixPakを適用後ですか？
		それとも？

その時、その前に何をしたら問題が発生しはじめたか（トリガー）とお考えのものを教えてください。トリガーの例として良くあるものから列挙しますので、答えるときの参考にしてください。また、各トリガーごとに実施すべき対策を示している場合は、コール前に試みてください。

対策2.1でreorg, runstats, bindを実行してみた結果はどうでしょうか？rebindを実行しているがbindはしていない場合は、bindの実行をしてみます。

調査2.7でネットワーク問題でないと判明している場合は、DBサーバー側の資源枯渇が性能劣化の原因ではないか、調査します。

		DBサーバー内で他のプロセス（たとえばWAS、MQ、ERPソフトや業務アプリケーション）が動いていませんか？そうであれば、それらの影響による資源枯渇が考えられます。
		OSコマンドを用いて下の表のような資源状況を調査して、状況をお知らせください。いずれかの調査項目に該当した場合には、それへの対策もとって、その結果の様子もお知らせください。

PDFファイルを見るにはAdobe® Reader®が必要です。
	Adobe Reader

調査項目 該当する場合の対策 5.1 問題発生時には、DBサーバーのCPU使用率が常時90%を超えていませんか？ 80%以内になるように、チューニングします。チューニング方法については、「最新データベース・パフォーマンスチューニング」のp.4「チューニング・ステップ1（CPU）」が参考になります。 「最新データベース・パフォーマンスチューニング」 （313KB） 5.2 問題発生時には、メモリー使用率が常時80%を超えていませんか？ 50%以内になるように、チューニングします。チューニング方法については、「最新データベース・パフォーマンスチューニング」のp.5「チューニング・ステップ2（メモリー）」が参考になります。 「最新データベース・パフォーマンスチューニング」 （313KB） 5.3 問題発生時には、ページング・スペースのページングが、BadケースはGoodケースに比較して多発していませんか？ ページングが頻発しないように、チューニングします。チューニング方法については、「最新データベース・パフォーマンスチューニング」のp.5「チューニング・ステップ2（メモリー）」が参考になります。 「最新データベース・パフォーマンスチューニング」 （313KB） 5.4 問題発生時には、ディスクI/O WAITがBadケースはGoodケースに比べ、増加していませんか？ 一般に、I/O WAITが20?25%以上の場合は、ディスク・ボトルネックを調査することになります。 Goodケースと同等になるように、チューニングします。チューニング方法については、「最新データベース・パフォーマンスチューニング」のp.6「チューニング・ステップ3（DISK）」が参考になります。 「最新データベース・パフォーマンスチューニング」 （313KB）

ユニークな環境で発生するのか、それとも問題のシステム環境全体で発生するのかを調査してみた結果はいかがですか？ また。調査項目によっては、アクションが指示されていますが、その結果はいかがですか？

スナップショットを用いて、サーバー内のどのプロセス（OS、DB2、ミドルウェア、アプリケーションなど）がボトルネックかを切り分けてて見た結果は、どんな感じでしょうか？

お役立ちヒント：ツールの使用法および、解釈の仕方は、「システム・リソースの使用量に関連するDB2スナップショット要素」の節をご参照ください。

下の調査を行い、結果の様子をコール時にご報告ください。

GoodケースとBadケースはともにシナリオとして存在し、かつ再現性はありますか？ 明確なシナリオが存在し、かつ再現性があることが、開発部門での調査の条件となります。