検索
連載

データベースの状態監視とメンテナンス：DB2マイスター養成講座（6）（2/2 ページ）

管理者は、データベースが正常に動作しているか否かに注意を怠ってはならない。今回は、データベースの状態監視とメンテナンス方法について解説する。（編集局）

Share
Tweet
LINE
Hatena
前のページへ | 　　　　　　

データベース・オブジェクトの監視

　ここからは、各データベース・オブジェクトの監視とメンテナンスについて説明します。データベース・オブジェクトは、以下のとおりです。

オブジェクト 監視 パラメータ メンテナンス
データベース 操作可能 db.db_op_status 障害の可能性大
表スペース 操作可能 ts.ts_op_status 障害の可能性大
表スペース 使用率 ts.ts_util コンテナ･サイズの変更・追加・削除
表スペース・コンテナ 使用率 tsc.tscont_util コンテナ･サイズの変更・追加・削除
表 フラグメンテーション − 表の再編成（REORG TABLE）
索引 フラグメンテーション − 索引の再編成（REORG INDEX）
トランザクション・ログ 使用率 db.log_fs_util
db.log_util		 不要なログの整理

■データベース

　データベース自身は、状態監視がメインです。これは、監視パラメータのdb.db_op_statusを有効にしておくことでヘルス・モニターで監視できます。

　状態監視で異常が見つかった場合は、障害の可能性もあるので問題判別が必要です。問題判別に関しては、Linuxプラットフォームが対象ではありませんが、

http://www-6.ibm.com/jp/software/data/developer/library/techdoc/db2mgmt.html#distinc

にガイドがあるので参考にしてください。

　問題判別については、最終回のトラブルシューティングで解説します。

■表スペースの監視とメンテナンス

　表スペースに対する主なメンテナンス作業は、データ量の増加に伴うコンテナの追加です。よって、表スペースの使用状況が主な監視対象となります。

  • 表スペースの状態
    監視パラメータts.ts_op_statusをあらかじめ有効にしておくことで、ヘルス・モニターで監視できます。

  • SMS表スペース
    監視パラメータtsc.tscont_utilのしきい値をあらかじめ設定しておくことで、ヘルス・モニターで監視できます。LinuxにおけるSMS表スペースはOSが管理するディレクトリ・スペースなので、OSレベルでの監視も可能です。その場合、dfコマンドなどで定期的に表スペースのあるディレクトリを監視します。

  • DMS表スペース
    DB2が管理する表スペースであるため、ヘルス・モニターでSMS表スペースと同様に監視可能です。DMS表スペースの場合は、ts.ts_utilパラメータで設定します。

　以下の例では、SMS表スペースのコンテナ使用率が96％を超えたためアラームが出ています。

$ db2 get health snapshot for tablespaces on weather show detail
（中略）
    インディケーター名            = tsc.tscont_util
       値                       = 96
       評価のタイム・スタンプ      = 03/25/2004 15:44:08.964760
       アラート状態              = アラーム
       公式                     = ((4515688448/4695654400)*100)
（中略）

　次に表スペースのメンテナンスについて説明します。

●表スペースの状態監視に対応するメンテナンス

　表スペースの状態監視で表スペースの異常が見つかるケースは、主に以下の理由が考えられます。

  • 表スペースが静止状態にある場合
    静止状態をリセットします。

  • データベースがバックアップ・ペンディングにある場合
    データベース（もしくは該当の表スペース）のバックアップを取得します。

  • ロールフォワード・ペンディングにある場合
    ロールフォワードを実行します。

　メンテナンス方法について、詳しくは、

http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.doc/admin/r0009231.htm

を参考にしてください。

●表スペースの使用率監視に対応するメンテナンス

　表スペース（コンテナ）の使用率が増えたり、逆にまったく利用されなくなって、コンテナ・サイズの変更やコンテナの追加・削除が必要になる場合があります。

  • コンテナ・サイズの変更
    SMS表スペースに関しては、そのディレクトリがあるディスク領域を拡大するしか方法がありません。DMS表スペースであれば、alter tablespace文を使うことでコンテナのサイズを変更可能です。
alter tablespace [表スペース名] resize （file '[ファイル名]' [変更後のサイズ]）
  • コンテナの追加（DMS表スペース）
    DMS表スペースは、コンテナを追加することも可能です。
alter tablespace [表スペース名] add（file '[追加するコンテナのファイル名]' [サイズ]）

　前述のケースでは、表スペースのコンテナ使用率に対してアラートが出ていたので新たなコンテナの追加が必要でした。この方法でコンテナを追加することで対応します。

■表と索引の監視とメンテナンス

　表に対する主なメンテナンス作業は、表の再編成と統計情報の更新です。データの挿入や削除など、更新の多い表はデータのフラグメンテーションが発生し、照会のパフォーマンスが低下する場合があります。そこで、定期的にフラグメンテーションをチェックして、表の再編成を行う必要があります。

　また、SQLの最適なアクセス・パスを得るために、表中のデータの統計情報や分散情報を最新状態に更新しておく必要があります。よって、表の監視作業も使用状況が主な対象になります。

●データのフラグメンテーションチェック

　DB2では、REORGCHKコマンドを使って表および索引の再編成の必要性をチェックできます。

http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.doc/core/r0001971.htm

