ポイント・イン・タイム・リカバリー

以前の時点へのデータのリカバリーのことを、 ポイント・イン・タイム・リカバリー と呼びます。オブジェクトを特定の RBA、LRSN、またはイメージ・コピーまでリカバリーできます。RECOVER ユーティリティーのポイント・イン・タイム・リカバリーのオプション を使用すると、このタイプのリカバリーを行えます。これらのオプションには TOCOPY、TOLOGPOINT、TOLASTCOPY、TORBA、および TOLASTFULLCOPY があります。

TORBA または TOLOGPOINT を使用して、 オブジェクトを任意の RBA または LRSN までリカバリーできます。TOCOPY、TOLASTCOPY、または TOLASTFULLCOPY を使用して、オブジェクトを前のイメージ・コピーまでリカバリーできます。

RBA または LRSN までオブジェクトをリカバリーする場合、その RBA または LRSN は、整合ポイント・イン・タイムである必要はありません。RECOVER ユーティリティーは、コミットされていない作業単位 を自動的に処理し、データは整合した状態のままにされます。

イメージ・コピーまでオブジェクトをリカバリーする場合、イメージ・コピーが整合ポイント・イン・タイムかどうかは、イメージ・コピーのタイプに応じて異なります。SHRLEVEL REFERENCE を使用して取られたイメージ・コピーは、整合点です。SHRLEVEL CHANGE を使用して取られたイメージ・コピーは、明示的な整合点ではありません。

別の明示的な整合点として静止ポイント があり、これは DB2® QUIESCE ユーティリティーを実行した結果、データが整合する点です。

整合ポイント・イン・タイムまでのリカバリーは、バックアウトする必要があるコミットされていない作業単位がないため、最も効率的です。

推奨事項: TOCOPY、TOLASTCOPY、または TOLASTFULLCOPY を指定 して RECOVER ユーティリティーを使用することによって、あるイメージ・コピーにまでデータをリカバリーする場合は、 SHRLEVEL REFERENCE オプションで作成されたコピーを指定してください。

SHRLEVEL CHANGE を指定して取られたコピーまでリカバリーする際に整合性を保つには、コピーの完了直後にリカバリー・ポイントを指定します。このポイントを検出するには、SYSIBM.SYSCOPY 内で SHRLEVEL CHANGE コピーに関するレコードを見つけ、PIT_RBA 列の値を使用します。RECOVER ステートメントで TORBA または TOLOGPOINT オプションを使用して、このリカバリー・ポイントを指定します。

フォールバック・リカバリーの場合を除いて、ポイント・イン・タイムまでデータをリカバリーした後にフル・イメージ・コピーを作成する必要はありません。ポイント・イン・タイム・リカバリーに 関連した RBA または LRSN を DB2 は SYSIBM.SYSCOPY カタログ表に記録して、将来のリカバリー操作では、不要なログ・レコードの範囲 をスキップできるようにします。

TOCOPY、TOLASTCOPY、 または TOLASTFULLCOPY オプションを指定して、あるポイント・イン・タイムまでデータを リカバリーする場合、RECOVER は、関連する索引スペースをすべて REBUILD ペンディング 状況にします。TOLOGPOINT または TORBA オプションを指定して、あるポイント・イン・タイムまで データをリカバリーする場合は、関連する索引スペースを RECOVER が REBUILD ペンディング 状況にするのは、索引がリカバリーされるのが、それらの対応する表スペースと 同じ RECOVER ステートメントではない場合です。その理由は、表スペースのみのポイント・イン・タイム・リカバリー を行うと、データは整合状態に、索引は不整合状態になるからです。

変更の始まり次のいずれかの方法で、REBUILD ペンディング状態を解除できます。変更の終わり

変更の始まり
  • 索引に対して REBUILD INDEX を実行します。
  • 索引に対してポイント・イン・タイムまでの RECOVER を実行します。この場合、表スペースが索引と同じ RECOVER ユーティリティー・ステートメントでリカバリーされないので、DB2 は索引に対して CHECK ペンディング状態を設定します。
