web-dev-qa-db-ja.com

DB2でREORGを実行した後、RUNSTATSを実行する必要がありますか？

REORGのドキュメント のコメント：

[〜＃〜]ビルド[〜＃〜]

Builds indexes. Updates index statistics.

しかし、私は常にREORG/RUNSTATSをペアリングする必要があるかのように聞いています。 「インデックス統計の更新」がRUNSTATSと同じことを達成することを誰かが確認できますか？

db2maintenancedb2-luw
4
Lucas

REORGは、DB2が正確なデータをポイントするのに役立ちます（つまり、インデックスは新しいデータを認識し、削除されたデータを含まないようにする必要があります）。インデックス。また、より効率的なアクセスのために、相互に関連するデータを移動するのにも役立ちます（特にクラスターインデックスの場合に当てはまります）。

RUNSTATSは、テーブルおよびインデックス内のデータのボリュームや分布に関する更新された統計を収集するために使用されます。この情報はシステムテーブルに格納され、オプティマイザなど、データをクエリするための最適なパスを決定するために使用されます。これは、データが増えるにつれて特に当てはまります。データは、オプティマイザがアクセスパスに以前にはなかったインデックスを含めるように分散する可能性があります（またはその逆で、インデックスを使用しないことを選択します）。 RUNSTATSは、REORGの実行方法にも影響を与える可能性があります-少なくとも古いバージョンのDB2では。

私がDB2 DBAから読んだ内容に基づいて、一般的に実行したい

  1. RUNSTATS
  2. REORG
  3. RUNSTATS

最初のRUNSTATSは、REORGが適切かつ効率的に機能するのに役立ちます。 RUNSTATSの後は、ページ上のすべてのデータ移動を考慮して、統計が正確であることを確認するためのものです。読む場所によっては、DB2の新しいバージョンでは、最後のRUNSTATSは不要であるとDBAが言及している場合があります。これに関する明確な回答は見当たらず、ほとんどのDB2 DBAは上記の順序に従うと聞いたので、当社はその順序を使用することを選択しました（レコードの場合、DB2 LUW 9.7 FP4にあり、移行する予定です。 V 10.1来年いつか）。

また、完全を期すために、一般に統計を更新し、オプティマイザーに影響を与える場合は、DB2を呼び出すすべてのアプリケーションがそれらの新しい最適化を確実に活用できるようにする必要があります。そのため、パッケージのREBINDは、静的パッケージが更新された統計と最適化されたクエリパスを知っていることを確認し、FLUSH PACKAGE CACHE DYNAMICは、Hibernateなどから動的クエリを削除して、更新されたクエリパスでクエリが再バインドされるようにします。 （[〜＃〜] note [〜＃〜]：z/OSでは、BINDおよびREBINDオプションがあるようです。おそらくFLUSH PACKAGE CACHE DYNAMICはそれらの下にあるか、zで別の名前になっています。）

したがって、最終的には次のようにします。

  1. RUNSTATS
  2. REORG
  3. RUNSTATS
  4. REBINDパッケージ
  5. FLUSH PACKAGE CACHE DYNAMIC（LUW上）またはz/OS上の同等のもの。
4
Chris Aldrich

IBM iでDB2を実行している場合は、そのすべてが処理されます。インデックスはリアルタイムで維持されます。統計は自動的に更新されます。プランは動的に最適化されます。

1
WarrenT