管理の手引き


回復方式: ロールフォワード回復

ロールフォワード回復では、 BACKUP コマンドとともに RESTORE コマンドおよび ROLLFORWARD コマンドを使用します。 ロールフォワード回復を実行すると、 データベースまたは表スペースは指定された時点における元の状態に回復されます。

データベースを初めて作成した時点では、循環ロギングだけが使用可能になります。 つまり、ログは再使用され (循環方式で)、保管も保存もされません。 循環ロギングでは、ロールフォワード回復は不可能です。 破損回復またはバージョン回復だけが使用可能です。 しかし、ログ保存を実行するときは、ロールフォワード回復を実行できます。 これは、バックアップ作成後に、ログがデータベースに対する変更を記録するからです。 logretain データベース構成パラメーターを "RECOVERY" に設定したり、 または userexit データベース構成パラメーターを使用可能にしたり、 あるいはこの両方を実行することによって、ログ・アーカイブを実行します。 これらのパラメーターのどちらかが上記の説明のとおりに構成されていると、 データベースはロールフォワード回復 について使用可能になります。

データベースが回復可能であるときは、 データベースと表スペースの両方のレベルでバックアップ、回復、 およびロールフォワード回復を実行できます。 データベースと表スペースのバックアップは、オンラインで行えます。 オンライン復元とロールフォワードは、表スペース・レベルでも行えます。

ロールフォワード回復では、ログに記録された完了作業単位を、 復元されたデータベース、表スペース、または複数の表スペースに再適用します。 ロールフォワード回復をログの最後まで実行するか、 あるいは特定の時点まで実行するかを指定できます。

データベースの復元で説明したように、 ロールフォワード回復はデータベース全体を復元した後に実行できます。 ロールフォワード操作保留状態の表スペースにも実行できます。 表スペースのロールフォワードの考慮事項については、 表スペースにおける変更のロールフォワードを参照してください。

ロギングに関連するデータベース構成パラメーターの詳細な説明については、 データベース・ロギングの構成パラメーターを参照してください。

バックアップについての考慮事項

データベースで順方向回復を行えるようになったときに適用される、 バックアップについての考慮事項を以下に示します。 バックアップの実行に適用される一般的な情報については、以下を参照してください。

データベース全体または表スペースをバックアップまたは復元すると、 回復活動記録ファイルが要約情報によって自動的に更新されます。 このファイルは、データベース内の復元のアクティビティーを記録する機能として便利です。 このファイルは、データベース構成ファイルと同じディレクトリーに作成されます。 回復活動記録ファイルについては、回復活動記録ファイルの情報を参照してください。

UNIX ベースの環境では、ディスクに作成されるファイル名は、 以下の情報をピリオドで区切って連結したもので構成されます。 他のプラットフォームでは、4 レベルから構成されるサブディレクトリー・ツリーが使用されます。

データベース別名
バックアップ・コマンドの呼び出し時に指定した 1〜8 文字のデータベース別名。

タイプ
作成されたバックアップのタイプで、"0" はデータベース全体、 "3" は表スペース、"4" は表ロードからのコピーです。

インスタンス名
DB2INSTANCE 環境変数からとられるデータベース・マネージャーの 1〜8 文字の現行インスタンス名。

ノード番号
ノード番号。

カタログ・ノード番号
データベースのカタログ・ノードのノード番号。

タイム・スタンプ
バックアップが実行された日付と時刻を 14 文字で表記したもの。 タイム・スタンプは yyyymmddhhnnss という形式です。 ただし、
yyyy は年 (1995 〜 9999)
mm は月 (01 〜 12)
dd は日 (01 〜 31)
hh は時 (00 〜 23)
nn は分 (00 〜 59)
ss は秒 (00 〜 59)

順序番号
ファイル拡張子として使用する 3 桁の順序番号。

復元に関する考慮事項

