リリース情報


7.6 第 8 章 データベースの回復

7.6.1 中断入出力の使用法

第 8 章「"データベース・リカバリ"」に、中断入出力関数の使用法に関するセクションを追加します。

注:
db2inidb ユーティリティーに関する下記の情報を、「バージョン 7.2 新着情報」に 記載されている情報と置き換えてください。

db2inidb は DB2 に添付された新しいツールで、クラッシュ・リカバリを実行でき、また データベースをロールフォワード保留状態にすることができます。

中断入出力は、連続的なシステム使用可能性を、オンライン分割ミラー・ハンドリングの フル・インプリメンテーション (つまりデータベースをシャットダウンせずにミラーを 分割) を提供することでサポートします。大きなデータベースでバックアップをオンラインまたは オフラインにすることが難しい場合は、中断入出力と分割ミラーを使用してミラー・イメージから バックアップまたはシステム・コピーを行うことができます。

ストレージ装置のミラーリングの度合いによって、db2inidb の使用法は変わります。 以下の使用法では、データベース全体がストレージ・システムを通じて一貫してミラーリングされていることを 想定しています。

マルチノード環境で、いずれかの区分から分割イメージを使用できるようにするには、 db2inidb ツールを区分それぞれで実行する必要があります。 db2inidb ツールは、すべての区分で同時に実行することができます。

  1. レプリケーション・データベースを作成する

    この目的は、1 次データベースの レプリケーションを読み取りに使用することです。 レプリケーション・データベースの作成手順は以下の通りです。

    1. 次のコマンドを入力して、1 次システムで入出力を中断します。
           db2 set write suspend for database
      
    2. オペレーティング・システム・レベル・コマンドを使用して、1 次データベースから ミラーを分割します。
    3. 次のコマンドを入力して、1 次システムで入出力を再開します。
           db2 set write resume for database
      

      コマンドの実行後、1 次システムの データベースは正常な状態に戻るはずです。

    4. ミラーリングされたデータベースに別のマシンから接続します。
    5. 次のコマンドを入力して、データベース・インスタンスを開始します。
           db2start
      
    6. 次のコマンドを入力して、DB2 クラッシュ・リカバリを開始します。
      db2inidb database_name AS  SNAPSHOT
      
      注:
      このコマンドは、 分割時に未了であったトランザクションによる変更をロールバックします。

    この処理はオフライン・バックアップにも使用することができますが、 1 次システムに復元する場合、ログ・チェーンが一致しないために、このバックアップを ロールフォワードに使用することはできません。

  2. 分割ミラーをスタンドバイ・データベースとして使用する

    ミラーリングされた (スタンドバイ) データベースは ログを通じて連続的にロールフォワードするため、1 次データベースで作成されている新しいログは、 1 次システムから絶えずフェッチされます。分割ミラーをスタンドバイ・データベースとして使用する 方法は以下の通りです。

    1. 1 次データベースで入出力書き込みを中断します。
    2. 1 次システムからミラーを分割します。
    3. 1 次データベースで入出力書き込みを再開し、1 次データベースが正常処理に戻るようにします。
    4. ミラーリングされたデータベースを別のインスタンスに接続します。
    5. ミラーをロールフォワード保留状態にして、ミラーをロールフォワードします。 db2inidb ツール (db2inidb <db_alias> as standby) を実行して、書き込み中断状態を除去し、 ミラーリングされたデータベースをロールフォワード保留状態にします。
    6. ユーザー出口プログラムをセットアップしてログをコピーし、1 次システムから ログ・ファイルを検索します。これにより、このミラーリングされたデータベースで 最新ログを使用できるようにします。
    7. データベースをログの終わりまでロールフォワードします。
    8. ステップ f に戻り、1 次データベースがダウンするまでこのプロセスを繰り返します。

  3. 分割ミラーをバックアップ・イメージとして使用する

    ミラーリングされた システムを 1 次システムに対して復元するためのバックアップ・イメージとして 使用する方法は、以下の通りです。

    1. オペレーティング・システム・コマンドを使用してミラーリングされたデータを コピーし、1 次システムの最上部にログオンします。
    2. 次のコマンドを入力して、データベース・インスタンスを開始します。
           db2start
      
    3. 次のコマンドを実行して、ミラーリングされたデータベースをロールフォワード保留状態にし、 書き込み中断状態を除去します。
      db2inidb database_alias AS MIRROR
      
    4. データベースをログの終わりまでロールフォワードします。

