管理の手引き


データベースの回復

データベースはハードウェア障害またはソフトウェア障害 (あるいはその両方) が原因で使用不能になることがあり、 障害が異なれば異なった回復処置が必要になります。 したがって、障害に対処できるように、 データベースを保護するための方策を講じておく必要があります。

このセクションでは、 各種の回復方式について説明し、 業務環境に最適な回復方式を判別する方法を示します。 この部分では、次の点について説明します。

回復とは何か

データベース上の問題が発生した場合は、 使用可能な戦略についての知識が必要になります。 これらには、媒体や記憶域の問題、電源停止、 およびアプリケーション上の障害が含まれます。 データベースまたは個々の表スペースをバックアップして、 データベースが壊れた場合にそれらを再作成することができます。 データベース・バックアップ の概念は、 他のデータ・バックアップの概念と同じです。 つまり、オリジナルで障害または損傷が起こる場合のために、 データのコピーを取り、異なる媒体に保管します。 一番単純なバックアップでは、 データベースをシャットダウンして、 トランザクションがこれ以上生じないようにしてから、 単純にそのバックアップを取ります。

このデータベースの再作成のことを回復 といいます。 破損回復 は、 障害が発生した後にデータベースの自動的な回復を試みます。 損傷したデータベースを回復するには、 バージョン回復ロールフォワード回復 の 2 通りの方法があります。

回復不能データベースでは、 logretainuserexit の 両方のデータベース構成パラメーターが使用不能になっています。 これは、保管されているログのみが破損回復に必要なログであることを意味します。 これらのログは、アクティブ・ログ と呼ばれ、 現在のトランザクション・データを含んでいます。 オフライン・バックアップを使ってバージョン回復を行うことは、 基本的には回復不能データベースの回復を行うことを意味します。 (オフライン・バックアップは、バックアップ操作の進行中は、 他のアプリケーションがこのデータベースを使用できないという意味です。) このようなデータベースは、オフラインでのみ復元できます。 復元すると、バックアップ・イメージが取られたときの状態に戻ります。

回復可能データベースでは、 logretainデータベース構成パラメーターが "RECOVERY" に設定されているか、 userexit データベース構成パラメーターが使用可能になっています。 または、これらの両方が行われています。 アクティブ・ログを破損回復で使用できますが、 アーカイブ・ログ もあり、 これにはコミット済みトランザクション・データが含まれています。 このようなデータベースは、オフラインでのみ復元できます。 復元すると、バックアップ・イメージが取られたときの状態に戻ります。 ただし、ロールフォワード回復では、 アクティブ・ログおよびアーカイブ・ログを使用することによって、 特定の時点またはアクティブ・ログの最後までデータベースをロール・フォワード する (つまり、 バックアップ・イメージが取られたときよりも進める) ことができます。

回復可能データベースのバックアップ操作はオフラインでもオンライン でも実行できます (オンラインとは、 バックアップ操作中に他のアプリケーションがそのデータベースに接続できるという意味です)。 データベースの復元とロールフォワード操作は、常にオフラインで実行しなければなりません。 バックアップ操作中に ロールフォワード回復は、 すべての 表の変更がキャプチャーされ、 バックアップが復元された時に再適用されることを保証します。

回復可能データベースがある場合は、データベース全体の代わりに、 個々の表スペースをバックアップ、 復元、およびロールフォワードすることができます。 表スペースをオンラインでバックアップするとき、 その表スペースは依然として使用可能であり、 同時に行われる更新がロギングされます。 表スペースに対してオンライン復元またはロールフォワード操作を実行するときは、 表スペース自体は操作が完了するまで使用できませんが、 ユーザーが他の表スペースにアクセスできないということはありません。

破損回復は、データベースが、矛盾したまたは使用不能な状態のままになることを防ぎます。 データベースに対するトランザクション (つまり作業単位) 予期しない割り込みを受けることがあります。 たとえば、作業単位の一部となるすべての変更内容が完了しコミットされる前に、 障害が発生すると、 データベースは矛盾した、または使用不能な状態のままになっています。

この場合は、データベースを一貫した使用可能な状態にする必要があります。 これは、未完了のトランザクションをロールバックし、故障発生時にメモリーに 残っていたコミット済みトランザクションを完了することによって行われます (図 13)。

図 13. 作業単位のロールバック


作業単位のロールバック

データベースが整合性があり使用可能な状態の場合には、 これは "一貫性ポイント" にあることになります。 オフライン・データベース・バックアップは、一貫性ポイントを表しています。 一貫性ポイントに達したとき、すべてのトランザクションは解決されており、 他のユーザーまたはアプリケーションでデータが使用できます。

破損の後には、RESTART DATABASE コマンド呼び出して、一貫性ポイントに移動できます (コマンド解説書 を参照)。 障害が発生するたびにこの処理を実行したい場合は、 自動再始動可能 (autorestart) 構成パラメーターの使用を考慮してください。 このデータベース構成パラメーターのデフォルト動作は、 必要なときにはいつでも RESTART DATABASE コマンドを呼び出すことです。 autorestart が使用可能になっていると、 障害後にデータベースに対し次の接続要求が出された時点で、 RESTART DATABASE コマンドが呼び出されます。

