【TF】【IM】 Db2 の自動メンテナンス機能でここまでできた

想定運用シナリオと検証環境

運用シナリオ

この記事では、以下のシナリオでシステムを運用することにする。

• 運用時間 業務時間帯：午前 7 時から翌午前 4 時 メンテナンス時間帯：午前 4 時から午前 7 時 システムの起動停止は、3 ヶ月に一回必要があれば行うが、通常は停止しない。
• バックアップ 上記のメンテナンス時間帯に、日次でオンライン・データベース・バックアップを取得し、障害時には障害発生時点まで戻すことができるようにする。 バックアップは 2 世代管理とする。
• パフォーマンス維持のための表メンテナンス 表の再編成は行わない。(索引経由のアクセスが中心であるため、特に必要としない。) 索引の再編成は実施する。 統計情報の取得は全表に対して、必要に応じて行う。
• ハウスキーピング 継続的に増大するログファイルなどは、自動的に消しこむようにする。
• チューニング 特別なメモリー・チューニングを行わなくても、適切なメモリー・アロケーションが行われることを期待する。
• ストレージ データベースの表スペースは、必要に応じて自動的に拡張されるものとする。

Db2 による自動化

上記運用シナリオは、Db2 の自動化機能で実現できることばかりだ。

逆に言えば、製品機能の範囲でも、これだけの運用は可能ということだ。

以下、Db2 の自動メンテナンス (自動バックアップ、REORG, RUNSTATS)、その他の自律コンピューティング機能 (STMM, 自動ストレージなど) でできることをまとめる。

• バックアップの自動取得 バックアップを曜日、時間などを指定したスケジュール・ベースで取得できる。この時、データベースに対する更新が少ない場合は、バックアップ取得をスキップするなどの操作も可能だ。
• パフォーマンス維持のための表メンテナンス パフォーマンスを維持するため、表メンテナンス作業として、定期的に REORG (再編成), RUNSTATS (統計情報の収集) を行う。 表 / 索引の REORG (再編成) 表や索引のフラグメンテーションの解消のため、また、表のレコードを特定の索引順に並べなおすため、自動で REORG を行うことができる。 ただし、フラグメンテーションが発生しにくかったり (レコードの削除や更新が多くない) や、表内のレコードの並び順によってパフォーマンスが左右されにくかったり (表へのアクセスが索引経由で行われるなど) する場合は、REORG 運用は必要ない。 表の REORG には、アプリケーションによる表の更新中にも実行できるオンライン REORG と、アプリケーションによる更新ができないオフライン REORG がある。現在、自動メンテナンス機能では、オフライン REORG のみサポートしている。RUNSTATS (統計情報の収集) Db2 に適切なアクセス・プランを選ばせるためには、表 / 索引の統計情報の収集は不可欠だ。Db2 では、RUNSTATS を自動で行わせることができる。RUNSTATS はアプリケーションによる表の更新中にも行うことができる。
• ハウスキーピング Db2 で自動的に増大するファイルとしては、バックアップ・イメージ、アーカイブ・ログ、エラー等が記録されるメッセージ・ファイルが挙げられる。 バックアップおよびログ・イメージの管理 バックアップを定期的に取得するのであれば、ディスク容量を維持するために、古いバックアップ・イメージは削除する必要がある。Db2 では、バックアップ・イメージの世代管理を行い、指定された世代を超えるイメージおよび、そのバックアップ・イメージに関連するアーカイブ・ログその他のオブジェクトを自動的に削除する機能を提供する。メッセージ・ファイル領域の管理 Db2 の起動停止などの稼動状況や、エラー・メッセージが書かれる db2diag.log、および管理通知ログ (インスタンス名.nfy) のサイズを指定して、ローテーションさせることができる。
• メモリー・チューニング Db2 は、使用できるメモリーサイズを、起動時の物理メモリーサイズから計算する。バッファープールや、ソート領域など Db2 内部でのメモリーの割り振りは、ワークロードに応じて動的にかつ自動的にチューニングされる。この機能を STMM (セルフ・チューニング・メモリー機能) という。これはデフォルト動作である。
• 表データ領域の自動拡張 Db2 のデータベースを作成すると、デフォルトで自動ストレージ表スペースが作成される。この表スペースは、内部に格納されるデータ量が増加すると、必要に応じて拡張される。拡張は自動で行われるため、運用作業は発生しない。あらかじめ特定の大きさの領域をアロケートしておいて、そこにデータを格納していくのではないため、表スペースの使用率を監視する必要はない。OS のファイル領域の使用率は、Db2 外で定期的に確認することが望ましい。