データベースで順方向回復を行えるようになったときに適用される、 復元についての考慮事項を以下に示します。 復元の実行に適用される一般的な情報については、以下を参照してください。

以下のことを考慮しなければなりません。

データベース変更のロールフォワード操作

ロールフォワード回復は復元されたデータベースを基に実行されるため、 データベース・バックアップが作成された後の特定の時点までデータベースを復元することができます。 この時点はログの最後か、 データベース・バックアップ作成時とログの最後までの間の任意の時点です。
注:全ログの末尾まで復元およびロールフォワードを実行する場合、 LIST HISTORY コマンドの後に示されるバックアップ ID は、最終時刻を表します。 つまり、バックアップ ID 値は 99991231235959 です。 ロールフォワードを実行する場合、 バックアップ ID の変換方法はこれだけです。

活動またはアーカイブ・ログが使用できない場合は、特定の時点の回復を使用できます。 この場合は、ログが失われた時点までロールフォワード可能です。 データベースに対しエラーが含まれたトランザクションが実行された場合も、 特定の時点までロールフォワード可能です。 この場合は、データベースを復元した後、 エラーが含まれたトランザクションの実行直前までロールフォワードします。

図 55. ロールフォワード回復


SQLD0RFL

表スペースについて特定時点のロールフォワード回復を実行することもできます。 詳細については、表スペースにおける変更のロールフォワードを参照してください。

この方式を使用するには、 ロールフォワード回復を使用可能にするようデータベースを構成する必要があります。 次の部分では、 データベース構成ファイルとデータベース・ログについての考慮事項を扱います。

DATALINK 列を含む表がある場合、 データベースおよび表スペースを復元してからログの終わりまでロールフォワードするおよび データベースおよび表スペースを復元してからある時点までロールフォワードするも参照してください。

データベース・ロギングの構成パラメーター

データベース構成ファイルには、 ロールフォワード回復に関連するパラメーターが含まれています。 省略時パラメーターではこの回復がサポートされていないので、 この方法を使用する予定の場合は、それらの省略時値をいくつか変更する必要があります。 DB2 UDB の構成についての詳細は、 第 32 章, DB2 の構成を参照してください。

1 次ログ (logprimary)
このパラメーターには、作成する 1 次ログの個数を指定します。

空の場合でもいっぱいの場合でも、1 次ログには同じ容量のディスク・スペースが必要です。 それで、必要以上に多数のログを構成すると、 不必要にディスク・スペースを使用することになります。 構成するログ数が少なすぎると、ログ満杯条件になる可能性があります。 構成するログの個数を選択する際は、それぞれのログのサイズと、 アプリケーションでログ満杯条件を処理できるかどうかを考慮する必要があります。

既存データベースでロールフォワード回復を使用可能にしている場合は、1 次ログの数を、 1 次ログと 2 次ログの合計数に 1 を足した数に変更する必要があります。 ロールフォワード回復が可能になっているデータベースでは、 long varchar フィールドと LOB フィールドについて追加情報がログに記録されます。

ログ・ファイルの合計サイズの限界は、32 GB です。 つまり、ログ・ファイルの数 (LOGPRIMARY + LOGSECOND) に、 各ログ・ファイルのサイズ (バイト単位) (LOGFILSIZ * 4096) を掛けた値が、 32 GB より小さくなければなりません。

この構成パラメーターの詳細は、第 32 章, DB2 の構成を参照してください。

2 次ログ (logsecond)
このパラメーターは、回復ログ・ファイル用に (必要に応じて) 作成されて使用される 2 次ログ・ファイルの数を指定します。

1 次ログ・ファイルがいっぱいになると、 logfilsiz で指定されたサイズの 2 次ログ・ファイルが必要に応じて 1 度に 1 つずつ割り振られます。 このパラメーターは、その最大数を制御します。 このパラメーターで指定した数より多くの 2 次ログ・ファイルが必要になると、 エラー・コードがアプリケーションに戻され、 データベースに対する活動は停止されます。

