web-dev-qa-db-ja.com

RMAN-リカバリ中にデータファイルが見つかりません

Oracle Linux 7で12.1 SEデータベースを実行しています。回復しようとすると、欠落しているデータファイルに関するrmanスクリプトから毎晩エラー/警告が出ます。

次のスクリプトを使用して、ローカルドライブに対してrmanを実行しています。

RUN {
  RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-7';
  BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'r2cig_incr' DATABASE;
  BACKUP DEVICE TYPE DISK TAG 'r2cig_inc' ARCHIVELOG ALL NOT BACKED UP DELETE ALL INPUT;
  DELETE NOPROMPT OBSOLETE DEVICE TYPE DISK;
}

ディスクスペースの問題により、2つ目のディスクが追加され、チャネルデバイスを変更することで、このディスクを使用するようにrmanを移動しようとしました。

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/u01/rman/r2cig/rman/%U' maxpiecesize 10G;

（後から考えると、シンボリックリンクの方が適している可能性がありますが、当時は、別のドライブ上のバックアップの場所を明示的または明白にすることをお勧めしました）。

このチャンネルの変更による影響はないようです。最初は7日間の保存期間を設定して古いイメージがまだ有効だったのではないかと疑いましたが、7日後もデータファイルイメージが古い場所にまだ作成されていました。

ディスク容量が次第に狭くなるにつれて、別のTAGを使用するようにバックアップスクリプトを変更して、新しいディスク上に新しいバックアップイメージのセットを強制的に作成しようとしました。これは機能しているように見えます。その夜、新しいバックアップイメージのセットが新しいディスクに正常に作成されましたが、その後の回復操作は失敗しているようです。

Starting recover at 19/12/2016 10:45:12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=251 device type=DISK
no copy of datafile 1 found to recover
no copy of datafile 2 found to recover
no copy of datafile 3 found to recover
no copy of datafile 4 found to recover
no copy of datafile 5 found to recover

ドキュメントからの私の理解は、これは最初の実行（データファイルのイメージコピーがない場合）で正常であり、2回目の実行（データファイルコピーはあるがインクリメンタルがない場合）で正常ですが、3回目以降の実行では正常であるということです常にデータファイルのコピーとそれに適用する増分があるはずです。これは現在、最後の6泊は失敗しています。

から https://docs.Oracle.com/cd/B19306_01/backup.102/b14192/bkup004.htm

スクリプトの初回実行時には、データファイルのコピーもレベル1の増分バックアップもないため、このコマンドは効果がありません。

スクリプトの2回目の実行時には、データファイルのコピー（最初のBACKUPコマンドによって作成されたもの）がありますが、レベル1の増分バックアップがないため、このコマンドは効果がありません。

3回目以降のすべての実行では、データファイルのコピーと前の実行からのレベル1の増分があるため、レベル1の増分がデータファイルのコピーに適用され、データファイルのコピーがレベル1の増分のチェックポイントSCNに到達します。

彼ら自身が行う増分バックアップは問題なく作成されており、正しい場所にあるようです。失敗しているのはリカバリのみです。

Recovery Managerがrecoverコマンド中にデータファイルを探している場所/場所を確認する方法はありますか？

それとも強制的に新しい場所を探す方法はありますか？

必要に応じて、以下のRMAN構成：

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/u01/rman/r2cig/rman/%U' MAXPIECESIZE 10 G;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/home/Oracle/app/Oracle/product/12.1.0/dbhome_1/dbs/snapcf_r2cig.f'; # default
oraclebackuporacle-12crman
3
Dave Smylie

不可能を実行するようデータベースに要求する。

タグを変更したため、イメージコピーの新しい初期セットを作成しました。

ディスク容量が次第に狭くなるにつれ、別のTAGを使用するようにバックアップスクリプトを変更して、新しいバックアップイメージのセットを新しいディスクに強制的に作成しようとしました。これは機能するようでした-新しいバックアップイメージのセットは、その夜の新しいディスク上で問題なく作成されました。

これが2016-12-13で起こったとしましょう（これに基づいて想定しています）。

これは、過去6泊で失敗しました

翌日、2016-12-14のバックアップスクリプトがこの時点に達しました：

RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-7';

そのため、2016-12-13で作成されたイメージコピーを以前の状態に戻したいと考えました：SYSDATE-7 = 2016-12-07。それはそのようには機能しません。イメージコピーを以前の状態に巻き戻すことはできません。このようなことを行おうとすると、Recovery Managerは以前のイメージコピーを探します。これは回復できます（逆方向ではなく、順方向）。ただし、指定されたTAGを持つ以前のイメージコピーはないため、no copy of datafile 1 found to recoverになります。

つまり、これは今日まで一日中起こりました。今日、このスクリプトは再度実行されました。

RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-7';

つまり、2016-12-13で作成されたイメージコピーをSYSDATE-7 = 2016-12-12の状態に復元します。それでも動作しません。

明日SYSDATE-7は、新しい初期イメージコピーが作成された日の2016-12-13を意味します。これも失敗すると思います。たとえば、スクリプトは毎日同じ時間に開始されます、00:00。 2016-12-13 00:00に開始し、2016-12-13 01:00にイメージコピーの作成を終了しました。次にスクリプトが開始するとき（2016-12-20 00:00）、SYSDATE-7は以前の時間2016-12-13 00:00を意味します。

しかし、翌日のSYSDATE - 7 = 2016-12-14になると、イメージコピーのリカバリが開始されます。

上記のスクリプトを毎日実行すると、SYSDATE-7のため、最初の7日間は何も回復されません。 8日目から回復します。

または、PREVIEWオプションを指定してスクリプトを実行することで、今すぐ試すことができます。これは、プレビューではなく、回復を行いません。これはおそらく、過去6日間と同じエラーを出力します。

RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-7' preview;

ただし、これにより、リカバリされるイメージコピー、開始と終了のSCN、およびリカバリに使用されるログファイルがリストされます。

RECOVER COPY OF DATABASE WITH TAG 'r2cig_incr' UNTIL TIME 'SYSDATE-5' preview;
6
Balazs Papp