バックアップおよびリカバリー時のデータ可用性の最大化のヒント

必要な可用性のレベルを決定する

発生する可能性がある故障の主な種類を判別することから始めます。 その後で、それらのタイプの故障ごとに、リカバリーに 費やせる最大時間数を決定します。 コストと可用性との 間のトレードオフを考慮してください。 連続可用性のリカバリー・プランは 費用が非常に高いので、システムで実際に必要な使用可能な時間 のパーセンテージについて考慮する必要があります。

データの可用性は、関連オブジェクトの可用性によって影響されます。 例えば、関連セット内の 1 つのオブジェクトに可用性の問題がある場合は、他のオブジェクトの可用性も影響を受ける場合があります。 関連オブジェクト・セットには基本表スペースと索引、参照制約で関連付けられたオブジェクト、LOB 表スペースと索引、XML 表スペースと索引が含まれています。

リカバリーの実行

バックアップ およびリカバリーの計画は、実施して見なければ操作可能かどうかは 分かりません。 さらに、リカバリー状態における作業のプレッシャーが間違いの原因になることが あります。 間違いを最小限にする最良の方法は、よく分かるようになるまではリカバリー・シナリオを 実習してみることです。 この実習を行うのに最善の時間は、主要なアプリケーションの実行 が少ない、正規の作業時間外の時間帯です。

予防できる停止の発生を最小限にする

バックアップとリカバリーの計画の 1 つの面は、可能ならば、リカバリーしなくても済むようにするべきです。 これを行う 1 つの方法は、Db2でのエラーによる停止 (障害) を防止することです。 必ず使用可能な保守について頻繁に確認し、停止の原因になりそうな問題に対して修正を施してください。

必要なバックアップ頻度を決定する

リカバリー基準を使用して、 データベースのコピーの作成頻度を決定 してください。

例えば、イメージ・コピーを使用していて、データ・ボリュームを失った後の最大許容リカバリー時間が 2 時間であり、通常、ボリュームには約 4 GB のデータが保持され、1 時間当たり 約 2 GB のデータを読み取ることができる場合は、4 GB のデータが書き込まれるごとに、コピーを作成する必要があります。 トランザクションやバッチジョブの実行中にコピーを作成するには、COPYオプションSHRLEVEL CHANGEまたはDFSMSdss concurrent copyを使用します。 数多くの変更を 行ったジョブの実行後も、コピーを作成する必要があります。 表スペースのコピーに加えて、索引のコピーも考慮する必要があります。

システム・レベルのバックアップを行うには、BACKUP SYSTEM ユーティリティーを使用します。 FlashCopy® テクノロジーが採用されているため、システム全体が非常に迅速にバックアップされ、事実上、データが利用できない状態になることはありません。

COPYTOCOPY ユーティリティーを使用することにより、1 次イメージ・コピーから 追加のバックアップ・イメージを作成することができます。 この機能は、ローカル・サイトの災害時回復サイトとして使用するリモート・サイトに、 バックアップ・イメージをコピーする場合に特に有効です。 アプリケーションは、COPYTOCOPY ユーティリティーと並行して実行することができます。 SYSCOPY カタログ表に書き込みを行うユーティリティーだけは、COPYTOCOPY と並行して実行することができません。

リダイレクト・リカバリーを使用したリカバリー時間の見積もり

リカバリーが必要な場合は、正確なリカバリー時間の見積もりが重要になります。 見積もったリカバリー時間を使用して、リカバリー時間目標を検証することができます。

リダイレクトされたリカバリーのジョブ出力からリカバリー時間見積もり (RTE) を計算するには、以下の式を使用します。 識別されたフェーズの経過時間 (ET) は、実リカバリーに対して実行されていない処理を除外するために、RECOVER ユーティリティー経過時間の合計から差し引く必要があります。

• ポイント・イン・タイム・リカバリーの RTE = 合計 ET - TRANSLAT ET
• 現在の状態にリカバリーするための RTE = 合計 ET - LOGCSR ET - LOGUNDO ET - TRANSLAT ET

メッセージを使用して、式の各変数を検索することができます。

• DSNU500I は、Total ET をレポートします
• DSNU1565I は、TRANSLAT ET をレポートします
• DSNU1552I は、LOGCSR ET をレポートします
• DSNU1557I は、LOGUNDO ET をレポートします

RECOVER ジョブの経過時間を最小化する

ディスクからシステム・レベル・バックアップをリカバリーする場合、RECOVER ユーティリティーは、メインタスクによってデータ・セットを順次リストアします。 テープからシステム・レベル・バックアップをリカバリーする場合、RECOVER ユーティリティーは複数のサブタスクを作成して、オブジェクトのイメージ・コピーとシステム・レベル・バックアップをリストアします。

システム・レベル・バックアップを使用する場合は、リカバリー時間を節約するために、最新のシステム・レベル・バックアップをディスク上に配置してください。

FlashCopy のイメージコピーの復元は非常に速く行われます。 ただし、一貫性のある FlashCopy イメージコピーを作成する（FLASHCOPY CONSISTENT）と、システムリソースをより多く使用し、FLASHCOPY YESを指定してイメージコピーを作成するよりも時間がかかる場合があります。 FLASHCOPY CONSISTENT を指定すると処理にかかる時間が長くなることがあります。これは、コミットされていない作業をバックアウトする際に、ログを読み取ってイメージ・コピーを更新する必要があるためです。

ポイント・イン・タイム・リカバリーの場合、静止ポイントおよび SHRLEVEL REFERENCE コピーにリカバリーする方が、他のポイント・イン・タイムにリカバリーするよりも高速です。

静止ポイント以外にリカバリーする場合は、次の要因がパフォーマンスに影響することがあります。