この構成パラメーターの詳細は、第 32 章, DB2 の構成を参照してください。

ログ・サイズ (logfilsiz)
このパラメーターには、構成する各ログのページ数を指定します。 ページのサイズは 4 KB です。

注:ログ・ファイルの合計サイズの限界は、32 GB です (つまり、 (logfilsiz + logprimary) x logfilsiz < 32 GB/4096)。

各 1 次ログのサイズは、パフォーマンスに直接影響します。 データベースの構成がログを保持するようになっている場合は、ログが満杯になるたびに、 新規ログの割り振りと初期化を求める要求が出されます。 ログのサイズを大きくすると、 新規ログの割り振りと初期化に必要な要求の回数は少なくなります。 (ただし、ログ・サイズを大きくすれば、 新規ログの形式化処理にかかる時間が長くなります。) 新規ログの形式化処理はデータベースに接続しているアプリケーションにとって透過的なので、 形式化処理はデータベースのパフォーマンスに影響しません。

データベースをオープンするための処理時間を最小限にするためにデータベースをオープンしたままにするアプリケーションを使用している (回復のパフォーマンスに関する考慮事項参照) 場合、 ログ・サイズの値はオフライン・アーカイブ・ログのコピーの作成にかかる時間によって決める必要があります。

オフライン・アーカイブ・ログを保管するのに使用している装置のデータ転送速度、 およびコピー作成に使用しているソフトウェアのデータ転送速度は、 データベース・マネージャーがログに書き込むときの平均速度以上であることが必要です。 転送速度が新規ログ・データの生成速度に追いつかない場合、 ディスク・スペースの空き容量によっては、 ロギング・アクティビティーがかなり長い時間続行されると、 ディスク・スペースを使い切ってしまうおそれがあります。 そうなると、データベース処理が停止してしまいます。

テープ装置または光媒体を使用している場合には、データ転送速度が最重要になります。 (ログを保管するために異なる媒体を使用する場合については、 付録 F, データベース回復用のユーザー出口を参照してください。) テープ装置の中には、ファイルのコピーに、 サイズに関係なく同じ長さの時間がかかるものがあります。 保存装置の能力について調べておく必要があります。

テープ装置には、このほかにも特有の考慮事項がいくつかあります。 保存要求の頻度も重要です。 コピー操作時間が 5 分間であるとすると、ログのサイズは、 作業負荷がピークの時の 5 分間分のログ・データを保持できるだけの十分な大きさになっている必要があります。 またテープ装置には、1 日あたりの操作回数に設計上の限界がある場合もあります。 ログ・サイズを決定するときは、これらの要素を考慮するようにしてください。

ログ・ファイルの損失を最小限にくい止めることも、 ログ・サイズを設定する際の重要な考慮事項の 1 つです。 保存には、ログ全体が必要です。 単一の大きなログを使用する場合は、保存の間隔を長くしてください。 ログが入っている媒体で障害が発生した場合は、 トランザクション情報がいくらか失われる可能性があります。 ログ・サイズを小さくすれば、保存の頻度は高くなりますが、 小さいログを使うため、媒体障害が発生しても失う情報量が少なくなります。

ログ・バッファー (logbufsz)
このパラメーターには、ログ・レコードをディスクに書き込む前に、 ログ・レコード・バッファーとして使用する、 データベース共有メモリーの量を指定します。 これらのログ・レコードは、以下のことが発生した場合にディスクに書き込まれます。

ログ・レコードのバッファリング機能によって、ディスクに書き込む頻度が少なくなり、 1 度に書き込まれるログ・レコードの数が多くなるので、 ロギング・ファイルの入出力がさらに効率的になります。

