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

runstatsを実施し、続いてbindを実施します。

		runstats SQLへの最適アクセス・パスを選択する（オプティマイズと呼びます）ために必要な、最新の統計情報を取得し、システムカタログに反映させます。 注：一部の例外を除いて、分散統計オプション（with distribution）を使用して、runstatsを実行します。
		bind 統計情報を反映したアクセス・パスをデータベースに保管します。過去に確実にBINDを実施した保証があればrebindでかまいません。

reorgの必要性をreorgchkにて調査し、必要な場合には、reorg、runstats、rebindの順に実施します。

		reorgchk データベースの物理的な再編成が必要かどうか、診断します。診断の見方がわからないときは、スキップしても構いませんが、一般にレコード件数が多い場合にはreorgには長時間必要ですので、注意が必要です。 お役立ちヒント：診断の見方は、 @IT Webサイト「DB2マイスター養成講座」第6回 データベースの状態監視とメンテナンス「データのフラグメンテーションチェック」の節 がわかりやすいです。
		reorg データベースを物理的に再編成し、性能向上を図ります。このときに、削除レコードを物理的に解放しますので、フリースペースが増加する効果もあります。
		runstats SQLへの最適アクセス・パスを選択する（オプティマイズと呼びます）ために必要な、最新の統計情報を取得し、システムカタログに反映させます。 注：一部の例外を除いて、分散統計オプション（with distribution）を使用して、runstatsを実行します。
		rebind 過去にbindされたアクセス・パスを更新します。bindよりも高速です。

runstats、bindの動作概要について知りたい場合には、「アクセスパスの選択におけるホストのDB2と ワークステーションのUDBとの違いについて」が参考になります。

問題判別の各種「DB2 UDB サポートハンドブック」 1章4-4, 4-6, 4-7, 4-8節に、それぞれreorg、runstats、bind、rebindコマンドの動作について解説されています。V8.1対応版として（AIXR、WindowsR版）が、V7.2対応版として（AIX、SolarisR版）が用意されています。