DB2セルフスタディ・キット: データベース管理

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 中級

Editorial staff, editorial staff, IBM

2008年 10月 18日

本資料は、DB2のデータベース管理のバックアップ/リカバリ、メンテナンス、監視の運用設計をすることを目的に、設計に必要となる項目や、設計、運用の手順についてご紹介しています。

データベース管理を始める前に

本資料では、運用管理を大きく3つのタスクに分けて解説していきます。

• バックアップ/リカバリ運用
• メンテナンス運用（表の再編成、統計情報の更新、ログ・ファイルのメンテナンス）
• 監視

必要な材料を確認しよう
運用管理を設計する前に、まずどのような管理が必要とされているのかを、以下の項目にしたがって整理してください。
この章での整理事項をもとに、次章「データベース管理」では、何を実施すればよいのか、その方法、実施のタイミングを選択し、運用管理を設計してください。

バックアップ/リカバリ運用
以下のような運用要件について整理し、決定しておく必要があります。

• データ復元の必要性
  データの重要性や、バックアップを取らなくても再生成（復元）可能かどうかという観点で判断してください。
  例）別のシステムからバッチ処理でデータを入れているため、データをロストしたとしても、問題はない。
• 運用時間
  システムの稼動時間です。サービス時間やオンライン時間とは異なります。
  例）24時間365日稼動で運用されている。
• サービス時間
  システムがサービスを提供する時間です。
  例）サービス時間は6時から24時までになっており、夜間は業務を停止している。
• 回復目標時間
  データをどの時点まで復元させるか、その目標時間です。
  例）前日の18時時点のデータの状態に戻したい。

メンテナンス運用
以下のような運用要件について整理し、決定しておく必要があります。

• メンテナンス時間
  システムのメンテナンスのために確保できる時間です。
  例）メンテナンス時間を月次で確保している。
• データの更新量
  それぞれの表のデータの更新処理の平均量、または表全体への割合です。
  例）更新処理が多く、日次の更新量が10%以上である。

監視
以下のような項目について整理し、決定しておく必要があります。

• 既存のシステムでの監視方法、対象
  シェルスクリプトやツールなどの監視方法や、リソースなどの監視対象です。
• 可用性
  障害の発生しにくさや、障害発生時に求められる修復速度です。

上に戻る

データベース管理

<バックアップ>
1.バックアップ方式の選択 前章でまとめた整理事項から、以下のチャートを参考に、バックアップ方式を選択してください。

1. 前章でまとめたデータの復元の必要性からバックアップ運用の必要性を判断してください。
2. バックアップ取得が必要な場合、運用時間とサービス時間をもとに、バックアップ取得可能なオフライン時間が確保できるかどうか判断してください。
   確保できない場合は、オンラインでのバックアップ取得になります。「2.ロギング方式」を参考にアーカイブ・ロギング方式に設定変更後、「4.オンラインバックアップ」に進んでください。
3. オフライン時間が確保できる場合、回復目標時間が、バックアップ取得時であるのか、またはそれ以降の時点であるか確認してください。
   「2.ロギング方式」でそれぞれのロギング方式に設定後、「3.オフラインバックアップ」に進んでください。

2.ロギング方式
DB2では、データベースに対して行われた変更内容をログに記録します。これにより、データベースを一貫性のある状態に復元することができます。DB2では、循環ロギングとアーカイブ・ロギングの2つのロギング方式がサポートされています。以下に2つのロギング方式と、変更方法について説明します。

【アーカイブ・ロギング】
アーカイブ・ロギングでは、ログ・ファイルは再利用されません。アーカイブ・ログを使用することによって、バックアップ取得時以降の変更内容をリカバリすることができます。

【ロギング方式の設定方法】
「1.バックアップ方式の選択」で決定したバックアップ方法のロギング形式に設定を変更してください。オフラインバックアップの循環ロギングの場合には、デフォルトの設定になるため、現在の設定を確認してください。

（1）現在の設定の確認

db2 get db cfg for <database-alias>
            

循環ロギングの出力（デフォルトの設定）

First log archive method             (LOGARCHMETH1) = OFF
            

（2）設定の変更（LOGRETAINへの設定例）
循環ロギングからアーカイブ・ロギングへの変更

db2 update db cfg using LOGARCHMETH1 LOGRETAIN
            

変更の確認