以上のように、Db2 では自動メンテナンス、およびその他機能を使用すれば、通常の運用作業のほとんどは自動化できる。

これ以外の運用作業としては、Db2 の稼動監視が挙げられる。自動メンテナンス機能では提供されないので、Db2 の監視ツール、OS の監視ツールを合わせて、要件に応じて検討してほしい。

環境

上記運用シナリオを、実際に自動メンテナンスで設定して、稼動検証してみた。

自動メンテナンス設定は、Data Studio というツールを使用して GUI で行うことができる。使用した環境は以下のとおりだが、運用対象となる Db2 は、V9.7 以降であれば、V10.1, V10.5 でもほとんど差はない。

環境構築手順が必要な場合は、「前提作業」の項を参照いただきたい。

• DB サーバー OS: Linux(RHEL 6.3) Db2 for Linux, UNIX and Windows V10.5 使用するインスタンス/データベース：　db2inst1/SAMPLE
• 操作用クライアント OS: Windows 7 Data Studio 4.1

自動メンテナンスの構成

では、早速、Db2 を構成していこう。この記事では、Data Studio で構成を行う。

操作の前提として、Db2 サーバーとクライアントとなる Data Studio が導入されていること、また、運用対象となるデータベースが作成済みであること、Data Studio 上にそのデータベースに対する接続が定義されていることが必要だ。

製品導入およびセットアップについては、後の「前提作業」で紹介したサイトをご覧いただきたい。

(1) Data Studio からデータベースへの接続

まず、Data Studio から、対象のデータベースに接続しよう。

Data Studio のデフォルト画面である「データベース管理」パースペクティブでは、図のように左手に「管理エクスプローラー」があり、Data Studio に接続情報が登録されたサーバー/インスタンス/データベースのツリーが表示されている。

ツリーから接続したいデータベースを選択し、右クリックのメニューから接続を選択し。必要情報を入力して、データベースに接続する。

(2) インスタンス・レベルのパラメータ構成

運用シナリオを実現するためには、いくつかの項目を組み合わせて設定する必要がある。設定には、インスタンス・レベルで行うものと、データベース単位で行うものがある。

最初に、インスタンス・レベルの設定であるデータベース・マネージャ (インスタンス) 構成パラメータを定義しておこう。

図のようにインスタンス名を右クリックし、メニューから「構成」を選ぶ。

すると、図のように、右手 (赤枠) に「パラメータの構成」ウィンドウが表示される。

画面をスクロールして、設定したいパラメータを見つける。スクロールバーは、下の図のように、ビュー全体のスクロールバーの内側に、パラメータリストのスクロールバーがあるので、気をつけよう。

構成パラメータは、カテゴリごとにまとめられており、カテゴリ名の左の三角をクリックすることで、パラメータを表示したり隠したりすることができる。

今回構成したいのは、「環境」カテゴリの DIAGSIZE パラメータだ。パラメータ名のすぐ右隣の列には現在の設定値が表示されており、その右の列に設定したい値を入力する。この記事では、「20」とする。

DIAGSIZE は、Db2 の診断ログ (db2diag.log) と、管理通知ログ (インスタンス名.nfy) のサイズを決めるものだ。これに 0 以外の数字を指定すると、診断ログと、管理通知ログは循環使用となり、診断ログファイル、管理通知ログファイルが各 10 個まで作成される。DIAGSIZE は、ログファイルの合計サイズを MB で指定する。ログの書かれる場所は、同じインスタンス構成パラメータリスト中の「診断」-DIAGPATH で指定されているので、見ておこう。

パラメータを設定したら、上にスクロールして「実行」ボタンを押して、変更を反映する。

