ロールフォワード回復では、 BACKUP コマンドとともに RESTORE コマンドおよび ROLLFORWARD コマンドを使用します。 ロールフォワード回復を実行すると、 データベースまたは表スペースは指定された時点における元の状態に回復されます。
データベースを初めて作成した時点では、循環ロギングだけが使用可能になります。 つまり、ログは再使用され (循環方式で)、保管も保存もされません。 循環ロギングでは、ロールフォワード回復は不可能です。 破損回復またはバージョン回復だけが使用可能です。 しかし、ログ保存を実行するときは、ロールフォワード回復を実行できます。 これは、バックアップ作成後に、ログがデータベースに対する変更を記録するからです。 logretain データベース構成パラメーターを "RECOVERY" に設定したり、 または userexit データベース構成パラメーターを使用可能にしたり、 あるいはこの両方を実行することによって、ログ・アーカイブを実行します。 これらのパラメーターのどちらかが上記の説明のとおりに構成されていると、 データベースはロールフォワード回復 について使用可能になります。
データベースが回復可能であるときは、 データベースと表スペースの両方のレベルでバックアップ、回復、 およびロールフォワード回復を実行できます。 データベースと表スペースのバックアップは、オンラインで行えます。 オンライン復元とロールフォワードは、表スペース・レベルでも行えます。
ロールフォワード回復では、ログに記録された完了作業単位を、 復元されたデータベース、表スペース、または複数の表スペースに再適用します。 ロールフォワード回復をログの最後まで実行するか、 あるいは特定の時点まで実行するかを指定できます。
データベースの復元で説明したように、 ロールフォワード回復はデータベース全体を復元した後に実行できます。 ロールフォワード操作保留状態の表スペースにも実行できます。 表スペースのロールフォワードの考慮事項については、 表スペースにおける変更のロールフォワードを参照してください。
ロギングに関連するデータベース構成パラメーターの詳細な説明については、 データベース・ロギングの構成パラメーターを参照してください。
データベースで順方向回復を行えるようになったときに適用される、 バックアップについての考慮事項を以下に示します。 バックアップの実行に適用される一般的な情報については、以下を参照してください。
新しいデータベースがロールフォワード回復を実行できるようにするためには、 少なくとも 1 つの構成パラメーターを使用可能にした後、 データベースの最初のバックアップをとるようにしてください。 片方または両方のパラメーターの値を変更すると、 データベースはバックアップ保留 状態になり、 その結果、データベースのオフライン・バックアップを作成しなければならなくなります。 バックアップ操作が正常に完了すると、データベースは使用可能になります。
OS/2 では、ディスケットまたはユーザー出口にバックアップをとることもできます。
OS/2 では、ユーザー出口から復元を実行してデータベースをロールフォワードするときは、 データベースへのパスだけが、コンテナーを探すために使用する唯一の参照パスとなります。 そのため、バックアップ・テープ上のそのデータベースのすべてのコンテナーが復元されます。
BACKUP コマンドの TABLESPACE オプションを使用して、 データベースの一部にバックアップを実行し、後で回復することも可能です。 この方法は、データ、索引、および長形式フィールド / ラージ・オブジェクト (LOB) を別々の表スペースで管理する場合に役立ちます。
順方向回復を使用できるようにしたい場合は、 定期的にノード・リストについてデータベースのバックアップをとる必要があり、 また、システム内の残りのノードのバックアップも少なくとも 1 つは作成する必要があります (該当するデータベースに関するユーザー・データを含んでいない場合でも)。 データベースに関するユーザー・データを含んでいないデータベース区画サーバーで、 データベース区画のバックアップ・イメージが必要となるのは、次の 2 つの場合です。
データベース全体または表スペースをバックアップまたは復元すると、 回復活動記録ファイルが要約情報によって自動的に更新されます。 このファイルは、データベース内の復元のアクティビティーを記録する機能として便利です。 このファイルは、データベース構成ファイルと同じディレクトリーに作成されます。 回復活動記録ファイルについては、回復活動記録ファイルの情報を参照してください。
UNIX ベースの環境では、ディスクに作成されるファイル名は、 以下の情報をピリオドで区切って連結したもので構成されます。 他のプラットフォームでは、4 レベルから構成されるサブディレクトリー・ツリーが使用されます。
データベースで順方向回復を行えるようになったときに適用される、 復元についての考慮事項を以下に示します。 復元の実行に適用される一般的な情報については、以下を参照してください。
以下のことを考慮しなければなりません。
TSM を使用して TAKEN AT パラメーターを指定しない場合、 TSM は最新のバックアップ・コピーを検出します。
OS/2 では、データベースまたは表スペースのバックアップ・コピーは、 ディスケットに保管させることもでき、 またユーザー出口から書き込み先を指定することもできます。
Windows 95 および Windows NT では、 データベースまたは表スペースのバックアップ・コピーをディスケットに保管させることもできます。
ROLLFORWARD コマンドを出すと、次のようになります。
注: | 最後に実行したバックアップの後で表スペースの名前を変更した場合、 その表スペースをロールフォワードする際には、 必ず新しい名前を使用してください。 以前の表スペースの名前は認識されません。 |
ロールフォワード処理の実行中に、別のデータベース RESTORE を実行することはできません。
注:
区分データベース・システムでは、 ログの最後まで表スペース (または複数の表スペース) をロールフォワードする場合は、 各データベース区画 (ノード) で復元する必要はありません。 回復が必要なデータベース区画でだけ復元すれば十分です。 特定の時点までの表スペースのロールフォワードを実行したい場合は、 ロールフォワードを実行する前に、 表スペースを各データベース区画で復元する必要があります。
ロールフォワード回復は復元されたデータベースを基に実行されるため、 データベース・バックアップが作成された後の特定の時点までデータベースを復元することができます。 この時点はログの最後か、 データベース・バックアップ作成時とログの最後までの間の任意の時点です。
注: | 全ログの末尾まで復元およびロールフォワードを実行する場合、 LIST HISTORY コマンドの後に示されるバックアップ ID は、最終時刻を表します。 つまり、バックアップ ID 値は 99991231235959 です。 ロールフォワードを実行する場合、 バックアップ ID の変換方法はこれだけです。 |
活動またはアーカイブ・ログが使用できない場合は、特定の時点の回復を使用できます。 この場合は、ログが失われた時点までロールフォワード可能です。 データベースに対しエラーが含まれたトランザクションが実行された場合も、 特定の時点までロールフォワード可能です。 この場合は、データベースを復元した後、 エラーが含まれたトランザクションの実行直前までロールフォワードします。
![]() |
表スペースについて特定時点のロールフォワード回復を実行することもできます。 詳細については、表スペースにおける変更のロールフォワードを参照してください。
この方式を使用するには、 ロールフォワード回復を使用可能にするようデータベースを構成する必要があります。 次の部分では、 データベース構成ファイルとデータベース・ログについての考慮事項を扱います。
DATALINK 列を含む表がある場合、 データベースおよび表スペースを復元してからログの終わりまでロールフォワードするおよび データベースおよび表スペースを復元してからある時点までロールフォワードするも参照してください。
データベース構成ファイルには、 ロールフォワード回復に関連するパラメーターが含まれています。 省略時パラメーターではこの回復がサポートされていないので、 この方法を使用する予定の場合は、それらの省略時値をいくつか変更する必要があります。 DB2 UDB の構成についての詳細は、 第 32 章, DB2 の構成を参照してください。
空の場合でもいっぱいの場合でも、1 次ログには同じ容量のディスク・スペースが必要です。 それで、必要以上に多数のログを構成すると、 不必要にディスク・スペースを使用することになります。 構成するログ数が少なすぎると、ログ満杯条件になる可能性があります。 構成するログの個数を選択する際は、それぞれのログのサイズと、 アプリケーションでログ満杯条件を処理できるかどうかを考慮する必要があります。
既存データベースでロールフォワード回復を使用可能にしている場合は、1 次ログの数を、 1 次ログと 2 次ログの合計数に 1 を足した数に変更する必要があります。 ロールフォワード回復が可能になっているデータベースでは、 long varchar フィールドと LOB フィールドについて追加情報がログに記録されます。
ログ・ファイルの合計サイズの限界は、32 GB です。 つまり、ログ・ファイルの数 (LOGPRIMARY + LOGSECOND) に、 各ログ・ファイルのサイズ (バイト単位) (LOGFILSIZ * 4096) を掛けた値が、 32 GB より小さくなければなりません。
この構成パラメーターの詳細は、第 32 章, DB2 の構成を参照してください。
1 次ログ・ファイルがいっぱいになると、 logfilsiz で指定されたサイズの 2 次ログ・ファイルが必要に応じて 1 度に 1 つずつ割り振られます。 このパラメーターは、その最大数を制御します。 このパラメーターで指定した数より多くの 2 次ログ・ファイルが必要になると、 エラー・コードがアプリケーションに戻され、 データベースに対する活動は停止されます。
この構成パラメーターの詳細は、第 32 章, DB2 の構成を参照してください。
注: | ログ・ファイルの合計サイズの限界は、32 GB です (つまり、 (logfilsiz + logprimary) x logfilsiz < 32 GB/4096)。 |
各 1 次ログのサイズは、パフォーマンスに直接影響します。 データベースの構成がログを保持するようになっている場合は、ログが満杯になるたびに、 新規ログの割り振りと初期化を求める要求が出されます。 ログのサイズを大きくすると、 新規ログの割り振りと初期化に必要な要求の回数は少なくなります。 (ただし、ログ・サイズを大きくすれば、 新規ログの形式化処理にかかる時間が長くなります。) 新規ログの形式化処理はデータベースに接続しているアプリケーションにとって透過的なので、 形式化処理はデータベースのパフォーマンスに影響しません。
データベースをオープンするための処理時間を最小限にするためにデータベースをオープンしたままにするアプリケーションを使用している (回復のパフォーマンスに関する考慮事項参照) 場合、 ログ・サイズの値はオフライン・アーカイブ・ログのコピーの作成にかかる時間によって決める必要があります。
オフライン・アーカイブ・ログを保管するのに使用している装置のデータ転送速度、 およびコピー作成に使用しているソフトウェアのデータ転送速度は、 データベース・マネージャーがログに書き込むときの平均速度以上であることが必要です。 転送速度が新規ログ・データの生成速度に追いつかない場合、 ディスク・スペースの空き容量によっては、 ロギング・アクティビティーがかなり長い時間続行されると、 ディスク・スペースを使い切ってしまうおそれがあります。 そうなると、データベース処理が停止してしまいます。
テープ装置または光媒体を使用している場合には、データ転送速度が最重要になります。 (ログを保管するために異なる媒体を使用する場合については、 付録 F, データベース回復用のユーザー出口を参照してください。) テープ装置の中には、ファイルのコピーに、 サイズに関係なく同じ長さの時間がかかるものがあります。 保存装置の能力について調べておく必要があります。
テープ装置には、このほかにも特有の考慮事項がいくつかあります。 保存要求の頻度も重要です。 コピー操作時間が 5 分間であるとすると、ログのサイズは、 作業負荷がピークの時の 5 分間分のログ・データを保持できるだけの十分な大きさになっている必要があります。 またテープ装置には、1 日あたりの操作回数に設計上の限界がある場合もあります。 ログ・サイズを決定するときは、これらの要素を考慮するようにしてください。
ログ・ファイルの損失を最小限にくい止めることも、 ログ・サイズを設定する際の重要な考慮事項の 1 つです。 保存には、ログ全体が必要です。 単一の大きなログを使用する場合は、保存の間隔を長くしてください。 ログが入っている媒体で障害が発生した場合は、 トランザクション情報がいくらか失われる可能性があります。 ログ・サイズを小さくすれば、保存の頻度は高くなりますが、 小さいログを使うため、媒体障害が発生しても失う情報量が少なくなります。
ログ・レコードのバッファリング機能によって、ディスクに書き込む頻度が少なくなり、 1 度に書き込まれるログ・レコードの数が多くなるので、 ロギング・ファイルの入出力がさらに効率的になります。
このコミットのグループ化が行われるのは、このパラメーターの値が 1 より大きく、 データベースに接続されているアプリケーションの数がこのパラメーターの値より大きい場合だけです。 コミットのグループ化が実行中である場合、 アプリケーションのコミット要求は、1 秒経過するか、 またはコミット要求回数がこのパラメーター値に達するまで保留されます。
ログ・パス・ディレクトリーは変更可能なので、ロールフォワード回復に必要なログが別のディレクトリーや別の装置に存在している可能性があります。 ロールフォワード操作中に、この構成パラメーターを変更して、 複数の位置のログにアクセスできます。
newlogpath の値への変更は、 データベースが一貫した状態になるまで適用されません。 参照用のデータベース構成パラメーター database_consistent はデータベースの状況を示しています。 この構成パラメーターの詳細は、第 32 章, DB2 の構成を参照してください。 データベースが一貫した状態になっていない場合にデータベース・ログが果たす役割については、 ログ・ファイル管理についての考慮事項を参照してください。
このパラメーターを使うと、省略時の循環ロギングを上書きすることになります。
このパラメーターを使うと、省略時の循環ロギングを上書きすることになります。 userexit は logretain を暗黙指定しますが、 その逆の暗黙指定はありません。
ユーザー出口プログラムについては、付録 F, データベース回復用のユーザー出口を参照してください。
userexit 構成パラメーターか logretain 構成パラメーターのどちらかを使用してロールフォワード回復を行うときに、アクティブ・ログ・パスが重要です。 userexit 構成パラメーターが使用可能になっていると、 アクティブ・ログ・パスから離れたログ・ファイルを保存するためにユーザー出口が呼び出されます。 logretain 構成パラメーターが "RECOVERY" に設定されていると、 ログ・ファイルがアクティブ・ログ・パスに残るようにします。 アクティブ・ログ・パスは、「Path to Log Files」か「Changed Path to Log Files」(newlogpath) のどちらかによって決まります。
データベースが順方向回復であれば、データベース全体を使用する代わりに、 表スペースをバックアップしたり、復元したり、ロールフォワードしたりできます。 個別の表スペースについて回復方針を決めておくこともでき、 これにより時間が節約されます。 つまり、データベース全体を回復するよりは、 データベースの一部を回復した方が時間は短縮されるからです。 たとえば、ディスクが不良で、そのディスクに表スペースが 1 つだけ含まれている場合は、 データベース全体を回復しなくても (したがって、 データベースの残りの部分に対するユーザー・アクセスに影響を与えずに)、 当該表スペースだけを復元しロールフォワードできます。 また、表スペース・レベルのバックアップを用意しておけば、 データベースの重要な部分を他の部分より頻繁にバックアップすることが可能になり、 これによりデータベース全体のバックアップより時間は短縮されます。
最後に実行したバックアップの後で表スペースの名前を変更した場合、 その表スペースをロールフォワードする際には、 必ず新しい名前を使用してください。 以前の表スペースの名前は認識されません。 また、 最低でもその表スペースの名前を変更した時点までロールフォワードを行わなければなりません。
区分データベース環境で、一部のデータベース区画がロールフォワード保留状態で、 他のデータベース区画では、一部の表スペース (データベース区画ではない) がロールフォワード保留状態の場合は、 まず、データベース区画をロールフォワードし、 次に表スペースをロールフォワードします。
表のデータおよび長形式オブジェクトが別々の表スペースに存在する場合に、 その表が再編成された場合は、 データと長形式のオブジェクトのための表スペースは同時に復元し、 ロールフォワードする必要があります。 表再編成後に、関係する表スペースのバックアップを作成する必要があります。
現在の状況を示すために、様々な状態が表スペースに関連付けられています。
バックアップ・イメージをオンラインで作成した場合、 またはロールフォワード操作が完了しなかった場合、 表スペースも ロールフォワード進行 状態になります。
表スペースは復元されると、常にロールフォワード保留状態になります (つまり、 表スペースを復元して WITHOUT ROLLING FORWARD パラメーターを指定すると、 WITHOUT ROLLING FORWARD は無視されます)。 表スペースを使用可能にするためには、 表スペースにロールフォワード回復を実行する必要があります。 ログの最後までロールフォワードすることもでき、 特定の時点までロールフォワードすることもできます。 特定の時点まで表スペースをロールフォワードしたい場合は、次の点に注意してください。
注: | バックアップ・イメージがオンラインで取られた場合は、 これを行うことはできません。 この場合、少なくともバックアップの最後までロールフォワードする必要があります。 |
両方の表スペースを同じ時点までロールフォワードする必要があります。 そのようにしない場合は、検査保留 状態で、 要約表がロールフォワード操作の最後に置かれます。
この状態が発生しないような停止時間を見つける必要があります。
データベースの 表スペース TABSP1 を データベース バックアップ T2 へロールフォワード の復元。 する時刻。 ログの最後まで TABSP1 のバックアップ。 ロールフォワード。 T1 T2 T3 T4 | | | | | | | | |--------------------------------------------------------------------------- | TABSP1 を T2 へ ロールフォワードする とき、T2 と T3 の 間ではログは 適用されない。 |
上記の例では、データベースを時刻 T1 でバックアップします。 次に、時刻 T3 で、表スペース TABSP1 を特定の時刻 T2 へロールフォワードし、 T3 後に表スペースのバックアップを作成します。 (表スペースはバックアップ保留状態であるため、 そのバックアップを作成する必要があります。 表スペース・バックアップのタイム・スタンプは T3 より後の時間になりますが、 表スペースは時刻 T2 です。 T2 と T3 の間では、ログ・レコードは TABSP1 には適用されません。) 時刻 T4 では、T1 で作成したバックアップを使用してデータベースを復元し、 ログの最後までロールフォワードします。 表スペース TABSP1 は、時刻 T3 になると復元保留状態になります。
表スペースは、T3 で復元保留状態になります。 これは、TABSP1 に対し T3 と T4 の間では T2 と T3 の間のログ変更項目を表スペースに適用しないで操作が行われたものとデータベース・マネージャーが想定するからです。 T2 と T3 間のログ変更項目が ROLLFORWARD の一部としてデータベースに再適用されたとすると、 この想定は間違っていることになります。 表スペースを特定の時点までロールフォワードした後に作成しなければならない表スペースの必須バックアップを用意することで、 以前の特定時点のロールフォワードの時刻が経過した後でも、その表スペースをロールフォワードできます (例の T3)。
表スペース TABSP1 を T4 まで回復したい場合は、 T3 後に作成したバックアップ (必須バックアップまたはそれ以後のバックアップ) から表スペースを復元し、ログの最後まで TABSP1 をロールフォワードします。
上記の例では、時刻 T4 までデータベースを復元する最も効果的な方法は、 必須ステップを以下の順序で実行する方法です。
データベースをロールフォワードする前に表スペースを復元するため、資源は、 データベース・ロールフォワード時には表スペースへのログ・レコードの適用には使用されません。 この状態は、表スペースを復元する前にデータベースをロールフォワードすると発生します。
時刻 T3 より後の時間の TABSP1 のバックアップ・イメージが見つからないか、 TABSP1 を T3 またはそれより前に復元したい場合は、次の操作を実行できます。
区分データベース環境では、 表スペースのすべての部分を同時に同じ時点までロールフォワードする必要があります。 これにより、表スペースはそれぞれのデータベース区画で整合性が保証されます。
ROLLFORWARD コマンドを使う前に、以下の項目を考慮する必要があります。
ログの最後までの順方向回復を実行すると、 QUERY STATUS により戻される特定の時刻が予想より早い時刻の場合、 ログ・ファイル (または複数のファイル) が見つからない旨のメッセージが、 QUERY STATUS により示されることがあります。
特定の時刻までの順方向回復を実行すると、 ロールフォワードが正しい時点まで実行されることが QUERY STATUS により確認できます。
![]() |
データベースに ROLLFORWARD CANCEL を使用すると、 ロールフォワードがデータベースに対し進行中の場合もそうでない場合も、 データベースは復元保留状態になります。
表スペースに関する ROLLFORWARD CANCEL 動作は次のとおりです。
注: | 表スペース・リストが指定されていない場合は、SQL4906 が出されます。 |
注: | 実行中のロールフォワード操作を取り消すために、 ROLLFORWARD CANCEL を使用することはできません。 これは、ROLLFORWARD STOP が出されていない完了したロールフォワード操作を取り消すため、 または完了する前に失敗したロールフォワード操作について使用することができます。 |
DATALINK 列を含む表がある場合、復元およびロールフォワードについての考慮事項も参照してください。
バージョン 2 クライアントからは、 区分データベースをロールフォワードすることはできません。
ROLLFORWARD コマンドを呼び出す場合は、その前に以下の点を考慮してください。
注:
DB2LOADREC レジストリー変数を使って、ロード・コピー所在情報のあるファイルを識別します。 ロールフォワード回復時にこのファイルを使って、ロード・コピーを探します。 次の情報が含まれています。
ロケーション・ファイルがないか、または対応する項目がこの項目にない場合は、 ログ・レコード中の情報が使われます。
ロールフォワード回復が実行される前に、ファイル内の情報が上書きされることがあります。
注:
次の情報がロケーション・ファイル内にあります。 最初の 5 つのパラメーターには有効値がなければならず、 これを使用してロード・コピーを識別します。 ロード・コピーが記録されるたびに、この構造全体が繰り返し使われます。 たとえば、次のようなものがあります。
TIMestamp 19950725182542 * ロード時に生成されたタイム・スタンプ SCHema PAYROLL * ロードされた表のスキーマ TABlename EMPLOYEES * 表名 DATabasename DBT * データベース名 DB2instance TORONTO * DB2INSTANCE BUFfernumber NULL * 回復に使用したバッファーの数 SESsionnumber NULL * 回復に使用したセッションの数 TYPeofmedia L * 媒体のタイプ - L はローカル装置 A は TSM O はその他のベンダー LOCationnumber 3 * ロケーションの数 ENTry /u/toronto/dbt.payroll.employes.001 ENT /u/toronto/dbt.payroll.employes.002 ENT /dev/rmt0 TIM 19950725192054 SCH PAYROLL TAB DEPT DAT DBT DB2 TORONTO SES NULL BUF NULL TYP A TIM 19940325192054 SCH PAYROLL TAB DEPT DAT DBT DB2 TORONTO SES NULL BUF NULL TYP O SHRlib /@sys/lib/backup_vendor.a
注:
注: | LOAD COPY NO を実行する場合に、 LOAD 実行後にデータベースまたは関係する表スペースのバックアップ・コピーを作成しておかないと、 データベースまたは表スペースを LOAD 実行後の特定の時点まで復元することはできません。 つまり、ロールフォワード回復を使用してデータベースまたは表スペースを LOAD 後の状態まで再作成することはできません。 LOAD が実行される前の特定の時点までしか、 データベースまたは表スペースを復元することはできません。 |
特定のロード・コピーの使用を希望すると、 LOAD タイム・スタンプはデータベースの回復活動記録ファイルに記録されます。 区分データベース環境では、 回復環境変数は各データベース区画でローカルなものでなければなりません。
LOAD についての詳細は、データ移動ユーティリティー 手引きおよび解説書 を参照してください。
まだ必要な表を誤って除去してしまう場合があるかもしれません。 データを決して失ってはならない表がある場合には、 除去しても表を回復可能にしておくことを考慮してください。
表のデータは、データベースの RESTORE、 次いでデータベースのロールフォワードを行うことにより回復できます。 データベースが大きいと時間がかかり、その回復のあいだにはデータは使用できなくなります。 除去された表の回復を利用すると、 表スペース・レベルの回復およびロールフォワードを使用して、 除去された表のデータを回復することができます。 したがって、これはデータベース・レベルの回復にかかる時間より短く、 ご使用のデータベースを、ユーザーが使用可能な状態に保つことができます。
除去された表が回復可能になるには、 表が常駐する表スペースで DROPPED TABLE RECOVERY オプションがオンになっていなければなりません。 これは、ALTER TABLESPACE ステートメントを使用するか、 または CREATE TABLESPACE ステートメントの実行中にできます。 これらのステートメントについての詳細は、SQL 解説書 を参照してください。
DROPPED TABLE RECOVERY オプションは表スペースに固有で、 正規表スペースに指定することしかできません。 表スペースにこの特性があるかどうかを判別するには、 syscat.tablespaces カタログ表にある表スペース名の DROP_RECOVERY 列を照会できます。
DROPPED TABLE RECOVERY オプションが "ON" になっている表スペースにある表に対して DROP TABLE ステートメントが実行されると、 ログ・ファイルに追加のログ・エントリーが作成されます。 このログ・エントリーには、除去された表を識別するための情報があります。 エントリーは回復活動記録ファイルでも作成され、 これには表を再作成するのに使用できる情報が含まれます。
以下のようにして、除去された表を回復できます。
注: | 除去された表の ID は、 Backup ID 列の LIST HISTORY 出力にリストされます。 |
エクスポートされたデータは、以下の命名規則に従ってファイルに書き込まれます。 ROLLFORWARD コマンドでユーザーにより指定される export_directory の下では、 それぞれのデータベース区画でサブディレクトリーが作成されます。 ユーザーは、ロールフォワード要求が出される前にサブディレクトリーを作成できます。 これは、特定のドライブまたはマシンにデータをエクスポートするのに使用できます。 サブディレクトリーの名前は "NODEnnnn" です。 ここで、nnnn はデータベース区画またはノード番号です。 それぞれのサブディレクトリーでは、 データ・ファイルが名前 "data" の下にエクスポートされます。 このデータ・ファイルには、 除去された表がそれぞれのデータベース区画にあったときと同じデータが含まれます。
除去された表から回復可能なデータのタイプについて、いくつかの制限事項があります。 一度で回復できる除去された表は 1 つだけです。 複数の除去された表を回復するには、 表が回復されるごとに上記の回復手順を実行しなければなりません。 以下のものは、回復することはできません。
データベース・ログを管理する場合は、以下の項目を考慮してください。
ロールフォワード回復方式が正常完了すると、 ロールフォワードで使用された最後のログは切り捨てられ、 その次の順次ログからロギングが開始されます。 これによって、ログ・パス・ディレクトリー中のログのうち、 ロールフォワード回復に使用された最後のログより順序番号が大きいログが再使用されるという実際的な効果があります。 ROLLFORWARD コマンドを実行する前にログのコピーを必ず作成してください。(ユーザー出口プログラムを使用して、これらのログを別の位置にコピーすることもできます。)
以下のような理由で、異なる複数のログに重複した名前が付けられることがあります。
データベース・マネージャーでは、 ロールフォワード回復時に誤ったログが適用されないようになっていますが、 必要なログの位置を検出することはできません。 ロールフォワード回復時には、必ず正しいログが使用可能になっているようにする必要があります。
データベースまたは表スペースにおける変更項目をロールフォワードする場合に、 ロールフォワード操作が次のログを見つけることができないと、 SQLCA にログ名が戻されて必要な次のログ・ファイルを示し、 ロールフォワード回復は停止します。 この時点で使用可能なログがなくなっている場合は、 ROLLFORWARD コマンドで処理を停止できます。
ロールフォワード回復を停止する場合で (ROLLFORWARD コマンドに STOP オプションを指定し)、 トランザクションの完了が記録されているログがデータベースまたは表スペースに適用されていないと、 未完了のトランザクションがロールバックされ、 データベースまたは表スペースを整合性のある状態にします。
![]() |
上記の図で、表スペースのバックアップ Backup 3 が上部のログ順序列の S0000013.LOG と S0000014.LOG の間で完了すると想定します。 データベース Backup 2 を使用して復元およびロールフォワードを実行する場合は、 S0000012.LOG を使用してロールフォワードする必要があります。 その後、上部のログ順序列か新規の下部のログ順序列で、ロールフォワード操作を継続できます。 下部の順序列でロールフォワードを行う場合は、表スペースのバックアップ Backup 3 を使って表スペースの復元とロールフォワード回復を行うことはできません。
表スペースのバックアップ Backup 3 を使ってログ終了時に表スペースのロールフォワード操作を完了できるようにするには、 データベースのバックアップ Backup 2 を使って復元してから、 上部のログ順序列を使ってロールフォワードする必要があります。 表スペースのバックアップ Backup 3 の復元が終了すると、 ログ終了時のロールフォワード操作を要求できるようになります。
注: | 特殊レジスター CURRENT TIMEZONE には、 UTC とアプリケーション・サーバー・データベースのローカル時との差が含まれています。 ローカル時間は、UTC に現行時間帯の内容を加えたものです。 |
データベース・ログに生装置を使用することができます。 このようにすることには、利点も欠点もあります。
ロー・ログの構成には、newlogpath データベース構成パラメーターを使用できます。 生装置により使用される構文の例については、生 I/Oを参照してください。 ただし、そのようにする前に、上記の利点と欠点、および下記の追加の考慮事項を考慮してください。
複数のディスクを使用する場合は、これによってより大きな装置が提供され、 結果として生じるストライピングは、 より速い入出力スループットによってパフォーマンスを向上させます。
装置のサイズに関する情報を使えば、 オペレーティング・システムのサポートによって DB2 で使用できる装置のサイズ (4 KB ページ内) を指定できます。 DB2 が書き込むことのできるディスク・スペースの量は、 device-size-available として参照されます。
DB2 は装置の最初の 4 KB ページを使用しません。 (このスペースは、一般にオペレーティング・システムが他の目的で使用します。) そのため、DB2 で利用できるスペースの合計は、 装置サイズ = 使用可能な装置サイズ - 1 です。
注:
ロールフォワード処理が完了すると、 最後にコミットされたトランザクションを含むログ・ファイルは切り捨てられ、 その次の順序のログからロギングが開始されます。 切り捨てられたログとそれより大きい順序番号のログのコピーがないなら、 データベースの指定時点以降の部分を回復することはできません。 (ロールフォワード操作後に通常のデータベース活動が行われると、 以後の回復で使用するために新規のログが作成されます。)
このバックアップは、サブディレクトリーに入っているログが空であっても必ず作成してください。
特定時点までの回復をデータベース全体に対して実行したいが、 回復中にログを失う可能性がある場合があるかもしれません。 (このようなことは、バックアップ・データベース・イメージの最後のものと、 データベースの回復目標時点との間にあるアーカイブ・ログ数が膨大である場合などに生じます。)
まず、適用可能なすべてのログを"安全な"位置にコピーする必要があります。 その後、RESTORE コマンドで、ロールフォワード回復方式を使用して、 データベースを特定の時点のものにすることができます。 必要なログがこのプロセス中に壊れたり失われたりした場合は、 他のところに移しておいたすべてのログのバックアップ・コピーを使います。