7.6.2 増分バックアップおよびリカバリ

第 8 章「"データベース・リカバリ"」に、増分バックアップおよびリカバリに関する 以下のセクションを追加します。

データベース (特にウェアハウス) のサイズがテラバイトからペタバイトの 範囲に展開するにつれて、これらのデータベースのバックアップおよびリカバリに 必要な時間とハードウェア・リソースも大幅に増加します。 大規模なデータベースを扱っている場合、データベースおよび表スペースの 全バックアップを実行することは、データベースの複数コピーのストレージ要件が 巨大になるため、最適なアプローチとはいえません。 以下の点に注意してください。

DB2 は現在、増分バックアップおよびリカバリをサポートしています (ただし、 大きなフィールドおよびラージ・オブジェクト・データはサポートしません)。 増分バックアップは、直前のバックアップが取られた後で 更新されたページのみを含むバックアップ・イメージです。 増分バックアップ・イメージそれぞれには、更新されたデータと索引ページに加え、 通常、全バックアップ・イメージに保管される初期データベース・メタデータ (データベース構成、 表スペース定義、データベース・ヒストリーなど) も含まれます。

以下の 2 つのタイプの増分バックアップがサポートされています。

増分バックアップ・イメージとデルタ・バックアップ・イメージとの主な相違点は、 時間の経過とともに変化するオブジェクトの連続バックアップを取るときの動作です。 連続増分イメージそれぞれには、以前の増分イメージの内容全体に加え、直前の バックアップが作成された後で変更されたデータや追加されたデータも含まれます。 デルタ・バックアップ・イメージには、直前のイメージが作成された後で変更されたページのみが含まれます。

データベースおよび表スペース増分バックアップの組み合わせは、 オンライン・モードとオフライン・モードの両方で許可されています。 バックアップについて計画する場合、データベースおよび表スペース増分バックアップを 組み合わせると、前のデータベース・バックアップは必ずしも 1 つのイメージではなく、 別の機会に取られた以前のデータベースおよび表スペース・バックアップの 固有セットになる場合があるため、注意してください。

データベースまたは表スペースを一貫性のある状態に再作成するには、 復元するオブジェクト全体 (データベースまたは表スペース) の一貫性のある イメージを使用してリカバリ処理を開始し、以下に説明する順序 (「リストア・メソッド」 セクションを参照) でそれぞれの適切な増分バックアップ・イメージを適用する必要があります。

データベース更新のトラッキングを可能にするため、DB2 は、 以下の 2 つの値を設定できる新しいデータベース構成パラメーター TRACKMOD をサポートしています。

デフォルト TRACKMOD 設定は、既存のデータベースであれば NO、 新しいデータベースであれば YES です。

トラッキングの細分度は、SMS および DMS 表スペースの両方の表スペース・レベルです。

データベースへの更新のトラッキングは、データを更新または挿入するトランザクションの 実行時パフォーマンスに、わずかながら影響を与えることがあります。

7.6.2.1 増分バックアップ・イメージからの復元

増分バックアップ・イメージからのリストア操作は常に、以下のステップで構成されています。

  1. 増分ターゲット・イメージを識別します。 DBA は、まず復元される最終イメージを決定し、DB2 リストア・ユーティリティーからの 増分リストア処理を要求します。 このイメージは、復元される最終イメージとなるため、増分リストアのターゲット・イメージとも呼ばれます。 このイメージに対して増分リストア・コマンドを実行すると、 このターゲット・イメージからの構成および表スペース定義で、新しい データベースを作成することができます。 増分ターゲット・イメージは、RESTORE DATABASE コマンドに TAKEN AT パラメーターを 使用することによって指定されます。
  2. 最新の全データベースまたは表スペース・イメージを復元し、適用可能な 連続増分バックアップ・イメージのベースラインを確立します。
  3. 要求された全データベースまたは表スペース増分バックアップ・イメージを、 ステップ 2 で復元されたベースライン・イメージの上に、作成された順にそれぞれ復元します。
  4. ステップ 1 によるターゲット・イメージが 2 回読み取られるまで、ステップ 3 を繰り返します。 ターゲット・イメージは、増分リストア処理が完了するまでに 2 回アクセスされます。 最初のアクセスでは、イメージから初期データのみが読み取られます。ユーザー・データは読み取られません。 2 回目のアクセスでは、完了イメージのみが読み取られて処理されます。

    リストア操作中に作成されるデータベースの正しいヒストリー、データベース構成、 および表スペース定義でデータベースが確実に構成されるようにするため、 増分リストア操作のターゲット・イメージは 2 回アクセスされなければなりません。 データベースの全バックアップ・イメージが最初に取られれた後で、表スペースが ドロップされている場合、そのイメージの表スペース・データはバックアップ・イメージから 読み取られますが、増分リストア操作中には無視されます。

