連載
» 2005年01月07日 00時00分 UPDATE

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データベース管理の中級レベルのスキルを持っているユーザーである。スクリーン・ショットなど一部のコンテンツは、日本語版のものに差し替えている。(編集局)

[Fraser McArthur,DB2 Enablement Consultant/IBM Canada Ltd.]

継続的なメンテナンス

developerworks

本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。


 ここでは、データベースの最適なパフォーマンスを維持するために役立つテクニックを紹介します。パーティション・データベースを使用している場合は、コマンドの有効範囲を常に念頭に置いてください。例えばRUNSTATSコマンドは、それ自身が呼び出されたデータベース・パーティション上の表の統計を収集しますが、REORGコマンドは、データベース・パーティション・グループのすべてのパーティションに対して作用します。各コマンドに関するドキュメントの「有効範囲」のセクションを参照してください。

REORGとREORGCHK

 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
(注:赤字は各自の環境に置き換えてください)

  • 参照情報→コマンド→DB2 Universal Database→コマンド行プロセッサー(CLP)→
    REORG INDEXES/TABLE


  • 参照情報→コマンド→DB2 Universal Database→コマンド行プロセッサー(CLP)→
    REORGCHK

RUNSTATS

 表や索引のREORGが終了したら、オプティマイザが最適なアクセス・プランを作成できるように、表と索引の統計を再収集します。サンプリングを使用したRUNSTATSを実行するか(大規模データベースでのパフォーマンスが向上します)、またはバックグラウンドで実行すると便利です。

 表や索引に対して以前にRUNSTATSが実行されたかどうかを確認するには、次のようにします。

SELECT char(tabname, 40)
FROM syscat.tables
WHERE type = 'T'
AND stats_time is null

SELECT char(indname, 40)
FROM syscat.indexes
WHERE stats_time is null

-- あるいは、次のようにしてRUNSTATSの実行時刻をリストします
-- (古いものから順に)

SELECT char(tabname, 40), stats_time
FROM syscat.tables
WHERE type = 'T'
ORDER BY stats_time
リスト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) || '.' 
       || char(tabname,40) || 
       ' AND DETAILED INDEXES ALL;' 
FROM syscat.tables 
WHERE type = 'T' 
ORDER BY tabschema, tabname;
リスト2 RUNSTATS CLPスクリプトの生成

  • 参照情報→コマンド→DB2 Universal Database→コマンド行プロセッサー(CLP)→RUNSTATS

REBIND

 REORGとRUNSTATSを実行し終わったら、すべてのデータベース・パッケージを再バインドします。これは、データベース・パッケージの静的SQLで最新のシステム統計を利用できるようにするためです。次のようにDB2RBINDを使用して、すべてのデータベース・パッケージを再バインドします。

db2rbind dbname -l logfile.out ALL
(注:赤字は各自の環境に置き換えてください)

 REBINDコマンドを使用すると、単一のパッケージを再バインドできます。

  • 参照情報→コマンド→DB2 Universal Database→システム・コマンド→db2rbind

  • 参照情報→コマンド→DB2 Universal Database→コマンド行プロセッサー(CLP)→REBIND

次ページに続く)

       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

Focus

- PR -

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。