破損回復を行うと、データベースは一貫性のある、使用可能な状態になります。 ただし、順方向回復が使用可能になっている (つまり、 logretain 構成パラメーターが "RECOVERY" にセットされているか、 または userexit 構成パラメーターが使用可能になっている) データベースで破損回復を実行する場合に、 個別の表スペースが原因で破損回復時にエラーが発生すると、 その表スペースはオフラインにならなければならず、修復されるまでアクセスできなくなります。 破損回復は続行します。 破損回復が完了した時点で、データベースに入っている他の表スペースは使用可能であり、 データベースへの接続は確立できます。 (一時表またはシステム・カタログ表が入っている表スペースに関しては例外 があります。 それらの表については、ロールフォワード回復の部分で説明します。)

前述のように、 DB2 には損傷したデータベースを回復させる方法が 2 つあります。

回復に影響する要素

どのデータベース回復方式を使用するかを決定するには、 以下の基本的な要素を考慮してください。

通常は、データベース保守および回復方針では、データベース回復のために必要になった時点ですべての情報を使用できるようにしておく必要があります。 この方針には、データベース・バックアップをとるための定期スケジュールを組み込み、 さらにデータベース作成時、または区分データベース・システムの場合は データベース区画サーバー (ノード) の追加あるいは削除によるシステム規模の変更時の 予定バックアップ作成操作を組み込む必要があります。 これらの基本要件以外にも、 データベース障害の発生を抑制したりその影響を緩和する要素を組み込んでおくと、 方針はさらに完全なものになります。

以下の部分で、さらに詳しく説明します。

このセクションでは主にデータベースについて述べていますが、 全体的な回復計画には次の項目の回復も組み込む必要があります。

回復可能データベースおよび回復不能データベース

データを容易に再作成できる場合、 そのデータが含まれているデータベースは回復不能データベースにすることができます。 次に例を示します。

データの再作成が困難な場合、 そのデータを保持するデータベースは回復可能データベースでなければなりません。 回復可能データベースの一部になる必要のあるデータの例を以下に挙げます。

データベース・ログ

すべてのデータベースには、それに伴うログがあります。 これらのログには、データベース変更の記録が保持されています。 データベースを最後の全オフライン・バックアップよりも後の時点に復元する 必要がある場合は、 データを障害発生時点までロールフォーワードするためにログが必要です。

DB2 ログには 2 つのタイプがあります。 循環アーカイブ であり、 それぞれは、異なるレベルの回復機能を提供します。

循環 ロギングは、 新規のデータベースが作成されるときの省略時動作です。 このタイプのロギングでは、 データベースの全オフライン・バックアップのみが有効です。 名前から分かるとおり、 循環ログはオンライン・ログの「輪」を使用して、 トランザクション障害およびシステム破損からの回復を提供します。 ログは、 現行トランザクションの保全性を保証するためにのみ使用および保存されます。 循環ロギングでは、 最後に行った全バックアップより後のトランザクションを使用してデータベースをロールフォワードすることはできません。 媒体障害および災害からの回復は、 全オフライン・バックアップからの復元によって行います。 最後のバックアップ以降の変更はすべて失われます。 全バックアップを作成するとき、 データベースはオフライン (ユーザーからアクセス不能) でなければなりません。 このタイプの復元では、データが全バックアップの時点まで回復されるため、 これは、バージョン回復 と呼ばれています。

図 16 は、 循環ロギングが活動状態のときにアクティブ・ログがログ・ファイルの輪を使用する様子を示しています。

図 16. 循環ロギング


循環ロギング

アクティブ・ログは、障害 (システム電源または アプリケーション・エラー) が原因でデータベースが一貫性のない状態になるのを防ぐために、 破損回復処理中に使用されます。 RESTART DATABASE コマンドは必要に応じてアクティブ・ログを使用し、 データベースを、一貫性のある使用可能な状態にします。 破損回復の際、障害が原因でコミットされていないログ内の変更内容は、 ロールバックされます。 コミットされてはいるもののメモリー (バッファー・プール) からディスク (データベース・コンテナー) へ物理的にまだ書き出されていない変更は、 再実行されます。 こうした処置によって、データベースの保全性が保たれます。 また、特定の時点での回復またはログの最後までの回復を実行するときに、 ROLLFORWARD DATABASE コマンドもアクティブ・ログを使用します。 アクティブ・ログは、データベース・ログ・パス・ディレクトリーにあります。

アーカイブ・ログがロールフォワード回復に使用されます。 次のとおりです。

オンライン・アーカイブ・ログ
アクティブ・ログに入っている変更内容が通常の処理で必要なくなると、 そのログはクローズされて、アーカイブ・ログになります。 アーカイブ・ログがデータベース・ログ・パス・ディレクトリーに入っている場合、 そのログはオンライン であるといいます (図 17 を参照)。