上の図のように、実行されたコマンドと、その結果が表示されるので、成功していることを確かめよう。

Data Studio で構成変更する場合は、通常、画面上で値を変更するだけでなく、「実行」でそれを反映する必要がある。結果の確認も忘れずに行ってほしい。

コマンドが「DEFFERED」となっている場合、設定変更は、対象 (この場合インスタンス) の再起動後に反映される。

後でもよいが、ここで忘れないうちに再起動しておく。停止/起動は、下の図のように、「管理エクスプローラー」から対象を選んで行うことができる。インスタンスの停止時には、他のアプリケーション接続を強制終了するオプションもあるが、通常は接続があると停止できない。停止時には、使用者がいないか確認しておこう。

(3) データベースの構成

今度は、SAMPLE データベースを構成する。

データベースに接続し、データベース名を右クリックすると、図のように、メニューに「セットアップおよび構成」が表示される。それを選択すると、「構成」/「自動メンテナンスの構成」/「データベース・ロギングの構成」が表示される。データベースの構成は、このメニューを使用して行う。

(4) データベース・ロギングの構成

他の構成の前提として必要となるため、まず、ロギングを構成する。

メニューから「データベース・ロギングの構成」を選択する。

「データベース・ロギングの構成」画面では、「ロギング・タイプ」/「ロギング・サイズ」/「ロギング・ロケーション」の 3 つのタブがある。ここで、「ロギング・タイプ」を選ぶ。

「ロギング・タイプ」構成タブが、図のように表示されるので、「データベース・ロギング・タイプ」として、「アーカイブ」を選ぶ。

下にスクロールし、図のように、ログのアーカイブ方法として「自動 Db2 アーカイブ」を選択し、アーカイブ先のロケーション (パス名) を指定する。

ロギング・タイプを循環からアーカイブに変更すると、オンライン・バックアップが取得できるようになる。

アーカイブ・ロギングへ変更した時には、一度データベースのオフライン・フルバックアップを取る必要がある。そのため、ロギング・タイプでアーカイブを選択すると、バックアップ取得に必要な情報を指定する追加タブが表示されるようになる。

「バックアップ・ロケーション」の指定は必須なので、「バックアップ・イメージ」タブで、バックアップ先を指定する。バックアップ・ロケーション欄横の「追加」ボタンで、あて先パスを追加できる。

この入力が済むと、変更を反映できるようになるので、画面上方の「実行」ボタンを押す。接続ユーザーがいると、バックアップが取得できず、失敗するので注意しよう。

後でタイミングを見計らって実行したい場合は、コマンドを保存しておくこともできる。「実行」ボタンの隣の「コマンドのプレビュー」を実行して、プレビューしたコマンドを保存すればよい。

ロギングの構成では、この他、ログファイルの個数や、サイズ、ログをミラーリングするかなど、いろいろな設定ができるが、今回の自動運用には必須ではない。システムの要件に応じて、各自設定されたい。

(5) 自動メンテナンスの構成

いよいよ、運用シナリオに即して、自動メンテナンス・ポリシーを設定していく。

データベースの「セットアップおよび構成」→「自動メンテナンスの構成」を選択すると、図の「自動メンテナンス・オプションの選択」ウィンドウが表示されるので、全てのオプションのチェックボックスをチェックする。変更を反映するため、「実行」をクリックする。

Db2 の自動メンテナンス機能という場合、狭義には、ここで設定されるバックアップ、REORG, RUNSTATS を指す。(STMM, 自動ストレージなどはここでは設定されない)

(6) オンライン・メンテナンス・ウィンドウの構成

オンライン・メンテナンス・ウィンドウとは、アプリケーションを稼動したまま実行できる作業を実施するための時間枠だ。オンラインで実施できる作業には以下のものがある。

• オンライン・バックアップ
• RUNSTATS
• オンライン索引 REORG
• オンラインで実行できる表 REORG のオプション (削除済みページの解放)

時間枠は、「オンライン・メンテナンス・ウィンドウ」タブから、開始時間、時間帯の長さ、曜日、日付の組み合わせで指定する。

