DB2 データベースの保守

受け入れられるパフォーマンスを確保するには、TADDM DB2 データベースを定期的に保守する必要があります。

以下の DB2 ユーティリティーが使用可能です。
REORG
可変長列の挿入、削除、および更新の各アクティビティーによって表データに数多くの変更が行われた後では、論理的に連続しているデータが、連続していない物理データ・ページ上にある場合があります。 このため、データベース・マネージャーが、データにアクセスするために追加の読み取り操作を実行します。 REORG ユーティリティーを使用して DB2 テーブルを再編成し、フラグメント化を解消して、スペースのレクラメーション処理を行います。 RUNSTATS の実行にかかる時間が通常より長い場合や、DB2 の REORGCHK コマンドによって必要性が示された場合は、必要に応じて REORG ユーティリティーを使用します。 REORG ユーティリティーの実行時には TADDM サーバーをシャットダウンしてください。オフラインでのテーブルや索引の再編成 (データのデフラグ) 中には、アプリケーションがテーブル内のデータにアクセスはできますが、更新はできないためです。 ディスカバリーがなくても TopologyBuilder は頻繁に実行されるため、このようなロックは、アプリケーション内で予測不能な結果を発生される可能性があります。
RUNSTATS (手動統計コレクション)
DB2 最適化プログラムは、指定された照会に基づいて DB2 カタログ内の情報および統計を使用して、データベースへの最適なアクセスを判別します。 RUNSTATS ユーティリティーを実行すると、ローカル・データベース内の特定の表および索引に関する統計情報が収集されます。 かなり多くのテーブル行が追加または除去されたときや、統計の収集対象となる列のデータが更新された場合は、RUNSTATS コマンドを使用して統計を更新する必要があります。 最適なパフォーマンスを得るためには、RUNSTATS タスクを週次または日次 (データベース・アクティビティーが活発な状態の場合) で実行します。 統計が更新されていないと、TADDM のパフォーマンスが大きく低下する可能性があります。 RUNSTATS ユーティリティーは、TADDM サーバーの実行中に実行できます。 TADDM は、後で説明するように特定の RUNSTATS 形式を必要とします。また、DB2 の AUTO_RUNSTATS オプションをオフにする必要があります。
AUTO_RUNSTATS (自動統計コレクション)
自動統計コレクション (auto-runstats とも呼ばれます) を有効にして、TADDM データベース統計を更新する必要があるかどうかを DB2 に判断させることができます。 RUNSTATS ユーティリティーがバックグラウンドで実行され、データベース統計が常に更新されます。
自動統計コレクションを有効にするには、パラメーター AUTO_MAINTAUTO_TBL_MAINT、および AUTO_RUNSTATSON に設定する必要があります。 以下のコマンドを実行します。
CONNECT TO <db alias>
UPDATE DB CONFIG USING AUTO_MAINT ON AUTO_TBL_MAINT ON AUTO_RUNSTATS ON
ここで、<db alias> はデータベースの名前です。
制約事項: このユーティリティーは、 DB2 APAR IT05733 がインストールされ、 DB2_SELECTIVITY=DSCC パラメーターが設定されている場合にのみ使用できます。 DB2 APAR IT05733 は、以下のリリースおよびそれ以降のリリースの DB2 に含まれています。
  • 9.7 フィックスパック 11
  • 10.1 フィックスパック 6
  • 10.5 フィックスパック 7
DB2 バージョン 10.xDB2_SELECTIVITY=DSCC パラメーターを設定するには、次のコマンドを実行します。
db2set -immediate DB2_SELECTIVITY=DSCC
注: DB2 9.7 では、 -immediate パラメーターはサポートされていません。 このバージョンで DB2_SELECTIVITY=DSCC パラメーターを設定するには、db2set DB2_SELECTIVITY=DSCC コマンドを実行し、DB2 を再始動します。
注: TADDM ユーザーが TADDM インストール済み環境で DB2 バージョンをアップグレードする場合は、互換性のあるバージョンのドライバーも更新する必要があります。 TADDM DB2 サーバーから db2jcc.jar を DBA に依頼することも、ご使用のバージョンの DB2 に該当するものをhttp://www-01.ibm.com/support/docview.wss?uid=swg21363866. からダウンロードすることもできます。 TADDM を停止し、 dist/lib/jdbc/にコピーして、TADDM ユーザーがファイルを読み取ることができるように許可が正しいことを確認してから、TADDM を始動します。 環境内のすべての TADDM サーバーで、この手順を繰り返します。
DB2 ヘルス・モニター
RUNSTATSREORG などの調整が必要な状態に変化した場合、プロアクティブにモニターするために TADDM データベースに対して DB2 ヘルス・モニターを実行することをお勧めします。 ヘルス・モニターは、システムの正常性に関する潜在的な問題をデータベース管理者に警告できます。 ヘルス・モニターは、ハードウェア障害を引き起こしたり、システム・パフォーマンスまたは機能を許容できないほど低下させたりする可能性がある問題をプロアクティブに検出します。 プロアクティブなヘルス・モニターによって、システム・パフォーマンスに影響が及ぶ問題になる前に、問題に対応できます。
DB2 PERFORMANCE ANALYSIS SUITE
DB2 の問題が疑われる場合、Performance Analyst ツールによって、問題の時点で取得された DB2 スナップショットを迅速に分析し、アクションを推奨できます。 このツールは、 https://www.ibm.com/developerworks/community/groups/community/perfanalystからダウンロードできます。
TADDM の DB2 スナップショットを取得するには、次の手順を実行します。
  1. DB2 サーバーから TADDM データベースに接続し、次のコマンドを実行します。
    db2 -tf updmon.sql
    ここで、updmon.sql ファイルには、以下の項目が含まれています。
    UPDATE MONITOR SWITCHES USING BUFFERPOOL ON ;
    UPDATE MONITOR SWITCHES USING LOCK       ON ;
    UPDATE MONITOR SWITCHES USING SORT       ON ;
    UPDATE MONITOR SWITCHES USING STATEMENT  ON ;
    UPDATE MONITOR SWITCHES USING TABLE      ON ;
    UPDATE MONITOR SWITCHES USING UOW        ON ;
    UPDATE MONITOR SWITCHES USING TIMESTAMP  ON ;
    RESET MONITOR ALL
  2. ステップ 1 が完了したら、DB2 get monitor switches コマンドを実行して、モニターのスイッチがすべて設定されているかどうかを確認します。 スイッチの状況がすべて、ON でなければなりません。
  3. パフォーマンスの問題があるプロセスを実行します。
  4. 遅いプロセスの実行中に、適切な間隔で次のコマンドを DB2 から実行します。
    db2 get snapshot for all on <dbname> > <dbname>-dbsnap.out
    このコマンドは、ステップ 1 でコマンドを実行したのと同じウィンドウから実行します。 このコマンドを、スクリプトを使用して実行することはできません。
  5. 毎回異なるタイムスタンプの出力ファイルを使用して、スナップショットを複数回取得します。 プロセス中に 3 から 4 回スナップショットを取得する間隔で実行しますが、実行間の時間が 1 時間を超えないようにします。