オフライン・アーカイブ・ログ
アーカイブ・ログがデータベース・ログ・パス・ディレクトリーに入っていない場合、 そのログはオフライン であるといいます (図 18を参照)。 ユーザー出口プログラムを使用して、アーカイブ・ログをデータベース・ログ・パス・ディレクトリー以外の位置に保管することもできます。 (追加情報については、 付録 F, データベース回復用のユーザー出口 を参照してください。)

図 17. アーカイブ・ログ


アーカイブ・ログ

図 18. オフライン・アーカイブ・ログ


オフライン・アーカイブ・ログ

ロールフォワード回復では、アーカイブ・ログとアクティブ・ログの両方を使用して、 ログの終わりまでまたは特定の時点まで、データベースを再作成することができます。 ロールフォワード機能は、アーカイブ・ログとアクティブ・ログで検出されるコミットされた変更項目を、 復元されるデータベースに再適用することで、この処理を実行します。

ロールフォワード回復は、 アーカイブ・ログとアクティブ・ログの両方にあるコミットされた更新を再適用することにより、 ログを使用して表スペースを再作成することもできます。 表スペースは、ログの最後まで、または特定の時点まで回復可能です。

オンライン・バックアップ時には、 データベースに対するすべての活動がログに記録されます。 オンライン・バックアップが復元されるとき、 これらのログは少なくともバックアップが完了した時点までロールフォワードされなければなりません。 このことが生じるようにするために、 ログをアーカイブしておき、データベースが復元されるときに使用可能にしなければなりません。 操作が完了したかなり後でも、バックアップ時に使用されたログ・ファイルがオープン状態のままになっている場合があります。 BACKUP DATABASE コマンドでオンライン・バックアップの FLUSH LOG オプションを指定すれば、 オンライン・バックアップの完了時にアクティブ・ログがクローズされます。 これにより、 アクティブ・ログをアーカイブして、 完全なバックアップと、そのバックアップの復元に必要なログすべてが備えられるようにできます。

図 19. ロールフォワード回復での活動およびアーカイブ・データベース・ログ


ロールフォワード回復での活動およびアーカイブ・データベース・ログ

アーカイブ・ログの記憶位置は、newlogpathuserexit の 2 つのデータベース構成パラメーターによって変更できます。 newlogpath パラメーターを変更すると、 アクティブ・ログの記憶位置も変更されます。 これらの構成パラメーターについての詳細は、管理の手引き: パフォーマンス を参照してください。

データベース・ログ・パス・ディレクトリーの中のどのログ・エクステント(コンテナーを参照) がアーカイブ・ログかを判別するには、 loghead データベース構成パラメーターの値を調べてください。 このパラメーターには、最も低い番号のアクティブ・ログが示されています。 loghead よりも小さい順序番号のログはアーカイブ・ログであり、 それらは移動可能なログです。 このパラメーターの値は、コントロール・センターを使用して検査できます。 あるいは、コマンド行プロセッサーおよび GET DATABASE CONFIGURATION コマンドを使用して、 「最初のアクティブ・ログ・ファイル」を参照します。 この構成パラメーターについての詳細は、管理の手引き: パフォーマンス を参照してください。

注:

  1. アクティブ・ログを消去すると、データベースは使用不能になってしまい、 再び使用できるようにするには復元することが必要になります。 また、消去された最初のログまでしかロールフォワードできません。

  2. アクティブ・ログが (ディスクが壊れた結果) 損傷するかもしれないことが心配な場合は、 ログの保管先のボリュームをミラーリングすることを考慮する必要があります。

作業表におけるロギングの低減

アプリケーションでマスター表から作業表を作成してその中にデータを入れる場合に、 マスター表から簡単に再作成できるという理由でこれら作業表の回復可能性について心配する必要がない場合、 作業表は CREATE TABLE ステートメント に NOT LOGGED INITIALLY パラメーターを指定して作成することができます。 NOT LOGGED INITIALLY パラメーターを使用する利点は、表が作成された作業単位と 同じ作業単位で表に対し行われた変更 (挿入、削除、更新、または索引作成操作を含む) をロギングしなくてもよい点です。 これにより、実行されるロギングが低減されるだけでなく、 アプリケーションのパフォーマンスも向上します。 NOT LOGGED INITIALLY パラメーターを指定した ALTER TABLE ステートメントを使用して、 既存の表について同じ結果を確保できます。

注:

  1. 同じ作業単位で NOT LOGGED INITIALLY パラメーターを使用し複数の表を作成できます。

  2. カタログ表および他のユーザー表に対する変更は、ロギングの対象になります。

表に対する変更がロギングされないため、 NOT LOGGED INITIALLY パラメーターの使用を決定するときには次の点を考慮する必要があります。

表の作成についての詳細は、SQL 解説書 を参照してください。

宣言済み一時表を作業表として使用することを計画している場合は、 次の点に注意してください。

宣言済み一時表とその制限についての詳細は、 SQL 解説書 で DECLARE GLOBAL TEMPORARY TABLE ステートメントを参照してください。