変更の終わり

いずれかのポイント・イン・タイム・リカバリーのオプション を使用して、非パーティション化表スペースの単一のデータ・セットを リカバリーすると、DB2 は メッセージ DSNU520I を発行して、その表スペースは RECOVER ジョブの後で不整合になる可能性 があることを警告します。このようなポイント・イン・タイム・リカバリーが行われると、ディクショナリー のない圧縮データが存在することになったり、現行ディクショナリーが入っているデータ・セットが 上書きされてしまう可能性さえ生じることになります。

ポイント・イン・タイム・リカバリーのオプション を使用して、増加対応パーティション表スペースをリカバリーする場合で、その表スペースのイメージ・コピーには現在の表スペースよりも少ない数のパーティションしかない 場合は、余分のパーティション (現在は定義されているが、 イメージ・コピー内にない) は RECOVER 処理の後は空になります。

再配列行フォーマットの表スペースまたはパーティションが、その表スペースまたはパーティションが基本行フォーマットだったポイント・イン・タイムまでリカバリーされると、RECOVER 処理後にその表スペースまたはパーティションは基本行フォーマットに戻ります。同様に、基本行フォーマットの表スペースまたはパーティションが、その表スペースまたはパーティションが再配列行フォーマットだったポイント・イン・タイムまでリカバリーされると、RECOVER 処理後にその表スペースまたはパーティションは再配列行フォーマットに戻ります。

表スペースのセットに 対してポイント・イン・タイム・リカバリーを実行した場合は、 その後に CHECK DATA を使用して不整合をチェックできます。

RECOVER ユーティリティーを使用して、表スペース・セットをポイント・イン・タイムまでリカバリーする場合は、必ず表スペースの全セットを同じポイント・イン・タイムまでリカバリーする必要があります。そのセットの全メンバーが含まれているわけではない場合、あるいはセット全体を同じポイント・イン・タイムまでリカバリーするわけではない場合、RECOVER は、セット内のすべての表スペースに関して補助 CHECK ペンディング状況を設定します。

また、ポイント・イン・タイム・リカバリーとポイント・イン・タイム・リカバリー・オプションを使用して、リフレッシュ・ペンディング状況 (REFP) にあるすべてのユーザー定義の表スペースと索引を リカバリーすることもできます。

推奨事項: ポイント・イン・タイム・リカバリーの実行後は、REORG TABLESPACE および REBUILD INDEX を実行して、リアルタイム統計を設定してください。リアルタイム統計に対するポイント・イン・タイム・リカバリーの効果について詳しくは、RECOVER 実行の影響を参照してください。
要件: システム・レベル・バックアップをリカバリー・ベースとして使用するには、DFSMShsm が z/OS® 1.8 以上であることが必要です。
変更の始まり

ポイント・イン・タイムへの作業のバックアウト

RECOVER ユーティリティーでは、コミット済みの作業を バックアウトすることにより、データの現行状態からポイント・イン・タイムまでデータを リカバリーできます。バックアウトによってデータをリカバリーするには、RECOVER 制御ステートメント で BACKOUT YES を指定します。

場合によっては、 作業のバックアウトによるポイント・イン・タイムへのリカバリーのほうが、 データのコピーのリストアとログの順方向適応によるポイント・イン・タイムへのリカバリー よりも高速です。

RECOVER ユーティリティーがコミット済み作業のバックアウトによってポイント・イン・タイム・リカバリーを実行する場合は、データがリカバリーされるポイント・イン・タイムにおいてコミットされていなかったすべての作業もバックアウトされるため、そのリカバリーは、整合性を保ったポイント・イン・タイム・リカバリーです。リカバリー完了時、データはトランザクション整合状態の ままになります。