db2 get db cfg
First log archive method         (LOGARCHMETH1) = LOGRETAIN
            

LOGARCHMETH1の設定がOFF以外になっていれば、アーカイブ・ロギングの設定になります。LOGRETAINの他に、DISK、TSM、VENDER、USEREXITなどの設定することができます。

3.オフラインバックアップ手順

（1）現在データベースに接続しているアプリケーションの停止

（2）データベースを静止モードに設定

db2 connect to <database-alias>
db2 quiesce database immediate
db2 connect reset
            

静止モードを設定した場合、許可されたユーザーのみがアクセスすることができます。静止モードの設定はデータベースレベルあるいはインスタンスレベルで設定可能です。上記の例では、データベースレベルで実行していますが、複数のデータベースへのアクセスを制御したい場合はインスタンスレベルで設定してください。

（3）接続アプリケーションの確認

db2 list applications
            

（4）オフラインバックアップの取得

db2 backup database <database-alias> to <バックアップ先ディレクトリ>
            

【出力例】
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20080408141928 です。

（5）静止モードの解除

db2 connect to <database-alias>
db2 unquiesce database immediate
db2 connect reset
            

4.オンラインバックアップ

（1）オンラインバックアップの取得
オンラインバックアップでは、リカバリの際に、バックアップ取得開始の時点から終了時点までのログを適用する必要があります。バックアップ取得時にinclude logsのオプションを指定することによって、バックアップ・イメージに、必要最低限のログ・ファイルを含めることがでます。

ログ・ファイルをバックアップ・イメージに含める場合

db2 backup database <database-alias> online to <バックアップ先ディレクトリ> include logs
            

ログ・ファイルをバックアップ・イメージに含めない場合

db2 backup database <database-alias> online to <バックアップ先ディレクトリ>
            

【出力例】
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20080408141928 です。

（2）リカバリに最低限必要なトランザクションログを判別
BACKUPコマンド実行時に、include logsを指定しなかった場合は、以下のコマンドでリカバリに必要なログ・ファイルを確認し、該当ログ・ファイルの保管について考慮してください。

db2 list history backup all for <database-alias>
            

上に戻る

リカバリ

1. リカバリ方式
「バックアップ」で選択したバックアップ形式をもとに、障害時のリカバリ運用を設計してください。

• オフラインバックアップ（循環ロギング）
  この場合は、リカバリはバックアップ取得時点へ戻すという方法になります。（「バージョン・リカバリ」と言います。）
  →手順2へ進んでください
  
  
• オフラインバックアップ（アーカイブ・ロギング）
  この場合は、リカバリの際に、バックアップ取得した時点以降から、障害直前の時点まで戻すことが出来ます。（「ロールフォワード・リカバリ」と言います。）
  →手順3へ進んでください
  
  
• オンラインバックアップ
  オンラインでバックアップを取得した場合、バックアップ取得開始時点から、終了時点までのログの適用（ロールフォワード）が必要になります。バックアップ取得した時点以降から、障害直前の時点まで戻すことができます。
  →手順4へ進んでください

2. バージョン・リカバリ手順
（1）現在データベースに接続しているアプリケーションの停止

（2）データベースを保守モードに設定

db2 connect to <database-alias>
db2 quiesce database immediate
db2 connect reset
            

db2 restore db <database-alias> from <backup-directory> taken at <timestamp>
            

3. オフラインバックアップからのロールフォワード・リカバリ手順
（1）現在データベースに接続しているアプリケーションの停止

（2）データベースを保守モードに設定

db2 connect to <database-alias>
db2 quiesce database immediate
db2 connect reset
            

db2 restore db <database-alias> from <backup-directory> taken at <timestamp>
            

db2 rollforward db <database-alias> query status
            

db2 rollforward db <database-alias> to end of logs and stop
            

db2 rollforward db <database-alias> to <timestamp> using local time and stop
            

4. オンラインバックアップの場合のリストア手順
（1）現在データベースに接続しているアプリケーションの停止

（2）データベースを保守モードに設定

db2 connect to <database-alias>
db2 quiesce database immediate
db2 connect reset
            

db2 restore db <database-alias> from <backup-directory> taken at <timestamp>
            

db2 restore db <database-alias> from <backup-directory> 
taken at <timestamp> logtarget <log-target>
            

db2 rollforward db <database-alias> query status
            

db2 rollforward db <database-alias> to end of logs and stop

