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