グループへのコミット回数 (mincommit)
このパラメーターを使うと、最低限の回数のコミットが実行されるまで、 ログ・レコードのディスク書き込みを遅らせることができるようになります。 この遅延により、ログ・レコード書き込みに関連するデータベース・マネージャーのオーバーヘッドが少なくなるため、 データベースに対して複数のアプリケーションを実行しており、 それらのアプリケーションによって非常に短い時間フレームに多数のコミットが要求される場合のパフォーマンスを向上させることができます。

このコミットのグループ化が行われるのは、このパラメーターの値が 1 より大きく、 データベースに接続されているアプリケーションの数がこのパラメーターの値より大きい場合だけです。 コミットのグループ化が実行中である場合、 アプリケーションのコミット要求は、1 秒経過するか、 またはコミット要求回数がこのパラメーター値に達するまで保留されます。

新規ログ・パス (newlogpath)
データベース・ログは、最初、 データベース・ディレクトリーのサブディレクトリー SQLOGDIR の中に作成されます。 アクティブ・ログと将来のアーカイブ・ログを保管する位置を変更するには、 この構成パラメーターの値を変更して別のディレクトリーか装置を指示するようにします。 データベースの構成が現在ロールフォワード回復用になっている場合、 データベース・ログ・パス・ディレクトリーに保管されるアーカイブ・ログは新規の記憶位置に移動されません。

ログ・パス・ディレクトリーは変更可能なので、ロールフォワード回復に必要なログが別のディレクトリーや別の装置に存在している可能性があります。 ロールフォワード操作中に、この構成パラメーターを変更して、 複数の位置のログにアクセスできます。

newlogpath の値への変更は、 データベースが一貫した状態になるまで適用されません。 参照用のデータベース構成パラメーター database_consistent はデータベースの状況を示しています。 この構成パラメーターの詳細は、第 32 章, DB2 の構成を参照してください。 データベースが一貫した状態になっていない場合にデータベース・ログが果たす役割については、 ログ・ファイル管理についての考慮事項を参照してください。

ログ保持 (logretain)
このパラメーターを設定すると、 アーカイブ・ログがデータベース・ログ・パス・ディレクトリーに保持されます。 これを "RECOVERY" に設定することによって、 データベース・マネージャーでロールフォワード回復方式を使用できるようになります。 logretain 構成パラメーターが使用可能になっていれば、 userexit を使用可能にする必要はありません。 ロールフォワード回復方式は、 2 つのうち一方のパラメーターを設定すれば使用可能になります。

このパラメーターを使うと、省略時の循環ロギングを上書きすることになります。

ユーザー出口 (userexit)
このパラメーターを使うと、データベース・マネージャーでログの保存と検索のためのユーザー出口プログラムを呼び出せるようになります。 ユーザー出口を使用可能にすると、ロールフォワード回復が可能になります。 userexit 構成パラメーターが使用可能になっていれば、 logretain を使用可能にする必要はありません。 ロールフォワード回復方式は、 2 つのうち一方のパラメーターを設定すれば使用可能になります。

このパラメーターを使うと、省略時の循環ロギングを上書きすることになります。 userexitlogretain を暗黙指定しますが、 その逆の暗黙指定はありません。

ユーザー出口プログラムについては、付録 F, データベース回復用のユーザー出口を参照してください。

userexit 構成パラメーターか logretain 構成パラメーターのどちらかを使用してロールフォワード回復を行うときに、アクティブ・ログ・パスが重要です。 userexit 構成パラメーターが使用可能になっていると、 アクティブ・ログ・パスから離れたログ・ファイルを保存するためにユーザー出口が呼び出されます。 logretain 構成パラメーターが "RECOVERY" に設定されていると、 ログ・ファイルがアクティブ・ログ・パスに残るようにします。 アクティブ・ログ・パスは、「Path to Log Files」か「Changed Path to Log Files」(newlogpath) のどちらかによって決まります。

表スペースにおける変更のロールフォワード

