Db2のREORGとRUNSTATSとは？パフォーマンス維持の基本運用を解説

はじめに

Db2を運用していると、最初は問題なく動いていたSQLが、徐々に遅くなることがあります。

これはアプリケーションの問題ではなく、データの状態や統計情報が変化することが原因であるケースも多くあります。

こうしたパフォーマンス低下を防ぐために重要なのが、「REORG」と「RUNSTATS」です。

本記事では、Db2におけるREORGとRUNSTATSの役割と、実務での基本的な使い方を初心者向けに解説します。

Db2のパフォーマンスを維持するためには、以下の2つを組み合わせて実行します。

・RUNSTATS：統計情報を更新する
・REORG：データの並びを整理する

どちらか一方では不十分であり、「統計情報」と「データ配置」の両方を最適化することが重要です。

まずは、それぞれの役割を整理します。

処理	役割	主な効果
RUNSTATS	統計情報の更新	実行計画の精度向上
REORG	データの再配置	I/O効率の改善

RUNSTATSは「どのようにデータが分布しているか」をSQL Serverに伝える役割があり、REORGは「データの並び自体」を最適化する役割があります。

例えば、データ量が増えているのに統計情報が更新されていない場合、実際とは異なる前提で実行計画が選択されてしまいます。

また、更新や削除を繰り返すことでデータの並びが崩れると、読み取り効率が悪化し、パフォーマンス低下につながります。

このように、両者は役割が異なるため、どちらか一方だけでは十分ではありません。

実務では、以下の流れで運用するのが基本です。

① RUNSTATSを実行して統計情報を更新する
② REORGが必要か確認する（REORGCHK）
③ 必要なテーブルに対してREORGを実行する
④ REORG後に再度RUNSTATSを実行する

この流れにより、「統計情報」と「データ配置」の両方を適切な状態に保つことができます。

特に重要なのは、REORG後にRUNSTATSを再実行する点です。
REORGによってデータ配置が変わるため、その状態を統計情報として反映する必要があります。

ここまでで基本的な考え方は理解できますが、実際の運用ではもう少し踏み込んだ判断が必要になります。

例えば以下のようなポイントです。

・どのタイミングでRUNSTATSを実行すべきか
・REORGを実施すべきテーブルの判断基準
・REORGCHKの結果の見方
・負荷を考慮した実行方法

これらについては、IBMの公式資料で非常に詳しく解説されています。

本記事で全体像を押さえたうえで、必要に応じて公式情報を参照することで、より実務に即した運用が理解できます。

Db2のパフォーマンスを維持するためには、REORGとRUNSTATSの適切な運用が欠かせません。

・RUNSTATSで統計情報を更新する
・REORGでデータ配置を最適化する
・両方を組み合わせて実行する

まずは基本的な流れを押さえ、そのうえで詳細な運用について理解を深めていくことが重要です。

Db2の技術情報については、以下の記事で整理しています。