回復目標点

バージョン回復とロールフォワード回復とでは、回復の目標時点が異なります。 バージョン回復の場合には、計画された各時点で、 オフラインの完全なデータベース・バックアップ・コピーをとります。 この方法では、回復されたデータベースは、 復元されたバックアップ・コピーより最新にはなりません。 たとえば、一日の終わりにバックアップ・コピーをとり、 翌日に作業中途でデータベースを失った場合は、半日分の変更内容を失うことになります。

ロールフォワード回復方式の場合、 データベースに対する変更はログの中に記録されています。 この方法では、まずバックアップ・コピーを使ってデータベースまたは表スペースを復元した後、 ログを使用して、バックアップ・コピーが作成されて 以来のデータベース変更を適用し直します。

ロールフォワード回復を使えるようにすると、 オンライン・バックアップと表スペース・レベルのバックアップの両方の長所を活用できます。 データベースまたは表スペース全体のロールフォワード回復を行うためには、 ログの最後まで、または指定された時点までの回復を選択できます。 たとえば、データベースがアプリケーションによって破壊された場合は、 復元されたデータベース・コピーから開始して、アプリケーション開始直前までの変更をロールフォワードすることができます。 指定した時間以降に書き込まれた作業単位は再適用されません。

また、ログの最後まで、または特定の時点まで、表スペースをロールフォワードできます。

バックアップの頻度と所要時間

データベースのバックアップには時間もシステム・リソースも必要となるため、 回復計画では、定期的なバックアップも含める必要があります。

ログを保管する場合など (これにより、ロールフォワード回復が可能になる)、 データベース全体のバックアップを定期的にとるようにしてください。 回復方針にロールフォワード回復が組み込まれている場合は、 最近のデータベース全体のバックアップを作成しておくと、 データベースに適用しなければならないアーカイブ・ログが少なくて済むことになります。 これにより、 データベースを回復するために実行する ROLLFORWARD ユーティリティーの時間が短縮されます。

また、バックアップおよびログを上書きせずに、 安全を考慮してデータベース全体および関連ログを複数個保管することも考慮してください。

頻繁に使用されるデータベースの回復とロールフォワードでアーカイブ・ログを適用するのに必要な時間について心配な場合には、 頻繁にデータベースのバックアップをとるためのコストを考慮してください。 これにより、 ロールフォワード時に適用する必要のあるアーカイブ・ログの数を減らすことができます。

バックアップは、データベースがオンライン でもオフライン でも実行できます。 オンラインの場合、他のアプリケーションまたはプロセスは、 バックアップ操作の実行中もデータベースに接続し続けたり、 データの読み取りや修正を行うことができます。 バックアップがオンラインで実行される場合、 データベースに接続できるのはバックアップ操作だけです。 バックアップ・タスクの実行中は組織内の他の部署はデータベースに接続できません。

データベースが使用できなくなる時間を短くするには、 オンライン・バックアップの使用が考えられます。 ロールフォワード回復が可能である場合にのみ、オンライン・バックアップがサポートされます。 ロールフォワード回復を使用でき、ログの完全セットがある場合は、必要が 生じたときにデータベースを再作成できます。

注:

  1. バックアップ操作が行われた時間に関係しているデータベース・ログがある場合、 使用できるのはオンライン・バックアップのみです。

  2. オフライン・バックアップは、オンライン・バックアップより高速です。

データベースの中に長形式フィールドと LOB のデータが大量に含まれている場合には、 データベースのバックアップ作業に非常に多くの時間がかかります。 BACKUP コマンドでは、特定の表スペースのバックアップをとることができます。 DMS 表スペースを使用すると、その表スペースに異なったタイプのデータを格納でき、 バックアップ操作に必要な時間を短縮できます。 表データをある表スペースに保持し、長形式フィールドおよび LOB データを別の表スペースに保持し、 索引を別の表スペースに保持することができます。 長形式フィールドと LOB データを別個の表スペースに保管してあるなら、 長形式フィールドと LOB データが入っている表スペースのバックアップはとらないように選択することによって、 バックアップの完了にかかる時間を少なくすることができます。 長形式フィールドおよび LOB データがビジネスにとって重要である場合には、 これらの表スペースのバックアップの作成と、 これらの表スペースの復元操作の完了にかかる時間との関係を考慮してください。 LOB データが別のソースから再作成可能である場合は、 LOB 列を含む表の作成または変更時には、NOT LOGGED オプションを選択してください。

表を再編成する場合、操作完了後に関連した表スペースのバックアップを作成する必要があります。 これにより、表スペースを復元しなければならない場合でも、 データ再編成によりロールフォワードを実行しなくても済みます。
注:表データの一部が入っていない表スペースをバックアップする場合、 その表スペースに対して時刻指定ロールフォワード回復は実行できません。 表に関する任意のデータ・タイプが含まれているすべての表スペースは、 同じ時点まで同時にロールフォワードする必要があります。

必要な回復時間