データベースが順方向回復であれば、データベース全体を使用する代わりに、 表スペースをバックアップしたり、復元したり、ロールフォワードしたりできます。 個別の表スペースについて回復方針を決めておくこともでき、 これにより時間が節約されます。 つまり、データベース全体を回復するよりは、 データベースの一部を回復した方が時間は短縮されるからです。 たとえば、ディスクが不良で、そのディスクに表スペースが 1 つだけ含まれている場合は、 データベース全体を回復しなくても (したがって、 データベースの残りの部分に対するユーザー・アクセスに影響を与えずに)、 当該表スペースだけを復元しロールフォワードできます。 また、表スペース・レベルのバックアップを用意しておけば、 データベースの重要な部分を他の部分より頻繁にバックアップすることが可能になり、 これによりデータベース全体のバックアップより時間は短縮されます。

最後に実行したバックアップの後で表スペースの名前を変更した場合、 その表スペースをロールフォワードする際には、 必ず新しい名前を使用してください。 以前の表スペースの名前は認識されません。 また、 最低でもその表スペースの名前を変更した時点までロールフォワードを行わなければなりません。

区分データベース環境で、一部のデータベース区画がロールフォワード保留状態で、 他のデータベース区画では、一部の表スペース (データベース区画ではない) がロールフォワード保留状態の場合は、 まず、データベース区画をロールフォワードし、 次に表スペースをロールフォワードします。

表のデータおよび長形式オブジェクトが別々の表スペースに存在する場合に、 その表が再編成された場合は、 データと長形式のオブジェクトのための表スペースは同時に復元し、 ロールフォワードする必要があります。 表再編成後に、関係する表スペースのバックアップを作成する必要があります。

現在の状況を示すために、様々な状態が表スペースに関連付けられています。

表スペースは復元されると、常にロールフォワード保留状態になります (つまり、 表スペースを復元して WITHOUT ROLLING FORWARD パラメーターを指定すると、 WITHOUT ROLLING FORWARD は無視されます)。 表スペースを使用可能にするためには、 表スペースにロールフォワード回復を実行する必要があります。 ログの最後までロールフォワードすることもでき、 特定の時点までロールフォワードすることもできます。 特定の時点まで表スペースをロールフォワードしたい場合は、次の点に注意してください。

時刻 T3 より後の時間の TABSP1 のバックアップ・イメージが見つからないか、 TABSP1 を T3 またはそれより前に復元したい場合は、次の操作を実行できます。

区分データベース環境では、 表スペースのすべての部分を同時に同じ時点までロールフォワードする必要があります。 これにより、表スペースはそれぞれのデータベース区画で整合性が保証されます。

ROLLFORWARD コマンド使用の計画

ROLLFORWARD コマンドを使う前に、以下の項目を考慮する必要があります。

注:実行中のロールフォワード操作を取り消すために、 ROLLFORWARD CANCEL を使用することはできません。 これは、ROLLFORWARD STOP が出されていない完了したロールフォワード操作を取り消すため、 または完了する前に失敗したロールフォワード操作について使用することができます。

DATALINK 列を含む表がある場合、復元およびロールフォワードについての考慮事項も参照してください。

バージョン 2 クライアントからは、 区分データベースをロールフォワードすることはできません。

ROLLFORWARD コマンドの呼び出し

ROLLFORWARD コマンドを呼び出す場合は、その前に以下の点を考慮してください。

ロード・コピー・ロケーション・ファイルの使用

DB2LOADREC レジストリー変数を使って、ロード・コピー所在情報のあるファイルを識別します。 ロールフォワード回復時にこのファイルを使って、ロード・コピーを探します。 次の情報が含まれています。

ロケーション・ファイルがないか、または対応する項目がこの項目にない場合は、 ログ・レコード中の情報が使われます。

ロールフォワード回復が実行される前に、ファイル内の情報が上書きされることがあります。