例:

   1. db2 restore database sample incremental taken at <ts>
 
      説明:
        <ts> は、復元される最後の増分バックアップ・イメージを示しています。
 
   2. db2 restore database sample incremental taken at <ts1>
 
      説明:
        <ts1> は、最初の全データベース (または表スペース) イメージを
        示しています。
 
   3. db2 restore database sample incremental taken at <tsX>
 
      説明:
        <tsX> は、作成シーケンス内の各増分バックアップ・イメージを
        示しています。
 
   4. ステップ 3 を繰り返し、増分バックアップ・イメージそれぞれを復元し、
      イメージ <ts> を組み込みます。

データベース・リストア操作を試みる場合、表スペース増分バックアップ・イメージが すでに作成されているときは、表スペース・イメージをバックアップ・タイム・スタンプの 順に復元する必要があります。

7.6.3 並列リカバリ

DB2 は現在、複数のエージェントを使用して、クラッシュ・リカバリと データベース・ロールフォワード・リカバリの両方を実行します。 その結果、これらの処理のパフォーマンスはさらに向上しました。 特に対称型マルチプロセッサー (SMP) マシンの場合、データベース・リカバリ中に 複数のエージェントを使用することによって、使用可能な追加 CPU を利用できるため、 パフォーマンスがより一層向上します。

この拡張によって導入された新しいエージェント・タイプは db2agnsc です。 DB2 は、マシンの CPU の数に基づいて、データベース・リカバリに使用する エージェントの数を選択します。 SMP マシンの場合、使用されるエージェントの数は CPU の数 + 1 になります。 CPU が 1 つのマシンでは、ログの読み取り、ログ・レコードの処理、およびデータ・ページの プリフェッチをより効率的に行うため、3 つのエージェントが使用されています。

DB2 はログ・レコードをこれらのエージェントに配布し、可能であれば、ログ・レコードを 同時に再適用できるようにします。 ログ・レコードの処理はページ・レベルで並列的に行われる (同じデータ・ページ上の ログ・レコードは同じエージェントによって処理される) ため、すべての処理が 1 つの表で 実行された場合でもパフォーマンスは向上します。

7.6.4 名前付きパイプへのバックアップ

UNIX ベース・システムでローカル名前付きパイプへのデータベース・バックアップ (および 名前付きパイプからのデータベース・リストア) がサポートされるようになりました。 名前付きパイプの作成側および使用側は、ともに同じマシン上になければなりません。 パイプはローカル・ファイル・システム上にある必要があります。 名前付きパイプはローカル装置として処理されるため、ターゲットが名前付きパイプであることを 指定する必要はありません。 AIX での例:

  1. 名前付きパイプを作成します。
      mkfifo /u/dbuser/mypipe
 
  2. データベース・バックアップ操作のターゲットとして、このパイプを使用します。
      db2 backup db sample to /u/dbuser/mypipe
 
  3. データベースを復元します。
      db2 restore db sample into mynewdb from /u/dbuser/mypipe

7.6.5 分割イメージからのバックアップ

DB2 は現在、データベースの分割ミラー・コピーへの全オフライン・データベース・バックアップを サポートしています。 オンライン・バックアップはサポートされておらず、ロールフォワード保留状態のデータベースは 使用できないため、その必要はありません。 分割ミラー・バックアップ・イメージを復元する場合、分割を行うときに 活動トランザクションがあった可能性があるため、そのイメージをロールフォワードする必要があります。

注:
DB2 バージョン 7.1 フィックスパック 3 および DB2 バージョン 7.2 では、 このサポートは DMS 表スペースのみを含むデータベースにのみ制限されます。 分割後、データベースのバックアップを試み、そのデータベースに SMS 表スペースが 含まれている場合、バックアップは失敗します。

データベースを分割した後、db2inidb ユーティリティーを使用して、 以下のいずれかのオプションを指定する必要があります。

