RMAN - 恢复期间未找到数据文件

Question

我在 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;
}

由于磁盘空间问题，添加了第二个磁盘，我尝试通过更改通道设备来移动 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

我从文档中的理解是，这在第一次运行时是正常的（当没有数据文件映像副本时），在第二次运行时正常（当有数据文件副本时，但没有增量），但是在第三次和后续运行时应该总是有一个数据文件副本和一个增量应用到它。这在过去的 6 个晚上一直失败。

来自https://docs.oracle.com/cd/B19306_01/backup.102/b14192/bkup004.htm

脚本第一次运行时，此命令无效，因为既没有数据文件副本，也没有级别 1 增量备份。

第二次运行脚本时，有一个数据文件副本（由第一个 BACKUP 命令创建），但没有增量级别 1 备份，因此该命令再次无效。

在第三次运行和所有后续运行中，有一个数据文件副本和前一次运行的 1 级增量，因此将 1 级增量应用于数据文件副本，使数据文件副本上升到 1 级增量的检查点 SCN .

他们自己的增量备份似乎创建得很好，并且在正确的位置，只是恢复失败了。

有什么方法可以查看 RMAN 在恢复命令期间查找数据文件的内容/位置吗？

或者有没有办法强制它查看新位置？

如果需要，我的 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

Answer 1

要求数据库做不可能的事。

您更改了 TAG，因此您创建了一组新的初始映像副本。

随着磁盘空间变得越来越紧张，我更改了备份脚本以使用不同的 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。那不是那样工作的。您无法将图像副本倒回早期状态。当您尝试执行此类操作时，RMAN 将查找较早的映像副本，它可以恢复（向前，而不是向后），但没有具有指定 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. 它会在第 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;