表／索引のメンテナンスとパーティション設計：DB2チューニング・ベストプラクティス（7）（1/2 ページ）
本連載はDB2 UDB V8のシステム管理者、およびアプリケーション開発者のために、パフォーマンス・チューニングに必要な技法を紹介する。記事の原文はIBM developerWorksで2004年4月に公開された「Best practices for tuning DB2 UDB v8.1 and its databases」で、DB2の設計、配置、構成、SQL、運用管理、モニタリングといった内容を、実践的な操作を中心に解説している。想定する読者はDB2データベース管理の中級レベルのスキルを持っているユーザーである。スクリーン・ショットなど一部のコンテンツは、日本語版のものに差し替えている。（編集局）
継続的なメンテナンス
ここでは、データベースの最適なパフォーマンスを維持するために役立つテクニックを紹介します。パーティション・データベースを使用している場合は、コマンドの有効範囲を常に念頭に置いてください。例えばRUNSTATSコマンドは、それ自身が呼び出されたデータベース・パーティション上の表の統計を収集しますが、REORGコマンドは、データベース・パーティション・グループのすべてのパーティションに対して作用します。各コマンドに関するドキュメントの「有効範囲」のセクションを参照してください。
REORGとREORGCHK
REORG（再編成）は、オーバーフロー行を除去し、表や索引の削除行のスペースを再利用するために使用します。これは、大量のDELETE、UPDATE、INSERTを実行した場合に大変役立ちます。また、REORGは（クラスタ索引などのために）表を特定の索引順に並べ替えるためにも使用できます。REORGはオンラインで実行することができ、一時停止することもできます。一方、REORGCHKは、REORGする必要のある表と索引を識別するために使用します。また、データベース内のすべての表に関する統計を収集するためにも使用できます。
統計情報を更新し、表や索引の再編成（REORG）が必要かどうかを識別するには、次のようにします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
現在の統計に基づいて、表や索引の再編成が必要かどうかを識別するには、次のようにします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
再編成が必要と識別された表については、REORGCHKの出力結果のREORG列（F1〜F8）に1つ以上のアスタリスク（*）が表示されます。次に、識別された表に対して実際にREORGを実行します。表を特定の順序に関係なく再編成するには（つまり単純に、疑似削除された行のスペースを再利用し、オーバーフロー行を除去するには）、次のようにします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ある表のすべての索引についてREORGを実行するには、次のようにします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
表を特定の索引順に物理的に並べ替えるには、次のようにします（これはORDER BYやクラスタ索引に適しています）。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
- 参照情報→コマンド→DB2 Universal Database→コマンド行プロセッサー（CLP）→
REORG INDEXES/TABLE - 参照情報→コマンド→DB2 Universal Database→コマンド行プロセッサー（CLP）→
REORGCHK
RUNSTATS
表や索引のREORGが終了したら、オプティマイザが最適なアクセス・プランを作成できるように、表と索引の統計を再収集します。サンプリングを使用したRUNSTATSを実行するか（大規模データベースでのパフォーマンスが向上します）、またはバックグラウンドで実行すると便利です。
表や索引に対して以前にRUNSTATSが実行されたかどうかを確認するには、次のようにします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
システム・カタログ表に対してRUNSTATSを実行することで、システム・カタログ表のパフォーマンスも向上します。
便利なコマンドをいくつか紹介します。
| コマンド | 説明 |
|---|---|
| RUNSTATS ON TABLE schema.table | 特定の表に関する統計を収集します。 |
| RUNSTATS ON TABLE schema.table AND INDEXES ALL | 特定の表とそのすべての索引に関する統計を収集します。 |
| RUNSTATS ON TABLE schema.table AND SAMPLED DETAILED INDEXES ALL | 拡張された索引統計とCPUのサンプリング技法を使用して、特定の表とそのすべての索引に関する統計を収集します。これは、索引が非常に大きく（100万行以上）、RUNSTATSのための時間が制限されている場合に便利です。 |
| RUNSTATS ON TABLE schema.table WITH DISTRIBUTION | 特定の表（およびオプションで特定の列）に関する追加の統計を収集します。これは、データが均一に分散していない場合に役立ちます。 |
| 表1 便利なRUNSTATSコマンド（注：赤字は各自の環境に置き換えてください） | |
また、SELECTステートメントを使用してスクリプトを作成するのも便利な方法です。この場合、次のようなSELECTステートメントを使用して、その結果をファイルにパイピングします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
- 参照情報→コマンド→DB2 Universal Database→コマンド行プロセッサー（CLP）→RUNSTATS
REBIND
REORGとRUNSTATSを実行し終わったら、すべてのデータベース・パッケージを再バインドします。これは、データベース・パッケージの静的SQLで最新のシステム統計を利用できるようにするためです。次のようにDB2RBINDを使用して、すべてのデータベース・パッケージを再バインドします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
REBINDコマンドを使用すると、単一のパッケージを再バインドできます。
- 参照情報→コマンド→DB2 Universal Database→システム・コマンド→db2rbind
- 参照情報→コマンド→DB2 Universal Database→コマンド行プロセッサー（CLP）→REBIND
（次ページに続く）
Copyright © ITmedia, Inc. All Rights Reserved.