　REORGCHKコマンドは、以下の8つの式を評価して、再編成の必要性を判断します。評価式に基づいて再編成が必要と判断した表や索引には、「*」マークが付けられます。

表の統計分析

F1: 100 * OVERFLOW / CARD < 5

F2: 100 * (データ・ページ数の有効スペース使用率) > 70

F3: 100 * (必須ページ数 / 合計ページ数) > 80

索引の統計分析

F4: CLUSTERRATIO または正規化された CLUSTERFACTOR > 80

F5: 100 * (KEYS * (ISIZE + 9) + (CARD - KEYS) * 5) / ((NLEAF - NUM EMPTY LEAFS) * INDEXPAGESIZE) > 50

F6: (100 - PCTFREE) * ((INDEXPAGESIZE - 96) / (ISIZE + 12)) ** (NLEVELS - 2) * (INDEXPAGESIZE - 96) / (KEYS * (ISIZE + 9) + (CARD - KEYS) * 5) < 100

F7: 100 * (NUMRIDS DELETED / (NUMRIDS DELETED + CARD)) < 20

F8: 100 * (NUM EMPTY LEAFS / NLEAF) < 20


RUNSTATS 中....
 
（中略）
索引統計:
 
F4: CLUSTERRATIO または正規化された CLUSTERFACTOR > 80
F5: 100 * (KEYS * (ISIZE + 9) + (CARD - KEYS) * 5) / ((NLEAF - NUM EMPTY LEAFS) * INDEXPAGESIZE) > 50
F6: (100 - PCTFREE) * ((INDEXPAGESIZE - 96) / (ISIZE + 12)) ** (NLEVELS - 2) * (INDEXPAGESIZE - 96) / (KEYS * (ISIZE + 9) + (CARD - KEYS) * 5) < 100
F7: 100 * (NUMRIDS DELETED / (NUMRIDS DELETED + CARD)) < 20
F8: 100 * (NUM EMPTY LEAFS / NLEAF) < 20
 
SCHEMA   NAME                 CARD  LEAF ELEAF  LVLS ISIZE  NDEL
   KEYS  F4  F5  F6  F7  F8 REORG
----------------------------------------------------------------
---------------------------------
表: DB2INST1.DAILY
DB2INST1 DAILY_IDX_CITY_KJ    3356    31     0     2    14     0
   3355  70  60   4   0   0 *----
DB2INST1 DAILY_IDX_JISCD      3356    20     0     2     5     0
   3348 100  57   7   0   0 -----
DB2INST1 DAILY_IDX_PREF_KJ    3356     8     0     2     9     0
     47  99  53  20   0   0 -----
----------------------------------------------------------------
---------------------------------
（中略）
REORGCHKコマンド使用例

　上記の実行例の場合、索引DAILY_IDX_CITY_KJのクラスタ率（CLUSTERRATIO）が低く、「*」マークが付いているので再編成の対象として検討する必要があります。

●表と索引のメンテナンス

　再編成を行ったとしても、必ずしも評価式を満たす結果が得られるとは限りません。そのため判断が難しいところですが、運用上許されるならばできるだけ再編成を実行します。

　今回は索引なので、以下のように再編成を実行します。

$ db2 reorg indexes all for table db2inst1.daily
DB20000I REORG コマンドが正常に終了しました。

　例では、実行前と比較してF5の評価式の値に向上が見られます。再編成を実行する動機となったF4の評価式は、残念ながら変化が見られませんでした。データの内容や分散度によっても結果が変わるので、このケースではたまたま変化がなかったと考えればいいでしょう。

DB2INST1 DAILY_IDX_CITY_KJ    3356    31     0     2    14     0
   3355  70  60   4   0   0 *----
実行前
DB2INST1 DAILY_IDX_CITY_KJ    3356    25     0     2    14     0
   3355  70  75   4   0   0 *----
実行後

　表の再編成は以下のように実行します。

$ db2 reorg table db2inst1.daily
DB20000I REORG コマンドが正常に終了しました。

　再編成後は、必ず表と索引の統計情報を更新します。

$ db2 runstats on table db2inst1.daily with distribution and detailed indexes all
DB20000I RUNSTATS コマンドが正常に終了しました。

　これで、表と索引が最適な状態にメンテナンスされました。

■トランザクション・ログの監視とメンテナンス

　トランザクション・ログに対するメンテナンス作業は、必要なくなったログを定期的に削除することです。よって、監視作業もログ・スペースの使用状況が主な対象になります。

●ログ・スペースの監視

　ログ・スペースは、監視パラメータのdb.log_fs_utilやdb.log_utilのしきい値をあらかじめ設定しておくことで、ヘルス・モニターで監視できます。Linuxにおいては、ログ・スペースはOSが管理するディレクトリ・スペースなので、OSレベルでの監視も可能です。dfコマンドなどで、定期的にログ・スペースのあるディレクトリを監視します。

●不要なログの整理

　バックアップ済みのアーカイブログや、すでにバックアップイメージが存在する期間のアーカイブログは、使用頻度が低いので別の場所に退避することをお勧めします。

　今回は、データベース・オブジェクトの監視とメンテナンスについて説明しました。次回は、データベースのチューニングについて説明します。

「次回」へ


「DB2マイスター養成講座」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ | 　　　　　　
ページトップに戻る