制約事項: 以下のポイント・イン・タイムへのバックアウト・リカバリーを実行することはできません。
  • リカバリーするオブジェクトの SYSIBM.SYSCOPY にある最新の SQL ALTER レコードのタイム・スタンプより前のポイント・イン・タイム。
  • 前回のバックアウト・リカバリーの完了時刻より前のポイント・イン・タイム。
  • 変更の始まりSYSCOPY レコードを挿入するユーティリティー (COPY や COPYTOCOPY でないユーティリティー) が実行される前のポイント・イン・タイム。変更の終わり
  • 変更の始まりLOG(YES) オプションを指定した REORG TABLESPACE が表スペースで実行される前のポイント・イン・タイム。変更の終わり

BACKOUT YES オプションを指定した RECOVERY ユーティリティーを実行する前に、リカバリーするオブジェクトを対象として、RECOVER オプションを指定した REPORT ユーティリティーを実行してください。 そうすることで、指定したポイント・イン・タイムまで作業をバックアウトすることによるオブジェクトのリカバリーについて、その実行の妨げとなるおそれのあるイベントを識別します。

変更の終わり

REORG でパーティションを再平衡化した後のリカバリーの 考慮事項

パーティション化表スペースの場合、限界キーの変更をマテリアライズする REORG ジョブよりも前に取ったイメージ・コピーは、現行 RBA または LRSN までのリカバリーに使用することができません。REORG ペンディングまたは勧告 REORG ペンディング状況が設定された後で、かつデータ・レコードを再配分する REORG が実行されるより前のポイント・イン・タイムへパーティション化表スペースをリカバリーすることは避けてください。適切なポイント・イン・タイムを判別するには、以下のことを行います。

  1. REPORT RECOVERY を実行する。
  2. リカバリー・ポイントが、データ・レコードを再配分した REORG より後の時点であるイメージ・コピーを選択する。

REORG ユーティリティーを実行して REORG ペンディング状況をオフにし、次に、その REORG ジョブより前のポイント・イン・タイムまでリカバリーするとします。この場合、DB2 は、その REORG ジョブに指定されたすべてのパーティションに、次のように限定状態を設定します。

  • データ・パーティションに対して、REORG ペンディング (および、場合によっては CHECK ペンディング) をオンに設定する。
  • 関連した索引パーティションに対して、再ビルド・ペンディングをオンに設定。
  • 非パーティション化副次索引の関連した論理パーティションに 対して、REBUILD ペンディングをオンに設定する。
新しい整合リカバリー・ポイントを作成するため、パーティション境界を変更する ALTER INDEX、ALTER TABLE、または REORG REBALANCE 操作の直後に、以下のいずれかのアクションを実行してください。
  • COPYDDN および SHRLEVEL NONE オプションを指定して REORG を実行する。
  • REORG の完了直後にフル・イメージ・コピーをとる。

パーティションの再平衡化の後にオフライン・コピーを使用してリカバリーする

データのリカバリーを、REORG ジョブがデータをパーティション間で再配分した後に実行するには、 RECOVER LOGONLY を使用します。 ポイント・イン・タイム・リカバリーを実行する場合は、オフライン・コピー を SYSCOPY レコードと同期させておく必要があります。 従って、MODIFY RECOVERY ユーティリティーを使用して、ICTYPE 列の値が 'A' のレコードを削除しないでください。 これらのレコードはリカバリー中に必要になるかもしれないためです。再平衡化を 実行した REORG より前に作成されたオフライン・コピーをもう使用する必要がない ことが確実な場合のみ、これらの SYSCOPY レコードを削除してください。

ポイント・イン・タイム・リカバリーに関する制約事項