使用シナリオは以下の通りです。

7.6.6 オンデマンド・ログ・アーカイブ

DB2 では現在、回復可能データベースのアクティブ・ログをいつでも クローズ (ユーザー出口オプションが使用可能であれば、アーカイブ) できます。 ある時点までのログ・ファイルの完全なセットを収集し、それらのログ・ファイルを 使用してスタンドバイ・データベースを更新することができます。

注:
オンデマンド・ログ・アーカイブは、ログ・ファイルが すぐにアーカイブされることを保証しているわけではありません。 ログ・ファイルを切り捨ててアーカイブ要求を出しますが、ユーザー出口プログラムに 関連する遅延が発生する場合もあります。

オンデマンド・ログ・アーカイブは、新しい DB2 ARCHIVE LOG コマンド、 または新しい db2ArchiveLog API を呼び出すことによって開始できます。

7.6.7 ログ・ミラーリング

第 8 章「"データベース・リカバリ"」に、中断入出力関数の使用法に関するセクションを追加します。

DB2 は現在、データベース・レベルでのログ・ミラーリングをサポートしています。 ログ・ファイルのミラーリングは、以下の状況からデータベースを保護するために役立ちます。

アクティブ・ログの損傷 (ディスク破損の結果として) が考えられる場合、 新しい DB2 レジストリー変数 DB2_NEWLOGPATH2 を使用し、データベースの 2 次パスを指定して アクティブ・ログのコピーを管理し、ログが保管されているボリュームをミラーリングすることを 考慮しなければなりません。

DB2_NEWLOGPATH2 レジストリー変数によって、データベースは、ログ・ファイルの 同一コピーを別のパスに書き込むことができます。 物理的に別のディスク (可能であれば、別のディスク・コントローラー上のディスク) に 2 次ログ・パスを 設定するようお勧めします。 これで、ディスク・コントローラーが障害の原因になることはありません。

注:
Windows NT および OS/2 では任意のパス名に装置をマウントできないため、 これらのプラットフォームで 2 次パスを別の装置に指定することはできません。

DB2_NEWLOGPATH2 を使用可能 (1) または使用不可 (0) に することができます。 デフォルト値は 0 です。 この変数が 1 に設定されている場合、2 次パス名は文字 2 に 連結されている LOGPATH 変数の現行値になります。 たとえば、SMP 環境で LOGPATH が /u/dbuser/sqllogdir/logpath である場合、 2 次ログ・パスは /u/dbuser/sqllogdir/logpath2 になります。 MPP 環境で LOGPATH が /u/dbuser/sqllogdir/logpath である場合、 DB2 はノード標識をパスに追加して、 1 次ログ・パスとして /u/dbuser/sqllogdir/logpath/NODE0000 を使用します。 この場合、2 次ログ・パスは /u/dbuser/sqllogdir/logpath2/NODE0000 になります。

DB2_NEWLOGPATH2 が最初に使用可能になったとき、実際に使用できるようになるのは、 次のデータベースの始動で現行ログ・ファイルが完了した後です。 これは、NEWLOGPATH の現在の使用方法と同様です。

1 次または 2 次ログ・パスのいずれかで書き込みエラーが発生した場合、データベースは 問題のあるパスを「不良」とマークし、db2diag.log ファイルにメッセージを書き込み、 後続のログ・レコードを問題のない「良好」ログ・パスにのみ書き込みます。 DB2 は、現行ログ・ファイルが完了するまで「不良」パスの使用を再び試みません。 DB2 は、次のログ・ファイルを開かなければならない場合、そのパスが有効であることを確認します。 有効であれば、パスの使用を開始します。 有効でなければ、次のログ・ファイルが初めてアクセスされるまで、そのパスの使用を再び試みません。 ログ・パスの同期化は試みられませんが、DB2 は、発生したアクセス・エラーに関する 情報を保管し、ログ・ファイルのアーカイブ時に正しいパスを使用できるようにします。 問題のない「良好」パスへの書き込み中に障害が発生した場合、データベースは異常終了します。

7.6.8 Sun Solaris および HP における、プラットフォーム間のバックアップおよびリストア・サポート

Sun Solaris と HP において、プラットフォーム間のバックアップおよびリストアがサポートされています。 バックアップ・イメージをシステム間で転送するには、バイナリー・モードで行う必要があります。 ターゲット・システムのデータベースは、オリジナル・データベースが作成されたシステムと同じ コード・ページ/領域で作成されなければなりません。