データベースの回復に必要な時間は、次の 2 つの要素で構成されます。 つまり、バックアップの復元を完了するために必要な時間と、ロールフォワード 操作時にログを適用するために必要な時間 (これは、データベースが順方向 回復について使用可能である場合) です。 回復計画を公式化するときは、 これらの回復費用とそれらが業務操作に与える影響を考慮しなければなりません。 全般的な回復計画をテストすることで、データベースを回復するために必要な時間が、 業務上の要件を考慮して正当かどうかを判別することができます。 各テストを実施した後、バックアップを作成する頻度を増やすことができます。 回復方針の一部としてロールフォワード回復を実行する場合は、 これによりバックアップ間でアーカイブされるログ数が減少し、 その結果、復元操作後にデータベースをロールフォワードするための時間が短縮されます。
注:区画内の並行処理 (intra_parallel) を使用可能に設定すると、 データベース・マネージャー構成パラメーターは バックアップと復元操作のパフォーマンスに影響を与えません。 intra_parallel パラメーターの設定に関係なく、 それぞれの操作で複数のプロセスが使用されます。

記憶域についての考慮事項

どの回復方式を使用するかを決定する際には、 記憶スペースの要件を考慮する必要があります。

バージョン回復方式の場合は、 データベースと復元後のデータベースを入れるスペースが必要になります。 ロールフォワード回復方式の場合は、 データベースまたは表スペースのバックアップ・コピー、復元後のデータベース、 およびアーカイブ・データベース・ログを入れるだけのスペースが必要になります。

表の中に長形式フィールドとラージ・オブジェクト (LOB) の列が含まれている場合は、 そのデータを別の表スペースに入れることを考慮してください。 このことは、回復の計画に関係するだけでなく、記憶スペースにも影響します。 長形式フィールドと LOB データを別の表スペースに取り分けておき、 長形式フィールドと LOB データのバックアップにかかる時間が分かっているなら、 表スペースのバックアップ頻度を少なくした回復計画にするよう決定できるかもしれません。 表を作成または更新して LOB 列を組み込む際に、 これらの列に対する変更内容を記録しないことを選択することもできます。 このように選択すると、 必要なログ・スペースおよび対応するログ・アーカイブ・スペースのサイズを減らせます。

LOB が入っている SMS 表スペースのバックアップは、元の表スペースのサイズより大きくなっている可能性があります。 表スペースに含まれる LOB データ・サイズによっては、バックアップは最大 40 パーセント大きくなる可能性があります。 たとえば、1 GB の SMS 表スペース (LOB が入っている) のバックアップを取る場合には、 復元する際に 1 GB より大きいディスク容量が必要になります。 このことが起こるのは、予備割り振りをサポートするファイル・システム (たとえば、 UNIX ベースのオペレーティング・システム) だけです。

媒体障害が発生したときにデータベースが破壊され、 それを再作成できなくなってしまうことがないようにするため、 データベース・バックアップ、データベース・ログ、 およびデータベース自身を別々の装置に保持するようにしてください。 この理由で、データベース作成時に、データベース・ログは、 newlogpath 構成パラメーターを使うことによって、 必ず別の装置に保管しておくようにしてください。 (このパラメーターも含め、ロギング関連の構成パラメーターについては、 データベース変更のロールフォワード操作 で説明します。)

データベース・ログには、大量の記憶域を使用できます。 ロールフォワード回復方法を使用する場合は、 アーカイブ・ログをどのように管理するかを決定する必要があります。 選択肢は次のとおりです。

注:OS/2 の場合は、 標準および非標準装置に存在するデータベースおよびデータベース・ログの両方の データベース・バックアップ・イメージの記憶域を処理するためのユーザー出口プログラムが、 DB2 でサポートされています。 詳細については、 付録 F, データベース回復用のユーザー出口 を参照してください。

関連データの一括保持

データベースを設計するとき、各表間の関係が分かります。 これらの関係はアプリケーション・レベルで表現することができ、 この場合は、 トランザクションは複数の表を更新します。 またデータベース・レベルで表現することができ、この場合は、 表間に参照保全が存在するかまたはある表のトリガーが別の表に影響を与えます。 回復計画を作成するときは、これらの関係を考慮に入れる必要があります。 関連するデータ・セットは、まとめてバックアップできます。 そのようなセットは、表スペース・レベルまたはデータベース・レベルのいずれかで作成できます。 関連するデータのセットをまとめて保持することで、 すべてのデータの一貫性が保証されている時点まで、回復処理を実行できます。 これは、表スペースに対し特定の時点のロールフォワード回復を実行できるようにしたい場合、 特に重要です。

異なるオペレーティング・システムの使用についての制約事項

複数のオペレーティング・システムのある環境で作業する場合、 バックアップおよび回復の計画を統合できないことを考慮しなければなりません。 つまり、一方のオペレーティング・システムで BACKUP DATABASE コマンドを 使用し、別のオペレーティング・システムで RESTORE DATABASE コマンドを 使用することはできません。 それぞれのオペレーティング・システムの回復計画は、 別個に独立して保持しなければなりません。