ここでは、図のように、毎日 (日曜から土曜日)、メンテナンス枠と決められている 04:00-07:00 と指定する。「メンテナンス・ウィンドウの作成または更新」チェックボックスをチェックして、「実行」する。

オンライン・メンテナンス作業は、業務時間帯に実施してもよいのだが、業務終了後の状態をバックアップしたいので、ここでは、業務外のメンテナンス時間帯を指定する。

システムによっては、業務後の予備時間が無く、むしろ業務時間帯の非ピークにバックアップしたいようなところもあるかもしれない。ウィンドウの決定は、後述「自動メンテナンスの考慮点」でも述べるように、大切なところなので、条件を吟味して指定してもらいたい。

オフライン・メンテナンス・ウィンドウ

メンテナンス・ウィンドウには、オンラインとオフラインがある。オフライン・メンテナンス・ウィンドウは、アプリケーションを停止して行う必要のある保守作業を実施するための時間枠だ。

オフライン・ウィンドウで実施する必要のある作業は、以下の 2 つだ。

• オフライン・バックアップ
• 表の REORG

今回は、バックアップはオンライン・バックアップを取得すること、表の REORG は行わないことから、オフライン・メンテナンス・ウィンドウは構成しない。

(7) バックアップ・ポリシー

「バックアップ・ポリシー」タブで、バックアップ取得方法を指定する。

自動バックアップでは、バックアップ頻度 (日、週など) と、ログの量 (更新が無ければバックアップはとらず、更新が多ければバックアップを頻繁にとる) の組み合わせでバックアップのタイミングを指定できる。

今回は、上の図のように、バックアップを毎日とるようにする。

下にスクロールし、バックアップのあて先と、バックアップ・モードとして「オンライン」を指定する。

「バックアップ・ポリシーの作成または更新」をチェックして実行。

(8) REORG ポリシー

REORG ポリシーでは、表の種類や名前、サイズの指定 (大きすぎる表はオフライン REORG では時間がかかるため) など、いろいろな基準で REORG 対象とする表を設定できる。なお、実際に REORG を実行するかどうかは、REORGCHK の結果判断されるので、ここで対象表としたからといって、常に REORG されるわけではない。

ここでは、オンラインで実行可能な、索引の REORG のみ実施するよう指定しておく。

(9) RUNSTATS ポリシー

RUNSTATS ポリシーでは、REORG と同様、自動 RUNSTATS の対象表を選択できる. 統計情報は、ここでは、すべての表を対象と指定しておく。(画面は省略)

(10) データベース・パラメータの構成

自動メンテナンスの構成は、(9) までで一通り終了したことになるが、運用シナリオに必要なデータベース構成パラメータがいくつか残っているので、これらを設定する。

データベース・パラメータの構成は、「管理エクスローラー」ツリーから、データベース名を選び、「セットアップおよび構成」→「構成」で行う。

「データベース・パラメータの構成」ウィンドウでは、「(2) インスタンス・レベルのパラメータ構成」のウィンドウと同様、カテゴリごとに分けられたパラメータのリストが、現在の設定値とともに表示される。

ここで、「リカバリー」カテゴリの以下のパラメータを設定する。

• AUTO_DEL_REC_OBJ : ON
• NUM_DB_BACKUPS : 2
• REC_HIS_RETENTN : 2

これらのパラメータは、取得したバックアップ関連オブジェクトの世代管理とハウスキーピングを制御するものだ。

NUM_DB_BACKUPS は、保持するバックアップ・イメージの世代数、REC_HIS_RETENTN は、バックアップ・イメージの保持日数を指定する。

バックアップ・イメージは、両方の指定で期限が切れた後のバックアップ取得時に削除される。

AUTO_DEL_REC_OBJ は、バックアップ・イメージの削除時に、これに関連するアーカイブ・ログファイルや LOAD コピーファイルも、合わせて削除することを指定する。

これらのパラメータによるファイルの消しこみは、自動バックアップとは独立した動作なので、自動バックアップを使用しない場合でも、活用できる。

これらのパラメータの変更は、データベースを再活動化した際に反映される。

その他、以下のパラメータが設定されていることを、確認する。

表 1. 確認すべきパラメータ