7.6.9 DB2 データ・リンク・マネージャーに関する考慮事項/バックアップ・ユーティリティーに関する考慮事項

このセクションの 2 番目の段落を以下の段落で置き換えます。

   ファイルがリンクされている場合、データ・リンク・サーバーは、それらの
   ファイルが ADSM のようなアーカイブ・サーバーまたはディスクに非同期的に
   コピーされるようスケジュールします。バックアップ・ユーティリティーを
   実行する場合、DB2 は、コピーするようにスケジュールされているすべての
   ファイルがコピーされていることを確認します。バックアップ処理の開始時に、
   DB2 は DB2 構成ファイルで指定されたすべてのデータ・リンク・サーバーに
   連絡します。データ・リンク・サーバーに 1 つ以上のリンク・ファイルが含まれ、
   そのサーバーが稼動していない場合、またはバックアップ処理中に稼動が停止した
   場合、バックアップには完全な DATALINK 情報は含まれません。
   バックアップ処理自体は、正常に完了します。データ・リンク・サーバーが
   そのデータベースに対して有効であることをマークし直すには、未解決のすべての
   バックアップのバックアップ処理を正常に完了する必要があります。
   データ・リンク・サーバーでの完了を待機している未解決のバックアップが、
   num_db_backups の値の 2 倍に達しているときに (以下参照) バックアップが
   開始された場合、バックアップ処理は失敗します。データ・リンク・サーバーを
   再始動して、未解決のバックアップを完了しないと、追加のバックアップを
   実行することはできません。

7.6.10 DB2 データ・リンク・マネージャーに関する考慮事項/リストアおよびロールフォワード・ ユーティリティーに関する考慮事項

以下の 2 つの文:

   データベースまたは表スペースを復元するときに WITHOUT DATALINK を
   指定しないと...
   および
 
   データベースまたは表スペースを復元するときに WITHOUT DATALINK を
   指定すると...

で始まる段落を以下の段落で置き換えます。

   データベースまたは表スペースを復元する場合、そのリストア操作を正常に
   完了するには、以下の条件が満たされている必要があります。
   o バックアップ・ファイルに記録されているデータ・リンク・サーバーが
     稼動していない場合でも、リストア操作は正常に完了します。
     見つからないデータ・リンク・サーバーに影響を受ける DATALINK 列情報を
     持つ表は、リストア操作 (使用されていれば、ロールフォワード操作) の
     完了後、データ・リンク調整保留状態になります。
     このリストア処理が正常に完了しないと、データベースに対して使用可能な
     ものとしてデータ・リンク・サーバーを再びマークすることはできません。
   o リストア処理中に、バックアップ・ファイルに記録されているデータ・リンク・
     サーバーが稼動が停止した場合、リストア操作は失敗します。データ・リンク・
     サーバーをダウンすると、リストア操作を再開できます (上の説明を参照)。
   o いずれかのデータ・リンク・サーバーで、前のデータベース・リストア操作が
     完了していない場合、後続のデータベースまたは表スペース・リストア操作は、
     それらのデータ・リンク・サーバーが再始動され、未完了のリストア操作が
     完了するまで、正常に完了することはありません。
   o バックアップ・ファイルに記録された DATALINK 列に関する情報はすべて、
     該当するデータ・リンク・サーバーの登録表に存在していなければ
     なりません。
     DATALINK 列に関するすべての情報が登録表に記録されていない場合、
     見つからない DATALINK 列情報を持つ表は、リストア操作 (使用されて
     いれば、ロールフォワード操作) の完了後、データ・リンク調整不能状態に
     なります。
     登録表にバックアップが記録されていない場合、与えられたバックアップ・
     ファイルが num_db_backups の値より前のもので、すでに「ガーベッジ・
     コレクション」されていると考えられます。つまり、この以前の
     バックアップからのアーカイブ・ファイルは、すでに除去されており、
     復元できません。DATALINK 列を持つ表はすべて、データ・リンク調整保留
     状態になります。
     登録表にバックアップが記録されていない場合、データ・リンク・サーバーが
     稼動していないために、バックアップ処理が完了していないと考えられます。
     DATALINK 列を持つ表はすべて、データ・リンク調整保留状態になります。
     データ・リンク・サーバーが再始動されると、リストア処理の前にバック
     アップ処理が完了します。
     ユーザーが表を使用することはできますが、DATALINK 列内の値はファイルを
     正しく参照しない場合があります (たとえば、DATALINK 列の値と一致する
     ファイルが見つからない場合があります)。このような問題を回避するには、
     "SET CONSTRAINTS for tablename TO DATALINK RECONCILE PENDING"
     ステートメントを出すことによって、表をチェック・ペンディング状態にすることができます。