一方のオペレーティング・システムから他のオペレーティング・システムに 表を移動しなければならない場合には、db2move コマンドを使用します。 あるいは、IMPORT または LOAD コマンドと共に EXPORT を使用します。 詳細については、データ移動ユーティリティー 手引きおよび解説書 を参照してください。

損傷を受けた表スペースの回復

損傷を受けた表スペースには、 アクセスできない 1 つまたは複数のコンテナーがあります。 これは、永続的な媒体 (たとえば、ディスクに障害がある) または 一時的な媒体 (ディスクがオフラインになっている、 またはファイル・システムがマウントされていない) の問題が原因です。

損傷を受けた表スペースがシステム・カタログ表スペースの場合には、 データベースを再始動することはできません。 元のデータをそのままの状態にしてコンテナーの問題を修正できない場合には、 以下の選択肢しか実行できません。

損傷を受けた表スペースがシステム・カタログ表スペースでない場合には、 DB2 はできるかぎりデータベースを使用できるようにします。 この場合に成功するかどうかはロギング戦略によって決まります。

損傷を受けた表スペースが唯一の一時表スペースである場合には、 データベースに接続されたらすぐに新しい一時表スペースを作成しなければなりません。 一度作成されると、新しい一時表スペースが使用できるようになり、一時表 スペースが必要な通常のデータベース操作を再開できます。 それから、任意でオフライン一時表スペースを除去します。 システム一時表スペースを使用する表の再編成については、特別な考慮事項があります。

回復可能データベースの表スペース回復

破損回復が必要であるため、 損傷を受けた表スペースは、アクセス不能状態でオフラインに入れられ、 さらにロールフォワード保留状態になります。 他に問題がなければ再始動操作は成功します。 損傷を受けた表スペースは、次の場合に再び使用できます。

回復不能データベースの表スペース回復

破損回復は必要であり、ログは永久に保持されるわけではないため、 ユーザーが損傷を受けた表スペースを除去するのをいとわない場合にのみ、 再始動操作を成功させることができます。 (正常な回復とは、損傷を受けた表スペースを回復して整合性のある状態に戻す必要のあるログ・レコードがなくなることを意味します。 したがって、そのような表スペースで有効なアクションは、これらを除去することだけです。)

これを行うには、 修飾されていないデータベース再始動操作を呼び出します。 損傷を受けた表スペースがない場合には、これは成功します。 失敗した (SQL0290N) 場合には、 db2diag.log を調べて、 現在損傷を受けている表スペースの完全なリストを参照できます。

注:DROP PENDING TABLESPACES リストに表スペース名を入れても、 この表スペースが DROP PENDING 状態になったことにはなりません。 これは、表スペースが再始動操作中に損傷を受けた場合にのみ起こることです。 再始動操作が成功したら、 TABLESPACE ステートメントを出して 除去保留状態にある各表スペースを除去する必要があります (LIST TABLESPACES コマンドを使用して、 どの表スペースがこの状態であるかを調べてください)。 このようにして、スペースを再利用するか、または表スペースを再作成できます。

回復のパフォーマンスに関する考慮事項

回復のパフォーマンスについて考慮する際には、 以下の点についても考慮に含めてください。

災害時回復の考慮事項

災害時回復 という用語は、 火災、地震、暴力行為、または他の災害事象が発生した場合にデータベースを復元するために、 実行しなければならない活動を記述するために使用されます。 災害時回復の計画には、以下の 1 つまたは複数が含まれます。

災害時回復計画が別のマシンでのデータベース全体の回復を意味する場合は、 少なくとも完全なデータベース・バックアップとデータベースに関するすべてのアーカイブ・ログが必要です。 ログをアーカイブする際にそれらを予備のデータベースに適用することによって、 そのデータベースを最新の状態にしておくことができます。 あるいは、データベース・バックアップとログ・アーカイブを予備のサイトに保持し、 災害発生後にだけ復元およびロールフォワードを実行するようにもできます。 (この場合、最新のデータベース・バックアップがぜひとも必要です。) しかし、災害時の場合は、 すべてのトランザクションを災害発生時まで復元することは通常は不可能です。

災害時回復に表スペースのバックアップが役に立つかどうかは、 障害の範囲によって決まります。 通常、災害時回復ではデータベース全体を復元する必要があるので、 待機サイトにデータベースの全バックアップを保持する必要があります。 すべての表スペースの別々のバックアップ・イメージがあるとしても、 データベースを復元するためにそれらを使用することはできません。 その災害がディスクの損傷である場合には、 表スペースのバックアップをそのディスクにある表スペースごとに回復に使用できます。 ディスク障害 (または他の理由) によりコンテナーにアクセスできない場合は、 コンテナーを別の場所に復元できます。 詳細については、RESTORE 実行時の表スペース・コンテナーの再定義 を参照してください。