自動メンテナンスの手動設定方法:

本文では、Data Studio での構成を説明しているが、これまでの設定は、コマンドラインでも可能だ。 パラメータの設定には、以下のコマンドを使用する。

インスタンスの構成パラメータ

UPDATE DBM CFG USING パラメータ名 値

データベースの構成パラメータ

UPDATE DB CFG USING パラメータ名　値

自動メンテナンス・ポリシーの設定には、以下のストアド・プロシージャを使う。

AUTOMAINT_SET_POLICYFILE(‘ポリシータイプ’, ‘ポリシーファイル名’)

設定できるポリシータイプは、AUTO_BACKUP, AUTO_REORG, AUTO_RUNSTATS, MAINTENANCE_WINDOW で、ポリシーの内容は XML ファイルに記述する。コマンドを使い慣れている場合は、こちらの方が細かい設定ができる。

自分で一から XML を記述するのは難しいが$INSTHOME/sqllib/samples/automaintcfgにポリシー XML ファイルのサンプルがあるので、修正して使用できる。

また、DataStudio のポリシー設定画面で、「コマンド・プレビュー」を行えば、XML を含む、ポリシー設定プロシージャの実行サンプルが生成される。

自動メンテナンスの構成 – (7) バックアップ・ポリシーの「コマンド・プレビュー」出力例