リストア処理の後、データ・リンク調整不能状態の表がある場合、 「表を Datalink_Reconcile_Not_Possible 状態から解除」で説明されているいずれかの方法で、 DATALINK 列データを修正することができます。

最初の段落の最後の注釈はそのまま適用されます。

このセクションの最後に以下を追加してください。

   データベース・バックアップ・イメージ内の datalink.cfg ファイルには、
   バックアップの時点の datalink.cfg だけが反映されているため、あまり
   一般的ではないリカバリにも備えて datalink.cfg をアーカイブするよう強く
   お勧めします。すべてのリカバリに備えるには、最新の datalink.cfg
   ファイルが必要です。そのため、ADD DATALINKS MANAGER または DROP
   DATALINKS MANAGER コマンド呼び出しの後、常に datalink.cfg ファイルを
   バックアップしなければなりません。最新の datalink.cfg ファイルが
   ディスク上にない場合、この datalink.cfg ファイルを取り出すために
   役立ちます。
   最新の datalink.cfg ファイルがディスク上ない場合、(バックアップ・イメージ
   から復元された) 既存の datalink.cfg ファイルを、ロールフォワード操作の
   実行前にアーカイブされた最新の datalink.cfg ファイルで置き換えます。

7.6.11 ロールフォワードなしで、オフライン・バックアップからデータベースを復元

ロールフォワードを伴わないリストアは、データベース・レベルでのみ実行できます。 表スペース・レベルでは実行できません。 ロールフォワードなしでデータベースを復元するには、回復不能データベース (循環ログを 使用するデータベース) を復元するか、 RESTORE DATABASE コマンドに WITHOUT ROLLING FORWARD パラメーターを指定してください。

WITHOUT DATALINK オプションでリストア・ユーティリティーを使用する場合、 DATALINK 列を持つ表はすべてデータ・リンク調整保留 (DRP) 状態になり、リストア操作中に データ・リンク・サーバーによる調整は実行されません。

WITHOUT DATALINK オプションを使用せず、バックアップ・ファイルに記録された データ・リンク・サーバーがデータベースに定義されていない (DROP DATALINKS MANAGER コマンドで ドロップされている) 場合、ドロップされたデータ・リンク・サーバーを 参照している DATALINK データを持つ表は、リストア・ユーティリティーによって データ・リンク調整保留状態になります。

WITHOUT DATALINK オプションを使用し、すべてのデータ・リンク・サーバーが 使用可能で、DATALINK 列に関するすべての情報が登録表に完全に記録されている場合、 バックアップ・ファイルに記録されている各データ・リンク・サーバーについて以下の項目が発生します。

注:
データ・リンク・サーバーが 1 つも稼動していないときに、 データベース・リストア操作に使用されたバックアップ・イメージが取られた場合、 このバックアップ内の DATALINK 情報が不完全なため、前述の処理は行われません。 また、ロールフォワードの有無にかかわらず、データベース・リストア後に、 データベース・リストア操作に使用されたバックアップ・イメージが取られた場合も、 前述の処理は行われません。 いずれの場合も、DATALINK 列を持つ表はすべてデータ・リンク調整保留状態になり、 リストア操作中にデータ・リンク・サーバーによる調整は実行されません。

7.6.12 データベースと表スペースを復元、およびログの最後までロールフォワード

データベースまたは表スペースを復元し、ログの最後までロールフォワード (つまり、すべての ログが提供されている) する場合、バックアップ・ファイル内に記録されている データ・リンク・サーバーの少なくとも 1 つがリストア操作中に稼動していない場合を除き、 調整検査は必要ありません。 ロールフォワード操作用にすべてのログが提供されているかどうかが確かでない場合、 または DATALINK 値を調整する必要があるを考えられる場合、以下の処理を行ってください。

  1. 関連する表に、次の SQL ステートメントを出します。

       SET CONSTRAINTS FOR tablename TO DATALINK RECONCILE PENDING
    
    これで、表がデータ・リンク調整保留状態およびチェック・ペンディング状態になります。
  2. 表をチェック・ペンディング状態にしたくない場合、次の SQL ステートメントを出してください。

       SET CONSTRAINTS FOR tablename IMMEDIATE CHECKED
    
    これで、表のチェック・ペンディング状態が解除されますが、データ・リンク調整保留状態は解除されません。 データ・リンク調整保留状態を解除するには、調整ユーティリティーを使用してください。