表スペースのバックアップと完全なデータベースのバックアップの両方があれば、 どのような災害時回復計画でも役に立ちます。 バックアップ、復元、およびデータのロールフォワードのために用意されている DB2 機能は、 災害時回復計画の基本となります。 業務を保護するために、準備した回復手順をテストしておくようにしてください。

媒体障害の影響の緩和

媒体障害の発生率を緩和し、 またこの障害タイプからの回復処理を簡単に実行できるようにするためには、 次の操作を実行します。

ディスク障害に対する保護

ディスクに障害が発生したためにデータまたはログが損傷を受ける危険性がある場合、 考慮すべきことは、 ディスク障害に対する何らかの許容度を持つ方策を講じておくことです。 通常は、これは、ディスク・アレイ を使用する ことで行われます。 ディスク・アレイはいくつかのディスク・ドライブをまとめたもので、 アプリケーションからは 1 つの大きなディスクのように見えます。

ディスク・アレイには、ディスク・ストライピング (複数ディスク間でファイルを分散すること)、 ディスクのミラーリング、およびデータ・パリティー検査が関係してきます。

ディスク・アレイは、 単に RAID (Redundant Array of Independent Disks) と呼ばれることがあります。 用語 RAID は、通常ハードウェア・ディスク・アレイにだけ適用されます。 ただし、ディスク・アレイはオペレーティング・システムまたはアプリケーション・レベルのソフトウェアによっても提供されています。 ハードウェア・ディスク・アレイとソフトウェア・ディスク・アレイの相違点は、 入出力要求を CPU がどのように処理するかという点です。 ハードウェア・ディスク・アレイの場合、 ディスク制御装置が入出力活動を管理するのに対し、 ソフトウェア・ディスク・アレイの場合は、 オペレーティング・システムまたはアプリケーションにより実行されます。

ハードウェア・ディスク・アレイ (RAID)

RAID ディスク・アレイでは、 ディスク制御装置により複数のディスクが使用され管理されていて、 独自の CPU も備えています。 アレイを構成しているディスクの管理に必要なすべてのロジックはディスク制御装置に含まれています。 したがって、この実行はオペレーティング・システムから独立して行われます。

RAID アーキテクチャーには RAID-1 から RAID-5 までの 5 種類があり、 それぞれがディスク・フォールト・トレランスを提供しています。 それぞれの機能とパフォーマンスは異なります。 一般に、RAID は冗長アレイを指します。 データ・ストライピングのみ (障害許容度の冗長度ではない) を提供する RAID-0 は、 この説明からは除外されています。 RAID の仕様では 5 つのアーキテクチャーを定義していますが、 今日では通常 RAID-1 と RAID-5 だけが使用されます。

RAID-1 は、ディスクのミラーリングまたはデュプレキシングとも呼ばれます。 ディスク・ミラーリングは、単一のディスク制御装置を使用し、データ (完全なファイル) をあるディスクから別のディスクに複写します。 ディスク・デュプレキシングはディスク・ミラーリングと同じですが、 ディスクは 2 番目のディスク制御装置に接続されています (2 つの SCSI アダプターと同じ)。 データの保護機能は良好です。 つまり、どちらのディスクに障害が発生しても、データは他のディスクから アクセス可能です。 デュプレキシングでは、データ保護の妥協がないと、 ディスク制御装置に障害が発生することがあります。 RAID-1 に関するパフォーマンスも良好ですが、 この実現方法で考慮しなければならないトレードオフは、 データをドライブのペアで複写しなければならないため、 必要なディスク容量が実際のデータ量の 2 倍になることです。

RAID-5 は、すべてのディスクの セクター単位のデータ・ストライピングおよび パリティー・ストライピングに関係しています。 パリティーは専用ドライブに保管される代わりに、データ情報とインターリーブされます。 データの保護機能は良好です。 ディスク障害が発生しても、他のディスクからの情報およびストライプされ たパリティー情報を使用しアクセス可能です。 書き込みパフォーマンスは RAID-1 または通常のディスクと比べてかなり低 いですが、読み取りパフォーマンスは良好です。 RAID-5 構成では、少なくとも 3 つの同一なディスクが必要です。 オーバーヘッドのために必要な余分なディスク・スペースは、 アレイに含まれるディスク数により異なります。 5 つのディスクで構成される RAID-5 構成の場合は、スペース・オーバーヘッドは 20% です。

RAID ディスク・アレイ (RAID-0 ではない) を使用する場合、 ディスクに障害が発生してもユーザーはアレイ上のデータにアクセスできます。 常時交換可能または常時スワップ可能ディスクをアレイに使用すると、 アレイ使用中に交換ディスクを障害ディスクとスワップすることが可能です。 RAID-5 の場合、2 つのディスクで同時に障害が発生すると、 すべてのデータは失われます (しかし、 同様のディスク障害が発生する可能性はごくまれです)。