スナップショットが収集されたら、Performance Analyst ツールを使用して最後のスナップショットから順にスナップショットを分析します。 例えば、何度も実行される照会の「ステートメント」タブで CPU 使用率および平均実行時間が高いのは、通常、最適化の問題を示しています。これは、RUNSTATS ユーティリティーで解決できます。 「表」タブのオーバーフロー・パーセントが高いのは、REORG ユーティリティーが必要であることを示している可能性があります。 「バッファー・プール」タブを調べて、アラートがないことを確認してください。バッファー・プールが小さすぎるとパフォーマンスが低下する場合があります。
始める前に
スキーマの変更が生じる大規模な保守の後、例えばフィックスパックの適用後などは、TADDM ストレージ・サーバーで TADDM_table_statistics.sql ファイルを生成する必要があります。 このファイルは、定期的に実行する必要がある RUNSTATS データベース保守タスクに必要です。 TADDM は、データベース統計の更新に特殊な形式を必要とします。TADDM では広範囲にわたって使用される、クラス名などの大容量の共通プレフィックスがある列を処理するときの DB2 の制限のためです。 このため、DB2 の AUTO_RUNSTATS オプションを使用せずに、次の手順を実行することで生成される RUNSTATS 構文を使用してください。 ただし、DB2 APAR IT05733 がインストールされ、DB2_SELECTIVITY=DSCC パラメーターが設定されている場合は、AUTO_RUNSTATS オプションを使用できます。
注: Linux および UNIX オペレーティング・システムの場合は、以下の手順に従ってください。 Windows オペレーティング・システムでデータベース保守を実行するには、.sh スクリプトの代わりに、対応する .bat スクリプトを使用します。
TADDM_table_stats.sql ファイルを生成するには、以下のステップを実行します。
  1. 以下のコマンドを実行します。
    cd $COLLATION_HOME/bin
  2. 次のコマンドを実行します。ここで、tmpdir は、このファイルを作成可能なディレクトリーです。
    ./gen_db_stats.jy > tmpdir/TADDM_table_stats.sql

    ストリーミング・サーバー・デプロイメントでは、このコマンドを 1 次ストレージ・サーバーで実行します。

  3. このファイルをデータベース・サーバーにコピーするか、データベース管理者 (DBA) に提供して TADDM データベースに対して実行します (手順の ステップ 2 を参照)。 テーブルに大規模な変更がある場合は、データベース統計を週次、またはより頻繁に更新してください。

DB2 データベースに対する保守を実行するには、以下のステップを実行します。

  1. REORG ユーティリティーを使用するには、以下の手順を実行します。
    1. データベース・サーバーで、 REORG TABLE コマンドを生成する以下の SQL 照会をファイルに入れます。
      select 'reorg table '||CAST(RTRIM(creator) AS VARCHAR(40))||'. 
       "'||substr(name,1,60)||'" ; ' from sysibm.systables where creator
       = 'dbuser' and type = 'T' and name not in ('CHANGE_SEQ_ID') 
       order by 1;
      ここで、dbusercom.collation.db.user= の値です。
      注: dbuser の大/小文字が、データベースの sysibm.systables 表の列 creatorに指定されている値と同じであることを確認してください。
    2. TADDM サーバーを停止します。
    3. DB2 コマンド・ラインでデータベースに接続し、以下のコマンドを実行します。
      db2 –x –tf temp.sql > cmdbreorg.sql
      db2 –tvf cmdbreorg.sql > cmdbreorg.out
    4. cmdbreorg.out ファイルでエラーを確認して、 REORG ユーティリティーが正常に実行されたことを確認します。
    5. TADDM サーバーを起動します。
  2. RUNSTATS ユーティリティーを使用するには、以下の手順を実行します。 このプロセスを少なくとも週次で自動的に実行するようにします。
    1. データベース・サーバーで、前に生成した出力を使用して TADDM 固有の RUNSTATS コマンドを実行します。
      db2 -tvf tmpdir/TADDM_table_stats.sql  > table_stats.out
    2. table_stats.out ファイルでエラーを確認して、 RUNSTATS ユーティリティーが正常に実行されたことを確認します。