db2 rollforward db <database-alias> to <timestamp> using local time and stop

上に戻る

表の再編成

1. 再編成方式の選択

1. データの更新、削除、挿入が多く、フラグメンテーションが発生する場合には、再編成処理の運用を考慮してください。
   以下の場合は、再編成処理を考慮しなくてもよいケースです。
   
   • 更新処理がなく、読み取りのみの表
   • ユニーク索引列を条件とした、1件索引
   • ④代替策がとられている表
2. オフラインのメンテナンス時間が確保されているか確認してください。確保されている場合は、オフラインでの再編成を検討してください。
3. オフラインのメンテナンス時間が確保できるか検討してください。再編成のメンテナンス運用をオンラインできない場合は、④の代替策を検討してください。
4. 以下のような機能や運用方式を活用することで、フラグメンテーションの発生を回避し、再編成処理そのものを不要とできる可能性があります。
   • 多次元クラスタリング表（MDC）
   • テーブル・パーティショニング
   • UNION　ALL　VIEW
   • クラスター索引
   • LOAD　REPLACE

2. 表の再編成実行の前に
再編成処理の前に、どの表に再編成が必要なのか特定する必要があります。REORGCHKコマンドの評価結果から、再編成を実施するかどうか判断し、REORGを実施してください。またREORG実行後は、統計情報にも反映させるため、RUNSTATSの実行を運用手順に入れてください。RUNSTASに関しては、次章「統計情報の更新」で説明します。

• 表の再編成チェックの実行
  1. インスタンスユーザーでログイン
     
     
  2. 表の再編成チェックを実行（reorgchk1.logに出力）
     
     

     db2 reorgchk current statistics on table all > reorgchk1.log

     
     
  3. rerogchk1.logの内容を確認
     
     

     view reorgchk1.log

     
     REORGCHKの結果、REORGカラムに「*」が出力されている場合は、REORGの実行が推奨されます。「*」の数が多いほど、推奨度は高くなります。
     REORGCHKの出力結果より、REORGが必要だと判断した場合は、以下の再編成の準備を参考に、該当する表のスキーマ名、索引の確認をしてください。そして「1再編成方式の選択」での決定をもとに、「3オフラインでの再編成処理」、または「4オンラインでの再編成処理」に進んでください。
     
     
• 再編成の準備
  1. データベースに接続
     
     

     db2 connect to <database-alias>

     
     
     
  2. 再編成する表のスキーマ名の確認
     
     

     db2 “select tabname,tabschema from syscat.tables” | grep <table-name> <table-name> <schema-name>

     
     
     
  3. 再編成する表の索引の確認
     
     

     db2 “select tabname,indname,indschema from syscat.indexes” | grep <table-name> <table-name> <table-name> <schema-name>

     
     

3. オフラインでの再編成処理
再編成処理の前に、どの表に再編成が必要なのか特定する必要があります。REORGCHKコマンドの評価結果から、再編成を実施するかどうか判断し、REORGを実施してください。またREORG実行後は、統計情報にも反映させるため、RUNSTATSの実行を運用手順に入れてください。RUNSTASに関しては、次章「統計情報の更新」で説明します。

1. 現在データベースに接続しているアプリケーションの停止
   
   
2. 表の再編成の実行（rerog.logは任意のファイル名）
   
   

   db2 “reorg table <schema-name>.<table-name> index <schema- name>.<index-name> use <tempspace-name>” >　rerog.log

   
   <tempspace-name>には作業領域として使用する一時表スペースを指定します。目安としてREROGする表の約2倍の一時表スペースを指定してください。
   
   
3. rerog.logの内容確認
   
   

   view reorg.log

   
   
4. 表の再編成チェックを実行
   
   

   db2 reorgchk current statistics on table all > reorgchk2.log

   
   
5. rerogchk2.logの内容を確認（reorgchk2.logは任意のファイル名）
   
   

   view reorgchk2.log

   
   

4. オンラインでの再編成処理

1. 表の再編成の実行（reorg.logは任意のファイル名）
   
   

   db2 “reorg table <schema-name>.<table-name> index <schema- name>.<index-name> inplace allow write access start” >　reorg.log

   
   
2. reorg.logの内容確認
   
   

   view reorg.log

   
   
3. 表の再編成チェックを実行
   
   

   db2 reorgchk current statistics on table all > reorgchk2.log

   
   
