ここからは、各データベース・オブジェクトの監視とメンテナンスについて説明します。データベース・オブジェクトは、以下のとおりです。
オブジェクト | 監視 | パラメータ | メンテナンス | |
---|---|---|---|---|
データベース | 操作可能 | 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
にガイドがあるので参考にしてください。
問題判別については、最終回のトラブルシューティングで解説します。
表スペースに対する主なメンテナンス作業は、データ量の増加に伴うコンテナの追加です。よって、表スペースの使用状況が主な監視対象となります。
以下の例では、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
を参考にしてください。
●表スペースの使用率監視に対応するメンテナンス
表スペース(コンテナ)の使用率が増えたり、逆にまったく利用されなくなって、コンテナ・サイズの変更やコンテナの追加・削除が必要になる場合があります。
alter tablespace [表スペース名] resize (file '[ファイル名]' [変更後のサイズ])
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 ----- ---------------------------------------------------------------- --------------------------------- (中略)
上記の実行例の場合、索引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コマンドなどで、定期的にログ・スペースのあるディレクトリを監視します。
●不要なログの整理
バックアップ済みのアーカイブログや、すでにバックアップイメージが存在する期間のアーカイブログは、使用頻度が低いので別の場所に退避することをお勧めします。
今回は、データベース・オブジェクトの監視とメンテナンスについて説明しました。次回は、データベースのチューニングについて説明します。
Copyright © ITmedia, Inc. All Rights Reserved.