第 8 章「"データベース・リカバリ"」に、中断入出力関数の使用法に関するセクションを追加します。
db2inidb は DB2 に添付された新しいツールで、クラッシュ・リカバリを実行でき、また データベースをロールフォワード保留状態にすることができます。
中断入出力は、連続的なシステム使用可能性を、オンライン分割ミラー・ハンドリングの フル・インプリメンテーション (つまりデータベースをシャットダウンせずにミラーを 分割) を提供することでサポートします。大きなデータベースでバックアップをオンラインまたは オフラインにすることが難しい場合は、中断入出力と分割ミラーを使用してミラー・イメージから バックアップまたはシステム・コピーを行うことができます。
ストレージ装置のミラーリングの度合いによって、db2inidb の使用法は変わります。 以下の使用法では、データベース全体がストレージ・システムを通じて一貫してミラーリングされていることを 想定しています。
マルチノード環境で、いずれかの区分から分割イメージを使用できるようにするには、 db2inidb ツールを区分それぞれで実行する必要があります。 db2inidb ツールは、すべての区分で同時に実行することができます。
この目的は、1 次データベースの レプリケーションを読み取りに使用することです。 レプリケーション・データベースの作成手順は以下の通りです。
db2 set write suspend for database
db2 set write resume for database
コマンドの実行後、1 次システムの データベースは正常な状態に戻るはずです。
db2start
db2inidb database_name AS SNAPSHOT
この処理はオフライン・バックアップにも使用することができますが、 1 次システムに復元する場合、ログ・チェーンが一致しないために、このバックアップを ロールフォワードに使用することはできません。
ミラーリングされた (スタンドバイ) データベースは ログを通じて連続的にロールフォワードするため、1 次データベースで作成されている新しいログは、 1 次システムから絶えずフェッチされます。分割ミラーをスタンドバイ・データベースとして使用する 方法は以下の通りです。
ミラーリングされた システムを 1 次システムに対して復元するためのバックアップ・イメージとして 使用する方法は、以下の通りです。
db2start
db2inidb database_alias AS MIRROR
第 8 章「"データベース・リカバリ"」に、増分バックアップおよびリカバリに関する 以下のセクションを追加します。
データベース (特にウェアハウス) のサイズがテラバイトからペタバイトの 範囲に展開するにつれて、これらのデータベースのバックアップおよびリカバリに 必要な時間とハードウェア・リソースも大幅に増加します。 大規模なデータベースを扱っている場合、データベースおよび表スペースの 全バックアップを実行することは、データベースの複数コピーのストレージ要件が 巨大になるため、最適なアプローチとはいえません。 以下の点に注意してください。
DB2 は現在、増分バックアップおよびリカバリをサポートしています (ただし、 大きなフィールドおよびラージ・オブジェクト・データはサポートしません)。 増分バックアップは、直前のバックアップが取られた後で 更新されたページのみを含むバックアップ・イメージです。 増分バックアップ・イメージそれぞれには、更新されたデータと索引ページに加え、 通常、全バックアップ・イメージに保管される初期データベース・メタデータ (データベース構成、 表スペース定義、データベース・ヒストリーなど) も含まれます。
以下の 2 つのタイプの増分バックアップがサポートされています。
増分バックアップ・イメージとデルタ・バックアップ・イメージとの主な相違点は、 時間の経過とともに変化するオブジェクトの連続バックアップを取るときの動作です。 連続増分イメージそれぞれには、以前の増分イメージの内容全体に加え、直前の バックアップが作成された後で変更されたデータや追加されたデータも含まれます。 デルタ・バックアップ・イメージには、直前のイメージが作成された後で変更されたページのみが含まれます。
データベースおよび表スペース増分バックアップの組み合わせは、 オンライン・モードとオフライン・モードの両方で許可されています。 バックアップについて計画する場合、データベースおよび表スペース増分バックアップを 組み合わせると、前のデータベース・バックアップは必ずしも 1 つのイメージではなく、 別の機会に取られた以前のデータベースおよび表スペース・バックアップの 固有セットになる場合があるため、注意してください。
データベースまたは表スペースを一貫性のある状態に再作成するには、 復元するオブジェクト全体 (データベースまたは表スペース) の一貫性のある イメージを使用してリカバリ処理を開始し、以下に説明する順序 (「リストア・メソッド」 セクションを参照) でそれぞれの適切な増分バックアップ・イメージを適用する必要があります。
データベース更新のトラッキングを可能にするため、DB2 は、 以下の 2 つの値を設定できる新しいデータベース構成パラメーター TRACKMOD をサポートしています。
デフォルト TRACKMOD 設定は、既存のデータベースであれば NO、 新しいデータベースであれば YES です。
トラッキングの細分度は、SMS および DMS 表スペースの両方の表スペース・レベルです。
データベースへの更新のトラッキングは、データを更新または挿入するトランザクションの 実行時パフォーマンスに、わずかながら影響を与えることがあります。
増分バックアップ・イメージからのリストア操作は常に、以下のステップで構成されています。
リストア操作中に作成されるデータベースの正しいヒストリー、データベース構成、 および表スペース定義でデータベースが確実に構成されるようにするため、 増分リストア操作のターゲット・イメージは 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> を組み込みます。
データベース・リストア操作を試みる場合、表スペース増分バックアップ・イメージが すでに作成されているときは、表スペース・イメージをバックアップ・タイム・スタンプの 順に復元する必要があります。
DB2 は現在、複数のエージェントを使用して、クラッシュ・リカバリと データベース・ロールフォワード・リカバリの両方を実行します。 その結果、これらの処理のパフォーマンスはさらに向上しました。 特に対称型マルチプロセッサー (SMP) マシンの場合、データベース・リカバリ中に 複数のエージェントを使用することによって、使用可能な追加 CPU を利用できるため、 パフォーマンスがより一層向上します。
この拡張によって導入された新しいエージェント・タイプは db2agnsc です。 DB2 は、マシンの CPU の数に基づいて、データベース・リカバリに使用する エージェントの数を選択します。 SMP マシンの場合、使用されるエージェントの数は CPU の数 + 1 になります。 CPU が 1 つのマシンでは、ログの読み取り、ログ・レコードの処理、およびデータ・ページの プリフェッチをより効率的に行うため、3 つのエージェントが使用されています。
DB2 はログ・レコードをこれらのエージェントに配布し、可能であれば、ログ・レコードを 同時に再適用できるようにします。 ログ・レコードの処理はページ・レベルで並列的に行われる (同じデータ・ページ上の ログ・レコードは同じエージェントによって処理される) ため、すべての処理が 1 つの表で 実行された場合でもパフォーマンスは向上します。
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
DB2 は現在、データベースの分割ミラー・コピーへの全オフライン・データベース・バックアップを サポートしています。 オンライン・バックアップはサポートされておらず、ロールフォワード保留状態のデータベースは 使用できないため、その必要はありません。 分割ミラー・バックアップ・イメージを復元する場合、分割を行うときに 活動トランザクションがあった可能性があるため、そのイメージをロールフォワードする必要があります。
データベースを分割した後、db2inidb ユーティリティーを使用して、 以下のいずれかのオプションを指定する必要があります。
使用シナリオは以下の通りです。
たとえば報告書の作成に使用する 1 次データベースの読み取り専用レプリケーションを作成することが目的です。 これを行うには、以下のステップにしたがってください。
db2 set write suspend for database
db2 set write resume for database
これで、1 次システムのデータベースは正常な状態に戻ります。
db2start
db2inidb <db_name> as snapshot
この処理はオフライン・バックアップにも使用することができますが、 1 次システムに復元する場合、ログ・チェーンが一致しないために、このバックアップを ロールフォワードに使用することはできません。
ミラーリングされた (スタンドバイ) データベースはログを通じて連続的に ロールフォワードし、1 次データベースで作成される新しいログも 1 次システムから連続的にフェッチされます。 分割ミラーをスタンバイ・データベースとして使用するには、以下のステップにしたがってください。
db2 set write suspend for database
db2 set write resume for database
これで、1 次システムのデータベースは正常な状態に戻ります。
db2inidb <db_name> as standby
db2 rollforward db <db_name> to end of logs
ミラーリングされたシステムをバックアップ・イメージとして使用し、1 次システムを 回復する方法:
db2start
db2inidb <dbname> as mirror
クラッシュ・リカバリなしで分割ミラーのオフライン・バックアップを実行するということは、 バックアップ・イメージを 1 次システムの上に復元することができるということです。 これを行うには、以下のステップにしたがってください。
db2 set write suspend for database
db2 set write resume for database
これで、1 次システムのデータベースは正常な状態に戻ります。
db2start
db2inidb <db_name> as standby
db2 backup database <db_name>
これで、暗黙的なデータベース接続が行われますが、DB2 クラッシュ・リカバリは開始されません。
DB2 では現在、回復可能データベースのアクティブ・ログをいつでも クローズ (ユーザー出口オプションが使用可能であれば、アーカイブ) できます。 ある時点までのログ・ファイルの完全なセットを収集し、それらのログ・ファイルを 使用してスタンドバイ・データベースを更新することができます。
オンデマンド・ログ・アーカイブは、新しい DB2 ARCHIVE LOG コマンド、 または新しい db2ArchiveLog API を呼び出すことによって開始できます。
第 8 章「"データベース・リカバリ"」に、中断入出力関数の使用法に関するセクションを追加します。
DB2 は現在、データベース・レベルでのログ・ミラーリングをサポートしています。 ログ・ファイルのミラーリングは、以下の状況からデータベースを保護するために役立ちます。
アクティブ・ログの損傷 (ディスク破損の結果として) が考えられる場合、 新しい DB2 レジストリー変数 DB2_NEWLOGPATH2 を使用し、データベースの 2 次パスを指定して アクティブ・ログのコピーを管理し、ログが保管されているボリュームをミラーリングすることを 考慮しなければなりません。
DB2_NEWLOGPATH2 レジストリー変数によって、データベースは、ログ・ファイルの 同一コピーを別のパスに書き込むことができます。 物理的に別のディスク (可能であれば、別のディスク・コントローラー上のディスク) に 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 は、発生したアクセス・エラーに関する 情報を保管し、ログ・ファイルのアーカイブ時に正しいパスを使用できるようにします。 問題のない「良好」パスへの書き込み中に障害が発生した場合、データベースは異常終了します。
Sun Solaris と HP において、プラットフォーム間のバックアップおよびリストアがサポートされています。 バックアップ・イメージをシステム間で転送するには、バイナリー・モードで行う必要があります。 ターゲット・システムのデータベースは、オリジナル・データベースが作成されたシステムと同じ コード・ページ/領域で作成されなければなりません。
このセクションの 2 番目の段落を以下の段落で置き換えます。
ファイルがリンクされている場合、データ・リンク・サーバーは、それらの ファイルが ADSM のようなアーカイブ・サーバーまたはディスクに非同期的に コピーされるようスケジュールします。バックアップ・ユーティリティーを 実行する場合、DB2 は、コピーするようにスケジュールされているすべての ファイルがコピーされていることを確認します。バックアップ処理の開始時に、 DB2 は DB2 構成ファイルで指定されたすべてのデータ・リンク・サーバーに 連絡します。データ・リンク・サーバーに 1 つ以上のリンク・ファイルが含まれ、 そのサーバーが稼動していない場合、またはバックアップ処理中に稼動が停止した 場合、バックアップには完全な DATALINK 情報は含まれません。 バックアップ処理自体は、正常に完了します。データ・リンク・サーバーが そのデータベースに対して有効であることをマークし直すには、未解決のすべての バックアップのバックアップ処理を正常に完了する必要があります。 データ・リンク・サーバーでの完了を待機している未解決のバックアップが、 num_db_backups の値の 2 倍に達しているときに (以下参照) バックアップが 開始された場合、バックアップ処理は失敗します。データ・リンク・サーバーを 再始動して、未解決のバックアップを完了しないと、追加のバックアップを 実行することはできません。
以下の 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 ファイルで置き換えます。
ロールフォワードを伴わないリストアは、データベース・レベルでのみ実行できます。 表スペース・レベルでは実行できません。 ロールフォワードなしでデータベースを復元するには、回復不能データベース (循環ログを 使用するデータベース) を復元するか、 RESTORE DATABASE コマンドに WITHOUT ROLLING FORWARD パラメーターを指定してください。
WITHOUT DATALINK オプションでリストア・ユーティリティーを使用する場合、 DATALINK 列を持つ表はすべてデータ・リンク調整保留 (DRP) 状態になり、リストア操作中に データ・リンク・サーバーによる調整は実行されません。
WITHOUT DATALINK オプションを使用せず、バックアップ・ファイルに記録された データ・リンク・サーバーがデータベースに定義されていない (DROP DATALINKS MANAGER コマンドで ドロップされている) 場合、ドロップされたデータ・リンク・サーバーを 参照している DATALINK データを持つ表は、リストア・ユーティリティーによって データ・リンク調整保留状態になります。
WITHOUT DATALINK オプションを使用し、すべてのデータ・リンク・サーバーが 使用可能で、DATALINK 列に関するすべての情報が登録表に完全に記録されている場合、 バックアップ・ファイルに記録されている各データ・リンク・サーバーについて以下の項目が発生します。
データベースまたは表スペースを復元し、ログの最後までロールフォワード (つまり、すべての ログが提供されている) する場合、バックアップ・ファイル内に記録されている データ・リンク・サーバーの少なくとも 1 つがリストア操作中に稼動していない場合を除き、 調整検査は必要ありません。 ロールフォワード操作用にすべてのログが提供されているかどうかが確かでない場合、 または DATALINK 値を調整する必要があるを考えられる場合、以下の処理を行ってください。
SET CONSTRAINTS FOR tablename TO DATALINK RECONCILE PENDINGこれで、表がデータ・リンク調整保留状態およびチェック・ペンディング状態になります。
SET CONSTRAINTS FOR tablename IMMEDIATE CHECKEDこれで、表のチェック・ペンディング状態が解除されますが、データ・リンク調整保留状態は解除されません。 データ・リンク調整保留状態を解除するには、調整ユーティリティーを使用してください。
バックアップ・ファイルに、データベースからドロップされた DB2 データ・リンク・マネージャーを 参照している DATALINK データが含まれている (つまり、バックアップが取られたときに、 DB2 データ・リンク・マネージャーがデータベースに登録されていた) 場合があります。 ドロップされた DB2 データ・リンク・マネージャーを参照している DATALINK データを持つ 表を少なくとも 1 つ含む、ロールフォワードされている表スペースそれぞれについて、 すべての表はロールフォワード・ユーティリティーによって DRP 状態になります。
以下の表は、実行可能なリカバリのタイプ、リストアおよびロールフォワードの実行中に
発生する 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 状態にする | 必須 |
注:
調整ユーティリティーを実行しなければならない状態:
この場合、DATALINK データを持つ表はデータ・リンク調整保留状態になります。 このような表それぞれに対して、調整ユーティリティーを呼び出さなければなりません。