ポイント・イン・タイム・リカバリーには、以下の制約事項が適用されます。
  • システム・レベルのバックアップは、BACKUP SYSTEM ユーティリティーによって行うことができます。ただし、リカバリー・ベースとして選択されたシステム・レベル・バックアップ以降に次のいずれかのユーティリティーが実行された場合、以前のポイント・イン・タイムへのオブジェクト・レベル・リカバリーにシステム・レベル・バックアップを使用することはできません。
    • REORG TABLESPACE
    • REORG INDEX
    • REBUILD INDEX
    • LOAD REPLACE
    • イメージ・コピーまたは並行コピーからの RECOVER

    z/OS V1R11.0 以降を 使用しており、カタログ情報を収集するように DFSMShsm をセットアップしてある 場合は、この制限は適用されません。

  • 索引が REBUILD ペンディング状態にある場合以外、その索引でポイント・イン・タイムまでの RECOVER を使用して REBUILD ペンディング状態をリセットすることはできません。関連付けられている表スペースがポイント・イン・タイムまでリカバリーされていて、関連するペンディングの定義変更がないためです。
  • クローン作成に現在関係しているオブジェクト、または、以前にクローン作成に関係したオブジェクト に対しては、最新の EXCHANGE ステートメントより前の時点までのポイント・イン・タイム・リカバリーを実行 することはできません。

リカバリー状況に影響を及ぼす可能性のあるアクション