CONNECT TO SAMPLE; CALL SYSPROC.AUTOMAINT_SET_POLICY ( 'AUTO_BACKUP', BLOB('<?xml version="1.0" encoding="UTF-8"?><DB2AutoBackupPolicy xmlns="http://www.ibm.com/xmlns/prod/db2/autonomic/config"><BackupOptions mode="Online">
<BackupTarget><DiskBackupTarget><PathName>/tmp/backup</PathName></DiskBackupTarget></BackupTarget></BackupOptions><BackupCriteria numberOfFullBackups="1" timeSinceLastBackup="168" logSpaceConsumedSinceLastBackup="6400"/>
</DB2AutoBackupPolicy> ') ); CONNECT RESET;

AUTOMAINT_SET_POLICY は、ポリシー XML をファイルとして与えるのではなく、プロシージャの引数として直接記述する場合に使用する。

自動メンテナンスの動作確認

自動メンテナンスの構成を行ったら、正常に稼動しているか確認する。

基本的には、db2diag.log をチェックすることで、どのような作業が行われているか知ることができる。

また、バックアップ、REORG などの情報は、回復履歴ファイルに記録されており、LIST HISTORY コマンドで確認することができる。

バックアップ

バックアップでは、何より、あて先にバックアップ・イメージが存在するかどうかを確認することが大切だ。

その他に、ログや、コマンドによって確認する例を以下に示す。

db2diag.log の自動バックアップ・メッセージ例

2014-08-07-05.45.31.659852-240 I1091734E374          LEVEL: Event
PID     : 17886                TID : 140637196977920 PROC : db2acd 0
INSTANCE: db2inst1             NODE : 000
HOSTNAME: xxxx
FUNCTION: DB2 UDB, Health Monitor, hmonBkpBackupDBOnline, probe:530
STOP    : Automatic job "Backup database online" has completed successfully
 on database SAMPLE, alias SAMPLE

回復履歴ファイルの確認コマンド実行例

$ db2 list history backup all for sample

                    List History File for sample
Number of matching file entries = 2

Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  Backup ID
 -- --- ------------------ ---- --- ------------ ------------ --------------
  B  D  20140807054529001   N    D  S0000131.LOG S0000131.LOG
 ----------------------------------------------------------------------------
  Contains 5 tablespace(s):

 00001 SYSCATSPACE
 00002 USERSPACE1
 00003 IBMDB2SAMPLEREL
 00004 IBMDB2SAMPLEXML
 00005 SYSTOOLSPACE
 ----------------------------------------------------------------------------
Comment: DB2 BACKUP SAMPLE ONLINE
 Start Time: 20140807054529
   End Time: 20140807054531
     Status: A
 ----------------------------------------------------------------------------
  EID: 185 Location: /tmp/backup

REORG

AUTO_REORG=ON になっている場合、システムでは、定期的 (2 時間おき) に、表の REORG が必要であるかどうかの評価を行っている。

以下は db2diag.log に出力される、REORG 評価の実施メッセージ例だ。

db2diag.log の REORG 評価メッセージ例

2014-08-06-06.45.26.175851-240 I376581E329           LEVEL: Event
PID     : 17886                TID : 140637451187968 PROC : db2acd 0
INSTANCE: db2inst1             NODE : 000
HOSTNAME: lexbz0223
FUNCTION: DB2 UDB, Health Monitor, db2HmonEvalReorg, probe:10
START   : Automatic reorg evaluation has started on database SAMPLE

この記事では、表の REORG は実施していないが、自動 REORG を行っている場合は、以下のようなメッセージが出力される。

db2diag.log の REORG メッセージ例

2014-07-28-05.26.58.174382-240 I8295995A424       LEVEL: Event
PID     : 1155132              TID  : 1293        PROC : db2fmp
INSTANCE: db2inst1              NODE : 000
HOSTNAME: サーバー名
EDUID   : 1293                 EDUNAME: db2acd
FUNCTION: DB2 UDB, Automatic Table Maintenance, db2AutoReorgExec, probe:10
STOP    : Automatic reorg has completed successfully on table SAMPLE .スキーマ名.表名

RUNSTATS

RUNSTATS の実行は、業務に大きな影響は与えないので、特に監視する必要はないが、実行された場合は、SYSCAT.TABLES カタログ表の STATS_TIME 列が更新されるので、これを見ることで RUNSTATS の有無を確認できる。以下の SQL では、2014年8月6日 0時以降に RUNSTATS が実行された表の名前を抽出している。

指定日以降に RUNSTATS が実行された表をリストする例

$ db2 "select substr(TABSCHEMA,1,10), substr(TABNAME,1,20),
 STATS_TIME from SYSCAT.TABLES where STATS_TIME > timestamp('2014-08-06-00.00.00.0000')"

1          2                    STATS_TIME
---------- -------------------- --------------------------
SYSIBM     SYSTABLES            2014-08-06-05.53.11.211125
SYSIBM     SYSVIEWS             2014-08-06-18.02.31.990503
SYSIBM     SYSDEPENDENCIES      2014-08-06-17.55.22.147490
SYSIBM     SYSCOLAUTH           2014-08-06-05.55.25.795139
SYSIBM     SYSSCHEMAAUTH        2014-08-06-05.55.25.915186
SYSIBM     SYSPASSTHRUAUTH      2014-08-06-05.55.25.958411
SYSIBM     SYSROUTINEAUTH       2014-08-06-05.52.49.188962
SYSIBM     SYSLIBRARYAUTH       2014-08-06-05.55.26.014126
  : 略

バックアップ・イメージ、アーカイブ・ログのハウスキーピング

AUTO_DEL_REC_OBJ が指定されており、バックアップの取得時に、期限切れとなったバックアップ・イメージや、アーカイブ・ログが消去された場合は、db2diag.log にメッセージが出力される。

db2diag.log の自動ハウスキーピング・メッセージ例

2014-08-07-10.45.31.587045-240 E1089018E561          LEVEL: Info
PID     : 17868                TID : 140081050412800 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : SAMPLE
APPHDL  : 0-7212               APPID: *LOCAL.db2inst1.140807144559
AUTHID  : DB2INST1             HOSTNAME: lexbz0223
EDUID   : 2831                 EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, database utilities, sqluhPruneHistoryDeleteFile, probe:1745
MESSAGE : ADM8504I  Successfully deleted the backup image with timestamp
          "20140729141712".

2014-08-07-10.45.31.588552-240 E1089580E560          LEVEL: Info
PID     : 17868                TID : 140081050412800 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : SAMPLE
APPHDL  : 0-7212               APPID: *LOCAL.db2inst1.140807144559
AUTHID  : DB2INST1             HOSTNAME: lexbz0223
EDUID   : 2831                 EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, database utilities, sqluhDeletionReport, probe:984
MESSAGE : ADM8506I  Successfully deleted the following database logs "100 -
          102" in log chain "1".

自動メンテナンスの考慮点

ここまで、想定運用シナリオに即して、自動メンテナンスを構成し、稼動する様子を示してきたが、自動メンテナンスを採用するためには、考慮しておくべきことがある。

自動メンテナンスで済むシステム / 済まないシステム

Db2 の自動メンテナンス機能が広いサービスを提供しているとは言っても、すべてのシステムが自動メンテナンスで守れるとは限らない。汎用的な仕組みで対応できるのは、ある程度一般的なシステムということになる。

自動メンテナンスの対象システムとしては、以下が条件となるだろう。

• 特別な高可用性要件がないこと 目安として、HA クラスタ構成をとっていない、災対環境を構築していないことがあげられる。HA クラスタ、HADR、災対環境がある場合には、運用においても、引継ぎ方法その他考慮点があり、そのための手順や、スクリプトの作成などを必要とする。これらは自動メンテナンス機能ではカバーされないため、別途運用設計が必要となる。
• 毎日のメンテナンス時間 (業務停止時間) を確保できる 自動メンテナンス機能では、メンテナンス・ウィンドウ内での、個別の作業スケジュール、起動タイミング、順序などは制御できない。業務時間中にオンライン・メンテナンス・ウィンドウを設定することはできるが、もともとメンテナンス時間枠があって、そこをウィンドウに設定できると、自動メンテナンスを利用しやすい。
• DB サイズは目安として 1TB 以内まで システムが大きいほど、自動運用によるバックアップや、表の再編成に時間がかかる。大きなシステムでは、システム特性に応じて、バックアップや REORG の方法が検討されるべきだ。

自動メンテナンスを採用することが難しいシステムでの、運用のあり方については、シリーズ「これだけはおさえたい Db2 の運用」の他記事を参考にしていただきたい。

構成上の考慮点

次に、自動メンテナンスを使用する場合に、理解しておくべき点を述べる。

メンテナンス・ウィンドウの方針

すでに述べたとおり、自動メンテナンス機能では、オンライン・メンテナンス・ウィンドウと、オフライン・メンテナンス・ウィンドウがある。どの作業を、いつ行わせるかは、メンテナンス・ウィンドウをどのように設定するかによって決まる。

ウィンドウ決定のためには、以下に注意する。

• ウィンドウの数 オンライン/オフライン・ウィンドウ各 1 つしか定義できず、作業ごと (例えば、バックアップ・ウィンドウ、REORG ウィンドウなど) に分けることはできない。
• ウィンドウ内の作業の制御 ウィンドウ内で実行される作業の起動タイミングや、順序は指定できない。
• ウィンドウの幅 実行すべき自動メンテナンス作業があるかどうかのチェックは約 2 時間おきに行われる。そのため、タイミングによっては、枠の開始からすぐには作業が実行されないことがある。チェックまでの時間も考え、枠の幅は 2 時間+作業実施時間を指定する。
• オフライン・ウィンドウ オフライン作業 (例えば、オフライン・バックアップ) を実行しようとしたタイミングで、ユーザーが接続していればエラーとなるが、自動メンテナンスではアプリケーションを停止するサービスは提供していない。 また、オフライン・ウィンドウ内で開始された作業が、長引いてウィンドウを突き抜けたとしても、キャンセルされることはない。このことから、オフライン・ ウィンドウを使用する場合は、アプリケーション停止の仕組みを作成する他、作業が長引いたときの対応を決定しておく必要がある。 オフライン作業のための業務停止が難しい場合は、オンライン作業のみ実行するようにした方がよいだろう。
• オンライン・ウィンドウ オンライン作業は、業務中に実行可能だが、ウィンドウ内での作業の順序やタイミングは制御できないので、業務中に不定期にユーティリティを実行したくない場合は、オンライン・ウィンドウをメンテナンス時間帯や、オフピークの時間帯に設定するとよいだろう。 この記事では、メンテナンス時間帯をオンライン・メンテナンス・ウィンドウとしている。

オンライン作業の考慮点

• データベースの活動化 バックアップが必要かどうかのチェックは約 2 時間ごとに行われる。この時にデータベースが活動状態でないと、チェックが行われず、バックアップがスキップされることがある。Db2 データベースでは、デフォルトでは、ユーザーが接続要求を出すと自動的にデータベースが活動化し、接続しているユーザーがいなくなると非活動化する。トランザクションが多くないシステムでは、データベースが時々非活動化されることがあるが、オンライン・メンテナンスを行うデータベースでは、このような非活動化が起こらないようにすべきだ。具体的には、データベースは、Db2 を起動したら、ACTIVATE DB コマンドで活動化する。コマンドで活動化したデータベースは、接続ユーザーがいなくなっても、非活動化されることはない。
• オンライン作業のパフォーマンス影響度 オンライン・ウィンドウを業務時間中に設ける場合は、UTIL_IMPACT_LIM インスタンス構成パラメータで、ユーティリティ実行のパフォーマンス影響度を抑えることができる。

機能の選択

この記事では、紹介のため、Data Studio で構成できる機能をすべて使用しているが、必要に応じてバックアップだけ、RUNSTATS だけのように選択して使用してよい。自動 RUNSTATS はデフォルトで ON であり、業務中に実行可能なので使いやすい。

運用要件

自動 REORG や RUNSTATS を行うにあたって、表ごとに運用方針を変えることはできない。よって、パフォーマンス維持に特別に注意を払うべきアプリケーションがあるのであれば、自動メンテナンスより、目的に応じたシェルを作成するなどして REORG/RUNSTATS した方がよい。

バックアップについても、週次でフルバックアップを取って、その他の日は差分バックアップを取る、などはできない。単純なフルバックアップの要件である必要がある。

バックアップ領域

AUTO_DEL_REC_OBJ 構成パラメータを使用して、バックアップ・イメージその他の世代管理を行う場合、古いバックアップ関連オブジェクトの削除は、新しいバックアップの取得作業の最後に行われる。したがって、2 世代保管を予定しているとき、ディスク容量は、最低 3 世代分必要となる。スケジュール外のバックアップを取得する可能性も考慮に入れて、ディスクは予定世代数 +2 程度は保持できるようにしておくことが望ましい。

稼動監視

問題が発生していないことは、「自動メンテナンスの動作確認」で紹介したメッセージなどで確認しておくことをお勧めする。特にバックアップはいざというときに、取得されていなかった、ということがないように管理したい。

前提作業

これまでの記述では、Db2, Data Studio を前提として話を進めてきたが、実際使うには、まず Db2 を導入し、データベースを作成しておく必要があることは、言うまでもない。

また、操作ツールとして Data Studio の導入を行い、データベースに接続できるように構成することが必要だ。

Db2, Data Studio の導入/構成方法は、以下の資料に記述がある。

Db2 の導入とデータベースの作成

[Db2] Db2 製品のダウンロードとインストール方法

Data Studio の導入と構成

Data Studio は、Eclipse ベースの Db2 運用管理ツールで、無償で提供されている。

Windows 版と、Linux 版があり、以下のサイトからダウンロードできる。

• IBM Data Studio

導入、構成方法は、以下のサイトが参考になる。

• IBM Data Studio インストール・ガイド

Data Studio から、Db2 の開始や終了などの操作を実行する時には、SSH を使用する。これは、データベースサーバーが Windows で、Data Studio が同一サーバー上に導入されている場合も同様だ。

SSH の構成については、以下を参照のこと。

• IBM Data Studio V4.1.1 documentation

Data Studio は、自動メンテナンス構成以外にも、データベース内のオブジェクト (例えば、表スペースや表) の作成、データの参照、SQL の作成と実行など、幅広く使用できるので、この機会に試してみていただきたい。

まとめ

この記事では、Db2 における自動メンテナンス機能概要、構成方法、考慮点を紹介してきた。バックアップ、RUNSTATS、REORG、ハウスキーピングなど一通りのことが 可能となるので、手間をかけたくないシステムでは、選択肢の一つだ。この記事が、運用設計の参考になることを願う。

著者 木村 佳陽子

参考情報

• IBM Db2 11.5 for Linux, Unix, and Windows documentation
• IBM Data Studio V4.1.1 documentation

お断り：