4. rerogchk2.logの内容を確認（reorgchk2.logは任意のファイル名）
   
   

   view reorgchk2.log

   
   

上に戻る

統計情報の更新

1. 統計情報の更新が必要かどうか
統計情報の更新の実施の判断としては、以下の項目を参考にしてください。

• データの更新量
  バッチ処理などによる大量更新や挿入をした場合です。目安としては表および索引データの10-20%が更新、挿入、削除処理されたときと考えてください。
• 再編成処理の実施
  前章の再編成処理を行った後は、統計情報に反映するために、統計情報の更新を実行してください。
• 新しい索引の作成、列の追加

DB2 V9.1以降は自動統計情報更新がデフォルトで有効になっているためDB2が必要に応じて、自動的にRUNSTATSが実施されます。

【確認方法】

db2 get db cfg
Automatic maintenance       　　(AUTO_MAINT) = ON
Automatic table maintenance   (AUTO_TBL_MAINT) = ON
Automatic runstats           　　(AUTO_RUNSTATS) = ON

2. 統計情報の更新の手順

1. db2lookの取得
   統計情報の更新をした後に、パフォーマンスの変化が発生した際の問題判別のために、RUNSTATS実行前に統計情報を取得しておいてください。
   
   

   db2look –d <database-alias> -m –t <table-name>

   
   
2. RUNSTATSの実行
   
   

   db2　runstats on table &schema-name>.<table-name> and index all >　runstats.log

   
   rustats.logの内容確認
   
   

   view runstats.log

   
   
3. 動的SQLを使用しているか、または静的SQLを使用しているか
   統計情報が変わると、SQLの最適なアクセスパスも変わります。そのため静的SQLを使用している場合には、統計情報更新後、パッケージを再度バインドし、アクセスパスを最適なものに更新します。動的SQLを使用している場合には、統計情報の更新実行字にアクセスパスの確認を行うため、再バインド処理は不要です。
4. BIND/再BIND
   再BINDは以前にバインドされたアプリケーションプログラムのパッケージを再作成する処理です。（rebind.logは任意のファイル名です）
   
   

   db2 rebind <database-alias> -l rebind.log view rebind.log

   
   

上に戻る

ログ・ファイルのメンテナンス

1. メンテナンスが必要なログ・ファイル

【$INSTANCE/sqllib/db2dump以下に出力されるログ】

• db2diag.log
• 管理通知ログ
• ダンプファイル、トラップファイル、コアファイル

上記のログ・ファイルは自動的に整理・削除されないため、定期的に整理してください。運用上、または問題判別上、不要となった内容は削除するように管理する必要があります。

【回復履歴ファイル】
回復履歴ファイルは、データベース単位に作成され、リカバリや管理のさまざまなイベントが記録されます。BACKUP DBコマンドでバックアップを取得している場合、データベース構成パラメーターのREC_HIS_RETENTNもしくは、NUM_DB_BACKUPSで設定した、期間、世代を超えたバックアップ情報は、「フルバックアップ/リストア/ロールフォワード」のタイミングで“有効期限切れ”となり、フルバックアップ実行時に自動的に削除（prune）されます。回復要件に応じて、上記パラメーターを設定してください。

2. 機能使用時に、メンテナンスが必要なログ・ファイル

【アーカイブ・ログ】
ロギング形式をアーカイブ・ロギング形式に設定した場合、アーカイブログファイルは蓄積されていくため、メンテナンスが必要になります。V9.5からは回復処理に不要となったアーカイブログファイルを自動的に削除する機能が提供されています。
詳細に関しては以下をご参照ください。
「DB2 9.5 技術資料　導入と管理機能の強化」第2章管理機能強化　回復オブジェクトの自動削除

【監査ログ】
監査機能（db2audit）使用時に必要となります。監査情報が取得されると、db2audit.logのファイル・サイズが増加するため、運用上、不要となったタイミングで削除する必要があります。DB2V9.1までは、pruneオプションを指定した db2auditコマンド実行により削除することができます。V9.5からは、archiveオプションを指定した db2auditコマンド実行により、一旦アーカイブした後に、ファイルを削除する手順となります。

【USEREXIT活動ログ】
USEREXIT使用時にメンテナンスが必要となります。問題判別上不要となった段階で、ARCHIVE.LOG、RETRIEVE.LOG、USEREXIT.ERRを削除してください。