表スペースを リカバリーする前に以下のアクションを行うと、リカバリー状況は次のような 影響を受けます。

  • 表を変更してパーティションを入れ替える場合 (ALTER TABLE ステートメントと ROTATE PARTITION 文節を使用):
    • パーティションを現在時刻までリカバリーできます。
    • パーティションを変更後のポイント・イン・タイムまでリカバリーできます。 ユーティリティーは、変更前に生じたリカバリー・ベース (例えば、 フル・イメージ・コピー、REORG LOG YES 操作、または LOAD REPLACE LOG YES 操作) を使用 できます。
    • パーティションを変更前のポイント・イン・タイムまでリカバリーすることはできません。 リカバリーは MSGDSNU556I および RC8 で失敗します。
  • パーティション境界を変更する場合 (ALTER TABLE ステートメントと ALTER PARTITION 文節を使用するか、REORG REBALANCE ユーティリティー制御ステートメントを使用):
    • リカバリー・ベース (例えば、フル・イメージ・コピー、REORG LOG YES 操作、 または LOAD REPLACE LOG YES 操作) が存在する場合は、パーティションを現在時刻まで リカバリーできます。
    • パーティションを、変更後のポイント・イン・タイムまでリカバリーできます。
    • 変更の始まり境界変更によって影響を受けたパーティションを、変更前のポイント・イン・タイムまでリカバリーできます。しかし、変更された境界は、前の境界に戻りません。RECOVER は、影響を受けたパーティションを REORG ペンディング状況に設定するため、その表スペースまたは各パーティションすべてを再編成する必要があります。影響を受けた各パーティションはすべて、1 つの RECOVER ステートメントのリカバリー・リストに 入っている必要があります。変更の終わり
  • 表を変更してパーティションを追加する場合 (ALTER TABLE ステートメントと ADD PARITION 文節を使用):
    • パーティションを現在時刻までリカバリーできます。
    • パーティションを変更後のポイント・イン・タイムまでリカバリーできます。
    • パーティションを変更前のポイント・イン・タイムまでリカバリーでき ます。RECOVER はパーティションを空にリセットします。
  • 変更の始まり列を追加する場合 (ALTER TABLE ステートメントと ADD COLUMN 文節を使用)、表を変更して列を追加する時点から以下のいずれかのアクションを行う時点までの間のポイント・イン・タイムまで表スペースをリカバリーすることはできません。
    • デフォルト値のドロップ (ALTER TABLE ステートメントと、DROP DEFAULT を指定する ALTER COLUMN 文節を使用)
    • デフォルト値の変更 (ALTER TABLE ステートメントと、SET DEFAULT を指定する ALTER COLUMN 文節を使用)
    変更の終わり
  • 変更の始まり複数の XML バージョンをサポートするように表を変換する場合 (REORG TABLESPACE ユーティリティー制御ステートメントを使用):
    • 関連付けられている表スペースを表が変換される前のポイント・イン・タイムまでリカバリーすることはできません。
    • その表の索引を表が変換される前のポイント・イン・タイムまでリカバリーすることはできません。
    変更の終わり
  • 変更の始まり表スペースの編成をハッシュ編成に変更する場合 (ALTER TABLE ステートメントと ALTER ORGANIZATION 文節を使用):
    • 表スペースを現在時刻までリカバリーできます。
    • 表スペースを変更前または変更後のポイント・イン・タイムまでリカバリーできます。
    • ハッシュ編成をマテリアライズした REORG の前または後のポイント・イン・タイム まで表スペースをリカバリーできます。REORG より前のポイントまで表スペースを リカバリーした場合、RECOVER ではその表スペースを AREOR 状況にします。
    変更の終わり
  • 変更の始まり表スペースのハッシュ・スペースのサイズを変更する場合 (ALTER TABLE ステートメントと ALTER ORGANIZATION 文節を使用):
    • 表スペースを現在時刻までリカバリーできます。
    • 表スペースを変更前または変更後のポイント・イン・タイムまでリカバリーできます。
    • ハッシュ・スペース・サイズの変更をマテリアライズした REORG の前または後の ポイント・イン・タイムまで表スペースをリカバリーできます。
    変更の終わり
  • 変更の始まりハッシュ編成をドロップする場合 (ALTER TABLE ステートメントと DROP ORGANIZATION 文節を使用):
    • 表スペースを現在時刻までリカバリーできます。
    • 表スペースを変更後のポイント・イン・タイムまでリカバリーできます。
    • 表スペースを変更前のポイント・イン・タイムまでリカバリーすることはできません。
    変更の終わり
  • 変更の始まりペンディングの定義変更を実行した場合、それらの変更をマテリアライズするかドロップして (ALTER TABLESPACE ステートメントと DROP PENDING CHANGES 文節を使用) からでないと、ポイント・イン・タイム・リカバリーを実行できません。
    例: 以下の特性を変更すると、ペンディングの定義変更が実行されます。 変更の始まり
    • セグメント・サイズ (ALTER TABLESPACE ステートメントと SEGSIZE 文節を使用)
    • データ・セット・サイズ (ALTER TABLESPACE ステートメントと SEGSIZE 文節を使用)
    • バッファー・プールのページ・サイズ (ALTER TABLESPACE ステートメントと BUFFERPOOL 文節を使用)
    • MEMBER CLUSTER 属性 (ALTER TABLESPACE ステートメントと MEMBER CLUSTER 文節を使用)
    • 表スペース・タイプ (ALTER TABLESPACE ステートメントを使用)
    変更の終わり
    変更の終わり
  • 変更の始まりセグメント化表スペースまたはユニバーサル表スペース内の表に対して以下のいずれかの SQL 操作を実行した場合、それらの変更は (RECOVER ユーティリティー制御ステートメントと BACKOUT YES 文節を使用して) バックアウトできません。
    • WHERE 文節のない DELETE (一括 DELETE)
    • TRUNCATE TABLE
    • DROP TABLE
    • ROTATE PARTITION 文節を指定した ALTER TABLE

    索引または補助オブジェクトがある基本表スペース (LOB 表スペースまたは XML 表スペース) 内の表に対して前述のいずれかのアクションを実行する場合、この制限はそれらの索引または補助オブジェクトにも適用されます。

    変更の終わり
索引を前のポイント・イン・タイムまたは現在のポイント・イン・タイムまでリカバリーする前に 以下のアクションを行うと、リカバリー状況は、下記のような影響を受けます。
  • 列のデータ・タイプを数値データ・タイプに変更した場合 (ALTER TABLE ステートメントと、新規データ・タイプを指定する ALTER COLUMN 文節を使用)、索引のフル・イメージ・コピーを作成するまで索引をリカバリーできません。 ただし、索引の再作成はできます。
  • 索引を NOT PADDED または PADDED に変更した場合 (ALTER INDEX ステートメントと NOT PADDED または PADDED 文節を使用)、索引のフル・イメージ・コピーを作成するまで索引をリカバリーできません。 ただし、索引の再作成はできます。
  • 索引を再生成する場合 (ALTER INDEX ステートメントと REGENERATE 文節を使用)、再生成された時点より前のポイント・イン・タイムまで索引または索引スペースをリカバリーすることはできません。 代わりに、REBUILD INDEX ユーティリティーを 使用して索引を再作成します。
  • DB2 が新しいバージョンの索引を作成するなど、索引を変更する場合には、新しいバージョンの索引を作成した最初の ALTER INDEX ステートメントより前のポイント・イン・タイムまで索引をリカバリーすることはできません。