RAID-1 またはソフトウェア・ミラー・ディスクをログに使用できます (ソフトウェア・ディスク・アレイを参照)。 これは、障害点までの回復可能性があり、書き込みパフォーマンスが高いためで、 これはログにとって重要です。 (ディスク障害発生後にただちに) データを回復できるように高信頼性が必要であるが、 書き込みパフォーマンスはそれほど重要でない場合は、 RAID-5 ディスクの使用を考慮してください。 あるいは、 書き込みパフォーマンスが重要で、 追加ディスク・スペースによるコストが大きくなってもこの状態を達成した場合は、 データおよびログに RAID-1 を考慮してください。

ソフトウェア・ディスク・アレイ

ソフトウェア・ディスク・アレイはハードウェア・ディスク・アレイとほぼ同じ操作を実行しますが (ハードウェア・ディスク・アレイ (RAID)を参照)、 ディスク・トラフィックの管理は、オペレーティング・システム・タスクまたはサーバーの下で実行されるアプリケーション・プログラムのいずれかが行います。 他のプログラムと同様、 ソフトウェア・アレイは CPU およびシステム・リソースを競合して獲得しなければなりません。 したがって、CPU 制約システムには適しておらず、ディスク・アレイ全体の パフォーマンスがサーバーの CPU の負荷と容量に依存する点に注意する必要 があります。

通常のソフトウェア・ディスク・アレイは、 ディスク・ミラーリングを実行します (ハードウェア・ディスク・アレイ (RAID)を参照)。 冗長性ディスクは必要ですが、高価な RAID ディスク制御装置は不要である ため、ソフトウェア・ディスク・アレイは比較的低価格で実現可能です。
注:オペレーティング・システムのブート・ドライブをディスク・アレイに設定すると、 そのドライブに障害が発生した場合はシステムが始動しなくなります。 ディスク・アレイが実行される前にドライブに障害が発生すると、 ディスク・アレイは始動できないため、ドライブにアクセスすることはできません。 ブート・ドライブは、 ディスク・アレイから分離されていなければなりません。

トランザクション障害の影響の緩和

トランザクション障害の影響を緩和するためには、 以下の条件が満たされているかどうか確認してください。

区分データベース・システムにおけるシステム・クロックの同期

データベース区画サーバー全体で相対的な同期がとれたシステム・クロック を維持し、データベース操作がスムーズに行われ、順方向回復性に制限が加 わらないようにします。 データベース区画サーバー間の時間差にトランザクションの操作および通信遅延時間を加えたものは、 max_time_diff (ノード間最大時間差) データベース・マネージャー構成パラメーターの値より小さくしてください。

ログ・レコードのタイム・スタンプがトランザクションの順序を確実に示すようにするために、 区分データベース・システムの DB2 は、 ログ・レコードに記録するタイム・スタンプの基準として、 各マシンのシステム・クロックを使用します。 しかし、システム・クロックを進めると、ログ・クロックはそれに合わせて自動的に進みます。 システム・クロックを遅らせることはできますが、ログのクロックを遅らせることはできず、 システム・クロックをこの時刻に合わせるまでは、 ずっと 進んだ時刻のままです。 このとき、両方のクロックは同期しています。 このことは、データベース・ノードで発生するシステム・クロック・エラー が短期間であっても、データベース・ログのタイム・スタンプではその影響 が長く続くことがあることを意味します。

仮説的な例として、データベース区画サーバー A のシステム・クロックを、 1997 年に間違って 1999 年 11 月 7 日に設定したものとします。 また、その誤りは訂正されましたが、 そのデータベース区画サーバーの区画で更新トランザクションがコミットされた であったとします。 そのデータベースが連続的に使用されていてその間で定期的に更新されていると、 1997 年 11 月 7 日から 1999 年 11 月 7 日までの間の任意の時点は、 ロールフォワード回復では実際には処理不能になります。 データベース区画サーバー A でコミットが行われると、 データベース・ログのタイム・スタンプは 1999 に設定され、 データベース・ログのクロックは 1999 年 11 月 7 日のままです。 この状態は、システム・クロックがこの時間と一致するまで続きます。 この時間フレーム内の時点へロールフォワードしようとすると、 指定された停止点 (1997 年 11 月 7 日) を超えた最初のタイム・スタンプで操作は停止します。

DB2 ではシステム・クロックに対する更新を制御することはできませんが、 max_time_diff データベース・マネージャー構成パラメーターを指定しておくと、 次のような問題が発生するのを防ぐことができます。

データベース・ログ内の正しくないタイム・スタンプを訂正し、 間違った値が伝搬されないようにするためには、次の操作を実行します。

  1. システム・クロックを正しい時間に調整します。
  2. 時間が不正に設定される前に作成したバックアップを使用し、 該当するデータベース区画サーバー上でデータベース区画を復元します。
  3. データベース区画のログの最後まで、変更項目をロールフォワードします。
  4. 変更項目がロールフォワードされた直後、データベース区画のバックアップ・コピーを作成します。

これらの処置を完了すると、ログ時間は調整され、 正しくないタイム・スタンプが伝搬されることがなく、 区画について最後に作成したバックアップを使用して、 データベース区画で時刻指定回復を実行することができるようになります。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]