バックアップ・ファイルに、データベースからドロップされた DB2 データ・リンク・マネージャーを 参照している DATALINK データが含まれている (つまり、バックアップが取られたときに、 DB2 データ・リンク・マネージャーがデータベースに登録されていた) 場合があります。 ドロップされた DB2 データ・リンク・マネージャーを参照している DATALINK データを持つ 表を少なくとも 1 つ含む、ロールフォワードされている表スペースそれぞれについて、 すべての表はロールフォワード・ユーティリティーによって DRP 状態になります。

7.6.13 DB2 データ・リンク・マネージャーとリカバリの相互作用

以下の表は、実行可能なリカバリのタイプ、リストアおよびロールフォワードの実行中に 発生する DB2 データ・リンク・マネージャー処理、およびリカバリ完了後に調整ユーティリティーを実行する必要性の有無を示したものです。
リカバリのタイプ リストア中の DB2 データ・リンク・マネージャー処理 ロールフォワード中の DB2 データ・リンク・マネージャー処理 調整
回復不能 データベース (logretain=NO)
完全バックアップのデータベース・リストア、 データベース・リンク・サーバーはすべて稼動 高速調整を実行 N/A ファイル・リンクの問題が考えられる場合、オプションで実行可能
WITHOUT DATALINK オプションによるデータベース・リストア 表を Datalink_Reconcile_Pending 状態にする N/A 必須
完全バックアップのデータベース・リストア、 少なくとも 1 つのデータベース・リンク・サーバーがダウン ダウンしているデータ・リンク・サーバーへのリンクを持たない 表スペース内の表でのみ高速調整を実行。それ以外の表を Datalink_Reconcile_Pending 状態にする なし ダウンしているデータ・リンク・サーバーへのリンクを持つ 表スペース内の表で必須
不完全バックアップのデータベース・リストア、 データベース・リンク・サーバーはすべて稼動 高速調整は実行されない。 DATALINK 列を持つ表すべてを Datalink_Reconcile_Pending 状態にする なし 必須
回復可能 データベース (logretain=YES)
WITHOUT ROLLING FORWARD オプションによる完全バックアップの データベース・リストア、データベース・リンク・サーバーはすべて稼動 高速調整を実行 N/A オプション
WITHOUT ROLLING FORWARD および WITHOUT DATALINK オプションによる 完全または不完全バックアップのデータベース・リストア、データベース・リンク・サーバーは稼動またはダウン 表を Datalink_Reconcile_Pending 状態にする N/A 必須
WITHOUT ROLLING FORWARD オプションによる完全バックアップの データベース・リストア、少なくとも 1 つのデータベース・リンク・サーバーがダウン ダウンしているデータ・リンク・サーバーへのリンクを持たない 表スペース内の表でのみ高速調整を実行。それ以外の表を Datalink_Reconcile_Pending 状態にする N/A ダウンしているデータ・リンク・サーバーへのリンクを持つ 表スペース内の表で必須
WITHOUT ROLLING FORWARD オプションによる不完全バックアップの データベース・リストア、データベース・リンク・サーバーは稼動またはダウン 高速調整は実行されない。 DATALINK 列を持つ表すべてを Datalink_Reconcile_Pending 状態にする N/A 必須
完全バックアップのデータベース・リストア、ログの 最後までロールフォワード、データベース・リンク・サーバーはすべて稼動 アクションなし アクションなし オプオプション
完全バックアップのデータベース・リストア、ログの最後まで ロールフォワード、ロールフォワードの処理中に少なくとも 1 つのデータ・リンク・サーバーがダウン アクションなし アクションなし オプション
完全または不完全バックアップのデータベース・リストア、ログの最後まで ロールフォワード、リストア中にいずれかのデータ・リンク・サーバーがダウン アクションなし DATALINK 列を持つ表すべてを Datalink_Reconcile_Pending 状態にする DATALINK 列を持つ表すべてに必須
不完全バックアップのデータベース・リストア、ログの最後まで ロールフォワード、リストア中にデータ・リンク・サーバーがすべて稼動 アクションなし アクションなし オプション
完全または不完全バックアップのデータベース・リストア、 ログの最後までロールフォワード、データ・リンク・サーバーはすべて稼動、いずれかの データ・リンク・サーバーでバックアップ不明 アクションなし 不明なバックアップを持つデータ・リンク・サーバーへの リンクを持つ表スペース内の表すべてを Datalink_Reconcile_Pending 状態にする 必須
完全バックアップの表スペース・リストア、ログの最後まで ロールフォワード、データベース・リンク・サーバーはすべて稼動 アクションなし アクションなし オプション
完全バックアップの表スペース・リストア、ログの最後まで ロールフォワード、ロールフォワードの処理中に少なくとも 1 つのデータ・リンク・サーバーがダウン アクションなし アクションなし オプション
完全または不完全バックアップの表スペース・リストア、ログの最後まで ロールフォワード、リストアの処理中にいずれかのデータ・リンク・サーバーがダウン アクションなし ダウンしているデータ・リンク・サーバーへのリンクを持つ 表スペース内の表すべてを Datalink_Reconcile_Pending 状態にする ダウンしているデータ・リンク・サーバーへのリンクを持つ 表スペース内の表で必須
不完全バックアップの表スペース・リストア、ログの最後まで ロールフォワード、データベース・リンク・サーバーはすべて稼動 アクションなし アクションなし オプション
完全または不完全バックアップのデータベース・リストア、指定時刻まで ロールフォワード、リストア/ロールフォワードの処理中にデータ・リンク・サーバーが稼動またはダウン アクションなし 表を Datalink_Reconcile_Pending 状態にする 必須
完全または不完全バックアップの表スペース・リストア、指定時刻まで ロールフォワード、リストア/ロールフォワードの処理中にデータ・リンク・サーバーが稼動またはダウン アクションなし 表を Datalink_Reconcile_Pending 状態にする 必須
ロールフォワードなしで、異なるデータベース名、別名、 ホスト名、またはインスタンスにデータベース・リストア (NOTE1) 表を Datalink_Reconcile _Not_Possible 状態にする N/A オプション。 ただし、Datalink_Reconcile _Not_Possible 状態の表は手操作で修正する必要あり
異なるデータベース名、別名、ホスト名、またはインスタンスに データベース・リストア、ロールフォワード アクションなし 表を Datalink_Reconcile _Not_Possible 状態にする オプション。 ただし、Datalink_Reconcile _Not_Possible 状態の表は手操作で修正する必要あり
WITHOUT DATALINK オプションを指定または指定せずに、 ロールフォワードなしで、不要なバックアップ (イメージはデータ・リンク・サーバー上で ガーベッジ・コレクション済み) からデータベース・リストア (NOTE1) 表を Datalink_Reconcile_Pending 状態にする アクションなし 必須
WITHOUT DATALINK オプションを指定または指定せずに、 不要なバックアップ (イメージはデータ・リンク・サーバー上でガーベッジ・コレクション済み) から データベース・リストア、ロールフォワード アクションなし 表を Datalink_Reconcile_Pending 状態にする 必須
不要なバックアップ (イメージはデータ・リンク・サーバー上で ガーベッジ・コレクション済み) から表スペース・リストア、ロールフォワードする アクションなし 表を Datalink_Reconcile_Pending 状態にする 必須

注:

  1. オフライン・バックアップおよび WITHOUT ROLLING FORWARD オプションによる リストア (logretain がオン)、またはオフライン・バックアップによる リストア (logretain がオフ)。

  2. 完全バックアップとは、必要なデータ・リンク・サーバーすべてが 稼動しているときに取られたバックアップのことです。 不完全バックアップとは、稼動していないデータ・リンク・サーバーが 少なくとも 1 つあるときに取られたバックアップのことです。

  3. データベース・リストア操作に使用されたバックアップ・イメージがデータベース・リストアの 後で取られたものである場合、ロールフォワードの有無にかかわらず、高速調整処理は実行されません。 この場合、DATALINK 列を持つ表すべてが Datalink_Reconcile_Pending 状態になります。

7.6.14 調整を必要とする状態の検出

調整ユーティリティーを実行しなければならない状態:


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