部内勉強会（よく使う運用機能）

今回のテーマは「よく使う運用機能」として定期的に実施する必要がある「再編成」、「再編成チェック」、「統計情報更新」について紹介します。

今日のテーマは先週に引き続き、運用の中でもバックアップと並び重要な機能である「再編成」とその実施要否を教えてくれる「再編成チェック」、そしてパフォーマンスへの影響が大きい「統計情報更新」の3つです。

データベースはパフォーマンス（レスポンス）がとても重要です。パフォーマンスが速すぎるということはないのですが、遅いとなると多大な影響が出てきてしまいます。パフォーマンスを維持し悪化させないための代表的な方法として今回テーマとする機能があります。「よく使う」というよりも「必ず実施するもの」として認識しておきましょう。

再編成

再編成（REORG）は断片化したデータを並べなおしたり、テーブル内の空き領域を開放したり、圧縮辞書を作成する機能です。いわゆるデフラグです。パフォーマンス維持改善のために実施する必要があります。

再編成がなぜ必要なのか？

テーブルのレコード（データ）は更新や削除を重ねることで順序がバラバラとなってしまいます。削除したレコードの領域は再利用されるのですが、レコードサイズは一定でないことが多いので新たに入るレコードが空き領域に入らない場合もあります。そのため、別の場所に格納されてしまうこともあって、SQLの要求で連続してレコードが必要な場合ではバラバラに格納されたレコードを読み取るのに何回もアクセスが発生してしまうことなります。そうなると当然パフォーマンスは悪くなってしまうことは想像していただけると思います。そんな状態を回避解消するため、レコードを並び替えてアクセス良くする必要があります。パフォーマンスダウンすることは利用者（ユーザー）への影響も大きいです。

それと、担当していたシステムでもやらかしてしまったケースで、データ移行した際に再編成などの処理実施を忘れてしまうことがありました。開発→本番などへデータを移行した際は、統計情報更新と合わせて忘れずに移行作業項目に組み込んでおきましょう。テストでは充分なパフォーマンスが出ていても、再編成および統計情報更新をしていないために充分なパフォーマンスが出ないことになりかねません。

再編成には実行タイプが2つあり、ひとつは以前からあるシャドー・コピー・アプローチで、もうひとつはインプレース・アプローチです。シャドー・コピー・アプローチは並べ替えているベーステーブルのレコードを一時作業領域に並べ替え、完了後に元の領域に戻し、さらに索引も作成しなおすという方法です。インプレース・アプローチは、該当テーブルの中のエクステントの空き領域を使ってデータを並び替える方法です。こちらは、まず先頭のレコードを後方の空きエクステントに詰め込み、先頭のエクステントを空にしてしまいます。その後、空いた先頭のエクステントにレコードを並べていく方法です。こちらはバックグラウンドでの実行となり、かつ処理途中で中断ができます。さらに処理中でも更新アクセスが可能です（実行時にオプション指定が必要）。索引の再作成はしないため、別途索引再作成の処理が必要になってしまいます。また、処理においてログ量が多くなりますので、必ず事前にテストをして書き出し量は確認しておきましょう。

再編成が不要なテーブルとしては、SQLによる更新処理がない読取専用のテーブルが該当します。SQLでの更新がないのでフラグメンテーションが起こらないためです。またユニーク索引列を条件にしたSELECT文での1件のみ検索する場合も再編成は実施有無の影響が少ないです。

・シャドー・コピー・アプローチのイメージ

・インプレース・アプローチのイメージ
（大きな枠がエクステント単位、小さい枠がデータのレコードをイメージしてください）

1）先頭のエクステントのレコードを後ろの空き領域に移動

2）先頭のエクステントが空になったら順番に先頭にレコードを移動する

3）空いたエクステントにキー順にレコードが並べられる

4）繰り返す

再編成チェック

再編成するかどうか悩むところがあると思いますが、それを解消してくれるツールが用意されています。それが再編成チェック（REORGCHK）です。このコマンドは統計情報を基にして対象となったテーブルのレコードなどの状況を判断し、各閾値に引っかかっているかどうかで再編成すべきか教えてくれる非常に便利なツール（といってもコマンド実行）です。テーブルとインデックスにそれぞれ閾値計算式があり、各閾値にひっかかると結果の該当箇所に「＊」が表示されます。

動きとしては、最初に統計情報更新を内部的に実施し、その情報をもとに判断します。この統計情報更新も、再取得するか、すでに取得済みのものを利用するかはオプションで選択できます。

・REORGCHK結果例（特定スキーマを対象に実行：Windows版）

統計情報更新

実施しないとパフォーマンスへの影響が大きい統計情報更新（RUNSTATS）です。この処理はアクセスパスを決定しているオプティマイザーが使用する情報源となるデータ（レコードの数や種類など）を収集する機能のことで、この情報と実体にギャップがあるとオプティマイザーは適切なアクセスパスを選べず、パフォーマンスが悪くなってしまうことがあります（オプティマイザーは収集した統計情報を基にしてアクセスパスを決定している）。そうならないためにもデータが大量に更新された後や索引を作成した時など、適切なタイミングで実施することが望ましいです。「パフォーマンスが悪いな、と思って統計情報更新したら改善した」なんてことはよくある話しで、可能であれば毎日実施が望ましいです。データ量が時間によって増減するテーブルなどは数時間ごとに実施することもあるようです。

実行するタイミングは主に、大量にデータ入替えがあった後（初期LOADや移行、定時LOADやIMPORTなど）、テーブルの10%～20%のレコードに更新が入ったとき、索引などのオブジェクトを新たに作成したとき、REORGした後、REBINDした後に実施することが望ましいです。

勉強会の様子（右奥が筆者）

今回の勉強会は、福岡事業所からの参加者が多く、本社からは数名が業務都合で参加できませんでした。（そして今日もＹ君は客先から本社へ戻って来ることができず、Web会議での参加となりました。）

＜参考資料リンク＞

プレ匠塾　4．運用設計

DB2 V9.5 運用管理ガイド：DB2 for LUW V9.5 データベース・メンテナンス