ポイント・イン・タイム・リカバリーの計画

整合ポイント (QUIESCE または SHRLEVEL REFERENCE 設定) である ポイント・イン・タイムまでのリカバリーは、バックアウトするべきコミットされていない作業がないため、 望ましいリカバリーです。

単一オブジェクトのコピーを作成するときには、 TOCOPY、TOLASTCOPY、または TOLASTFULLCOPY リカバリーのための整合ポイントを設定するため、SHRLEVEL REFERENCE を使用してください。 SHRLEVEL CHANGE を用いて作成されるコピーは、コピーが行われている間に変更が生じる可能性が あるため、単一インスタントではデータをコピーしません。後で RECOVER TOCOPY 操作を実行すると、 データの整合性が失われる可能性があります。 代わりに、TOLOGPOINT オプションを指定した RECOVER を使用して SHRLEVEL CHANGE コピーの後 のポイント、およびバックアウトされるコミットされていない作業単位を指定してください。

オブジェクトのリストのコピー時には、SHRLEVEL REFERENCE を使用します。 後でポイント・イン・タイム・リカバリーが必要な場合は、共通の RBA または LRSN 値を示す TOLOGPOINT と 共に、単一の RECOVER ユーティリティー・ステートメントを使用して、すべてのオブジェクトをリストすることができます。 SHRLEVEL CHANGE を使用してオブジェクトのリストをコピーする場合は、 その直後にオブジェクトの QUIESCE を実行する必要があります。

リカバリーのパフォーマンスを改善するには、表スペースまたは表スペース・セットの フル・イメージ・コピーをとり、その後、QUIESCE ユーティリティーを使用して それらを静止します。このアクションによって、RECOVER TORBA または TOLOGPOINT は、ログの利用を最小限に抑えて、表スペースを 静止ポイントまでリカバリーすることができます。

許可: ポイント・イン・タイム・リカバリー・オプションの使用は、 DB2 リカバリー環境について精通している 人のみに限定してください。

整合性の確保

RECOVER TORBA、 RECOVER TOLOGPOINT、および RECOVER TOCOPY を使用して、以下のいずれかの単一オブジェクトを リカバリーできます。

  • パーティション化表スペースの単一のパーティション
  • パーティション索引スペースの単一のパーティション
  • SIMPLE 表スペースの単一のデータ・セット

上記のオブジェクトについてはいずれも、すべてのデータ・セットを同一レベルに リストアしてください。そのようにしないと、データは不整合になります。

可能であれば、 表スペースとその索引のすべて (または、表スペース・セットと その関連するすべての索引) を同じ RECOVER ユーティリティー・ステートメントで指定 し、さらに TOLOGPOINT または TORBA を指定して QUIESCE ポイント を指定してください。このアクションは、 索引が CHECK ペンディングまたは REBUILD ペンディング状況にされるのを回避します。TOLOGPOINT がすべてのオブジェクトに共通の QUIESCE ポイントではない場合は、 以下の手順に従ってください。

  1. 表スペースを TOLOGPOINT の値 (RBA または LRSN のいずれか) までリカバリーします。
  2. 並行 REBUILD INDEX ジョブを使用して、それぞれの表スペースの索引をリカバリーします。

この手順によって、表スペースと索引が確実に同期化され、CHECK INDEX ユーティリティーを実行する 必要がなくなります。

