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

ステップ2以下の調査を実施するための、前提条件を次に示します。

		調査2.3でエラーが出ていないことを確認した。または、エラーが出ていて対策2.3で対処したが、状況が改善されなかった。
		調査2.4で特に資源問題がないことを確認した。
		比較対象として、同じloadコマンドでかつ同じデータを用いた比較調査資料が準備できる。たとえば、新しいFixPakを当てたら遅くなった場合には（Badケースと呼びます）、元の状態（Goodケースと呼びます）での調査データを入手でき、それとの比較で議論できる。

OSをバージョンアップしたか、リリースアップした直後から、パフォーマンス問題が発生した場合には、DB2も最新のFixPakをあてて様子をみます。

loadユーティリティー固有の確認項目を、GoodケースおよびBadケースのそれぞれについて調査します。

調査項目 該当する場合の対策 3.1 本当に、ロードが性能劣化しているのか、DB2コマンド行プロセッサー（CLP）を立ち上げ、確認してみます。 db2 => list history load all for db_name で、過去のloadと現在のload時間を比較することが可能です。 本当にロードが性能劣化の原因であると判断できた場合は、調査を継続します。そうでない場合は、別の切り口からの調査に切り替えます。 3.2 ロードのいずれのフェーズが遅いと考えられますか？ ロードには、ロード?構築?削除?索引コピーの4つのフェーズがあります。フェーズ毎の実行時間の確認は、ロード実行時のメッセージを参照で可能です。 劣化の原因として、良くあるものを列挙しますので、参考にして調査し、原因を発見した場合は対策をとります。   ロード・フェーズの劣化：入力ファイルの配置の変更、ファイル・システムのI/O競合等OSレベルの問題、一時表スペースに関連する構成変更     構築フェーズの劣化：索引の追加、単純なデータ量増大（索引作成時間はデータ量の増加分より大きく増えます。）     削除フェーズの劣化：アプリケーション的な要因による重複データの増加     索引コピー：フェーズ：ロード・フェーズと同じ   3.3 ロード固有のチューニングは何か行いましたか？ ロードのチューニング方法については、「最新データベース・パフォーマンスチューニング」のp.10「ユーティリティ・チューニング（load)」が参考になります。 「最新データベース・パフォーマンスチューニング」 （313KB） Adobe® Reader®が必要 3.4 loadコマンド実行時に他にどのようなアプリケーション（DB2、その他も含む）が並列処理されていましたか？ 並行処理されるアプリケーションが、いつもと異なっている、あるいはデータ量が異なっている場合には、「資源不足発生」の観点から、調査3.1 ステップ5?7をもう一度念入りに調査してみます。 3.5 loadコマンドは複数並列実行していますか？ そうである場合は、その順番も確認の必要があります。 並列度やバッファ・サイズの明示的な指定が無い場合、loadコマンドが複数並列実行されていると、最初のロードで資源を使い過ぎて、2番目以降が遅くなることがあります。 loadコマンドの並列度、バッファ・サイズの指定と、ロードの順番を確認してください。 もし可能であれば、loadコマンドのオプションで適切な並列度とバッファ・サイズを指定してください。それがだめなら、大きいロードを先に実行することで多少影響を小さくできます。

次の順で資料を収集します。

		パフォーマンス問題・資料収集の注意点および準備
		パフォーマンス問題・共通詳細情報の取得
		UNIX系OS/Linuxの場合は、load実行時モニター情報取得：UNIX系OS,Linux
		Windows系OSの場合は、load実行時モニター情報取得：Windows系OS
		パフォーマンス問題・情報送付手順