上に戻る

監視

1. 監視対象、監視方法の決定
「必要な材料を確認しよう」で整理した以下の事項をもとに、監視対象、監視方法を決定してください。

• 既存のシステムでの監視方法、対象
  既存のシステムで監視していた項目、方法をもとに、何を監視するか決定してください。

• 可用性
  高い可用性が求められるようなシステムの場合、重大なエラーやレスポンスの低下となる情報を事前に検出し、障害を未然に防止しすることが求められます。また障害時には原因を判別し、対応する必要があります。DB2ではさまざまな機能が用意されていますが、本資料では以下の項目を取り上げます。

事前の障害検知　→　ヘルス・モニター
問題発生時の原因分析　→　管理通知ログ

他のモニタリング機能に関しては以下の資料を参考にしてください。
「DB2 V9 運用管理ガイド：パフォーマンス･モニタリング」

2.ヘルス・モニター
ヘルス・モニターは、DB2が正常に稼動しているかどうか監視し、異常があれば通知します。ヘルス・モニターはヘルス・インジケーターを使用して、データベースの正常性を判断します。
ヘルス・インジケーターの項目に関しては以下をご覧下さい。
「Information Center ヘルス・インジケーターの要約」

【設定方法】

• 手順（設定）
  
  1. データベースマネージャー構成パラメーターの設定
     V8.2移行はデフォルトONの設定です。
     
     

     db2 update dbm cfg using health_mon on

     
     
  2. ヘルス・インジケーターの設定
     
     

     db2 update alert cfg for database manager using <Health- indicator-Name> set <Parameter-Name> <Valure>

     
     
     
     

     <Health-indicator-Name>:ヘルス・インジケーター名 <Parameter-Name>：アラート構成 <Valure>：設定値

     
     
  3. ヘルス・インジケーターの設定確認
     
     

     db2 get alert cfg for database manager using <Health- indicator-Name> set <Parameter-Name> <Valure>

     
     
• 手順（運用時）
  1. 現在の各ヘルス・インジケーターの状態確認
     
     

     db2 get health snapshot for all on sample

     
     
  2. アラートが上がっていた場合の対処方法のヒント入手
     
     

     db2 get recommendations for health indicator <Health-indicator-Name>

     
     
  3. 管理通知ログの監視
     アラートは管理通知ログに出力されます。次項「管理通知ログ」をご覧下さい。

【ヘルス・センター】
ヘルス・モニター機能をGUIで操作するために、ヘルス・センターが用意されています。
ヘルス・インジケーターの設定変更や、アラートが発生した際の、詳細表示や推奨アクションの情報を入手することができます。

3.管理通知ログ(notifylog)
重要な問題が発生すると、DB2 は管理通知ログに情報を書き込みます。この情報はデータベース管理者およびシステム管理者のために提供されています。イベントのタイプと収集される情報の詳細さのレベルは、データベースマネージャー構成パラメーターの NOTIFYLEVELによって決定されます。デフォルトでは3に設定されているため、より詳細な情報を出力したい場合は、4に変更してください。

2006-06-05-22.09.13.224000   Instance:DB2   Node:000
PID:1104(db2syscs.exe)   TID:5340   Appid:*LOCAL.DB2.060605130746
data protection  sqlpgResSpace Probe:2860   Database:SAMPLE

ADM1823E  アクティブ・ログがフルになっており、アプリケーション・ハンドル "9"
によって保留されています。 COMMIT、ROLLBACK または FORCE APPLICATION
を実行して、このアプリケーションを終了してください。
            

4.OSでの監視
DB2で使用しているディスク使用率を把握するためには、ファイルシステムの使用率を監視する必要があります。以下のファイルシステムの監視を検討してください。

【監視対象のファイルシステム】

• /(root)
• /var
• /tmp
• /home
• /usr
• インスタンスホームディレクトリ
• DB2アーカイブログディレクトリ/DB2アクティブログディクトリ
• ユーザーデータ用ディレクトリ（SMS表スペース）

SMS表スペースを作成している場合、dfコマンドで、表スペースの作成されているファイルシステムを監視してください。DMS表スペースは、OSのコマンドでは監視できないため、ヘルス・モニターで設定するか、またはdb2 list tablespaces show detail コマンドを用いて、表スペース使用率の監視を行ってください。

著者について

		developerWorks Information Management team

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る