注:

  1. 区分データベース環境では、 DB2LOADREC レジストリー変数は db2profile ファイル内に含まれていなければなりません。

  2. 区分データベース環境では、ロード・コピー・ファイルは各データベース区画サーバーに存在していなければならず、 ファイル名 (パスも含め) は同じでなければなりません。

  3. 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 ステートメントが実行されると、 ログ・ファイルに追加のログ・エントリーが作成されます。 このログ・エントリーには、除去された表を識別するための情報があります。 エントリーは回復活動記録ファイルでも作成され、 これには表を再作成するのに使用できる情報が含まれます。

以下のようにして、除去された表を回復できます。

  1. 除去された表を識別します。 この識別子は、LIST HISTORY DROPPED TABLE コマンドを使用すると、 回復活動記録ファイルで見つかります。 除去された表のリストが表示され、表を再作成するのに必要な情報も得られます。

    注:除去された表の ID は、 Backup ID 列の LIST HISTORY 出力にリストされます。
    このコマンドの詳細については、コマンド解説書 を参照してください。

  2. 表が除去される前に実行されたデータベースまたは表スペース・レベルのバックアップを復元します。
  3. ROLLFORWARD コマンドで RECOVER DROPPED TABLE オプションを使用して、 除去した後の特定の時刻までロールフォワードします。 このオプションを使用する際に必要なその他の情報には、 除去された表の識別、および出力ファイルが書き込まれるディレクトリー・パスが含まれます。 ディレクトリー・パスは、すべてのデータベース区画からアクセスできるものか、 またはそれぞれの区画に存在するかのいずれかでなければなりません。 このコマンドの詳細については、コマンド解説書 を参照してください。
  4. 活動記録ファイルから CREATE TABLE ステートメントを使用して表を再作成します。
  5. ROLLFORWARD コマンドによりエクスポートされたデータを、表にインポートします。

エクスポートされたデータは、以下の命名規則に従ってファイルに書き込まれます。 ROLLFORWARD コマンドでユーザーにより指定される export_directory の下では、 それぞれのデータベース区画でサブディレクトリーが作成されます。 ユーザーは、ロールフォワード要求が出される前にサブディレクトリーを作成できます。 これは、特定のドライブまたはマシンにデータをエクスポートするのに使用できます。 サブディレクトリーの名前は "NODEnnnn" です。 ここで、nnnn はデータベース区画またはノード番号です。 それぞれのサブディレクトリーでは、 データ・ファイルが名前 "data" の下にエクスポートされます。 このデータ・ファイルには、 除去された表がそれぞれのデータベース区画にあったときと同じデータが含まれます。

除去された表から回復可能なデータのタイプについて、いくつかの制限事項があります。 一度で回復できる除去された表は 1 つだけです。 複数の除去された表を回復するには、 表が回復されるごとに上記の回復手順を実行しなければなりません。 以下のものは、回復することはできません。

ログ・ファイル管理についての考慮事項

データベース・ログを管理する場合は、以下の項目を考慮してください。

ロー・ログの使用

データベース・ログに生装置を使用することができます。 このようにすることには、利点も欠点もあります。

ロー・ログの構成には、newlogpath データベース構成パラメーターを使用できます。 生装置により使用される構文の例については、生 I/Oを参照してください。 ただし、そのようにする前に、上記の利点と欠点、および下記の追加の考慮事項を考慮してください。

ログの消失

特定時点までの回復をデータベース全体に対して実行したいが、 回復中にログを失う可能性がある場合があるかもしれません。 (このようなことは、バックアップ・データベース・イメージの最後のものと、 データベースの回復目標時点との間にあるアーカイブ・ログ数が膨大である場合などに生じます。)

まず、適用可能なすべてのログを"安全な"位置にコピーする必要があります。 その後、RESTORE コマンドで、ロールフォワード回復方式を使用して、 データベースを特定の時点のものにすることができます。 必要なログがこのプロセス中に壊れたり失われたりした場合は、 他のところに移しておいたすべてのログのバックアップ・コピーを使います。


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