• リカバリー時点にアクティブであった UR の期間。
• ロールバックされるアクティブな UR を持つDb2メンバーの数。

COPY ジョブの経過時間を最小化する

COPY ユーティリティーを 使用すれば、オブジェクトのリストのイメージ・コピーを並列して作成することが できます。 イメージ・コピーは、ディスクまたはテープに作成することができます。

また、COPYユーティリティを使用して FlashCopy 画像コピーを作成することもできます。 コピー操作中であるためにデータを使用できない期間およびリカバリー操作に必要な時間の量の両方を FlashCopy により削減できます。

ユーザーのログの正しい特性を判別する

ユーザーのログの正しい特性を判別する場合は、次の基準を検討してください。

• 十分なディスク・スペースがある場合には、さらに大きなアクティブ・ログを使用してください。 アクティブ・ログからのリカバリーは、アーカイブ・ログからの リカバリーより迅速です。
• アーカイブ・ログからのリカバリーの速度を増すためには、ディスクへの アーカイブを考慮してください。
• テープにアーカイブする場合は、リカバリ中にアーカイブ・テープをマウントする使用可能なドライブをDb2が待つ必要がないように、十分なテープ・ドライブがあることを確認してください。
• バッファー・プールとログ・バッファーを効率良く実行できる ように十分大きくしてください。

最小化Db2再始動時間

多くのリカバリー処理は、Db2の再始動を伴います。 Db2のシャットダウンおよび始動にかかる時間を最小限にする必要があります。

Db2システムの再始動時にバックアウト・アクティビティーを制限できます。 Db2システムが作動可能になるまで、長時間実行されているリカバリー単位のバックアウトを延期することができます。 インストール・オプション LIMIT BACKOUT および BACKOUT DURATION を使用して、再始動処理時に遅らせるバックアウト作業を決定します。

以下の主な要因は、Db2シャットダウンの速度に影響を与えます。

• オープンしているDb2データ・セットの数

  シャットダウン時に、Db2は、高速シャットダウン機能が使用不可にされている場合に使用するすべてのデータ・セットをクローズして割り振り解除する必要があります。 デフォルトでは、高速シャットダウン機能を 使用するように設定されています。 高速シャットダウン機能を有効化および無効化する方法については、 IBM® サポートにお問い合わせください。 同時にオープンされるデータ・セットの最大数は、Db2サブシステム・パラメーター DSMAX によって決定されます。 データ・セットのクローズおよび割り振り解除には通常、データ・セットごとに 0.1 から 0.3 秒かかります。

  z/OS® グローバルリソースシリアライゼーション（GRS）により、 Db2 データセットのクローズ時間が長くなる場合があります。 Db2 データセットが複数のシステムで共有されていない場合は、 z/OS、GRS RESMILパラメータ値をOFFに設定するか、 Db2 データセットをSYSTEMS除外RNLに配置してください。

• アクティブ・スレッド

  Db2は、すべてのスレッドが終了するまでシャットダウンできません。 Db2コマンドの DISPLAY THREAD を発行して、Db2のシャットダウン中にアクティブなスレッドがあるかどうかを判別します。 可能なら、アクティブなスレッドを取り消して ください。

• SMF データの処理

  Db2 のシャットダウン時に、 z/OSDb2 の起動後に開かれたすべての Db2 データセットに対してSMF処理を行います。 この処理にかかる時間を短縮するには、パラメータDDCONS(NO)を設定します。 z/OS パラメータDDCONS(NO)を設定することで、

以下の主な要因は、Db2始動の速度に影響を与えます。

• Db2チェックポイント間隔

  Db2チェックポイント間隔は、チェックポイント間隔は、連続するチェックポイント間でDb2が書き込むログ・レコードの数を示します。 ログ記録、分単位、またはその両方でチェックポイントの頻度を指定できます。 詳細は、「CHECKPOINT TYPE」フィールド（CHKTYPEサブシステムパラメータ ）を参照してください。

  Db2をリサイクルせずに、LOGLOAD オプション、CHKTIME オプション、または SET LOG コマンドのこれらのオプションの両方の組み合わせを使用して、CHKFREQ 値を動的に変更することができます。 指定する値は、再始動要件に応じて 異なります。 CHKTIME オプションのデフォルト値は 5 分です。

• 長時間実行作業単位

  Db2は、始動時に非コミット作業をロールバックします。 このアクティビティーの時間の長さは、Db2がシャットダウンする前に作業単位が実行されていた時間の約 2 倍になります。 例えば、作業単位がDb2異常終了する前に 2 時間実行される場合、Db2の再始動には少なくとも 4 時間かかります。 始動にどれぐらいの時間がかけられるかを 判別して、その半分より長い時間、実行する作業単位を 避けてください。

  アカウンティング・トレースを使用して、長時間実行 する作業単位を検出できます。 表を変更するタスクの場合には、 経過時間をコミット操作数で除算し、コミット操作間の平均時間を 求めてください。 この時間が受け入れられないアプリケーションには、コミット操作を 追加してください。

  推奨 ：長時間実行中の回復ユニットを検出するには、インストールパネルDSNTIPLのUR CHECK FREQオプションを有効にします。 リカバリー単位が長時間実行されることを回避できない場合は、 インストール・パネル DSNTIPL の LIMIT BACKOUT オプションを使用可能にすることを考慮してください。
• アクティブ・ログのサイズ

  テープにアーカイブする場合には、 各アクティブ・ログを十分な大きさにして一般的な作業単位のログ・レコードを 保持することによって、不要な始動の遅延を回避できます。 これにより、Db2が始動時にテープ・マウントを待機する必要がある可能性が低くなります。