TOLOGPOINT または TORBA を指定して QUIESCE ポイントを示すことができない場合は、任意のポイント・イン・タイムを指定でき、DB2 は データを整合状態に保ちます。TORBA または TOLOGPOINT が指定されている場合、RECOVER ユーティリティーは、コミットされていない作業単位 を自動的に処理し、データは整合した状態に保たれます。

TORBA または TOLOGPOINT オプション を指定して RECOVER を使用する場合、リカバリー・ポイントでアクティブなリカバリー単位によって 変更されるすべてのオブジェクトが同じポイント・イン・タイムまでリカバリーされて、すべて同期化されるように してください。

  • DB2 は、 リカバリー・ポイント・イン・タイム中に未完了 (inflight)、アボート中 (inabort)、延期アボート (postponed abort)、 またはインダウト (indoubt) であるリカバリー単位に対する変更をロールバックします。
  • DB2 は、 リカバリー・ポイント・イン・タイム中に INCOMMIT であるリカバリー単位に対する 変更をロールバックしません。
  • DB2 は、 RECOVER ステートメント内のオブジェクトに対する変更のみをロールバックします。

CHECK ペンディング状況の回避

DB2 は、以下のポイント・イン・タイム・リカバリー状態で CHECK ペンディング状況を設定します。

  • 以前のポイント・イン・タイムに設定された表スペースのメンバーを少なくとも 1 つリカバリーするが、同じ静止ポイントに設定された表スペースのすべてのメンバーをリカバリーするわけではない。この場合、リカバリーされるすべての従属表スペースが、 表スペース全体の範囲についてチェック・ペンディング状況になります。リカバリーされる表スペースのすべての従属表スペースが、特定の従属表の有効範囲で CHECK ペンディング状況になります。
  • RECOVER ステートメントが TORBA オプションまたは TOLOGPOINT オプションを含んでおり、表スペース・セットのすべてのメンバーを同じポイント・イン・タイムまでリカバリーする。ただし、参照制約は、そのポイント・イン・タイムの後に、それらの表スペースの 1 つで定義された。この場合、参照制約のある表が含まれている表スペースに対して CHECK ペンディング 状況が設定されます。
  • RECOVER ステートメントが TORBA オプションまたは TOLOGPOINT オプションを含んでおり、1 つ以上の索引を前のポイント・イン・タイムまでリカバリーする。ただし、同じ RECOVER ステートメントが、関連する表スペースをリカバリーしない。この場合、DB2 は索引の CHECK ペンディング状況を設定します。
  • 変更の始まりDB2 10 変換モードで、RECOVER ステートメントが TORBA オプションまたは TOLOGPOINT オプションを含んでおり、定義されている LOB 列または XML 列がある表スペースを、それらの LOB 表スペースや XML 表スペースをリカバリーせずにリカバリーする。DB2 10 新機能モードでは、基本表スペースおよびそれらに関連付けられた LOB または XML 表スペースは、一緒にリカバリーする必要があります。変更の終わり

RECOVER が、通知参照制約によって関連している従属表スペースを CHECK ペンディング状況にすることはありません。

CHECK ペンディング状況の設定を回避するには、以下のアクションを実行します。

  • 参照制約に関与する表をリカバリーするときは、その制約に関与するすべての表スペースをリカバリーします。
  • すべての従属オブジェクトを同じポイント・イン・タイムまでリカバリーします。
  • リカバリーに使用する予定のポイント・イン・タイムの後に、表チェック制約または参照制約を追加しないでください。
  • 索引と、関連する表スペースを同じポイント・イン・タイム (できれば、静止ポイント) またはCOPY SHRLEVEL REFERENCE ポイントまでリカバリーします。RECOVER 処理は、同じ RECOVER ステートメントのすべての索引について、CHECK ペンディング状況をリセット します。
関連情報:

圧縮されたデータ

表スペースまたはパーティションの一部 (例えば、1 つのデータ・セット) を以前のポイント・イン・タイムまでリカバリー する際には注意が必要です。リカバリー中のデータ・セットが別のディクショナリーで圧縮された場合、 そのデータは読み取ることができなくなります。