从Oracle RMAN备份还原失败的时间约为60%（noarchivelog模式）

我遇到了一个奇怪的情况，恢复最近创建的Oracle RMAN备份有时有效，有时无效

我们使用Oracle 12c。数据库正在noarchivelog模式下运行

完整故事：我们有一个大型CI设置，其中节点可以选择一个作业，从repo构建自身并运行测试。对于某些测试，需要构建数据库。为了加快测试速度，我们

• 首次尝试从备份还原数据库
• 如果失败，我们将删除数据库，重建shell和数据。重新创建备份，然后启动测试

当然，我们的想法是，大部分时间恢复都可以工作，实际上，恢复大约有40%的时间可以工作，而在其他时间，恢复失败，数据库重建。这种情况似乎与单个节点之间没有任何关联，它只工作一次，然后就不工作了

我们使用以下脚本进行备份

rman target=/ << EOF
RUN {
    CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
    SHUTDOWN IMMEDIATE;
    STARTUP MOUNT;
    BACKUP DATABASE;
}
EXIT;
EOF

另一个错误

09:49:17 Finished restore at 27-01-2017 09:49:14
09:49:17 
09:49:17 Starting recover at 27-01-2017 09:49:14
09:49:17 using channel ORA_DISK_1
09:49:17 
09:49:17 starting media recovery
09:49:17 
09:49:17 archived log for thread 1 with sequence 52 is already on disk as file /oracle/oradata/DB1/redoDB11.log
09:49:17 archived log for thread 1 with sequence 53 is already on disk as file /oracle/oradata/DB1/redoDB12.log
09:49:17 archived log for thread 1 with sequence 54 is already on disk as file /oracle/oradata/DB1/redoDB13.log
09:49:17 RMAN-08187: WARNING: media recovery until SCN 1755105 complete
09:49:17 Finished recover at 27-01-2017 09:49:15
09:49:17 
09:49:17 RMAN-00571: ===========================================================
09:49:17 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
09:49:17 RMAN-00571: ===========================================================
09:49:17 RMAN-03002: failure of sql statement command at 01/27/2017 09:49:16
09:49:17 ORA-01147: SYSTEM tablespace file 1 is offline
09:49:17 ORA-01110: data file 1: '/oracle/oradata/DB1/DB1_system.dbf'
09:49:17 
09:49:17 RMAN> 

还有一个

11:17:55 starting media recovery
11:17:55 media recovery failed
11:17:55 RMAN-00571: ===========================================================
11:17:55 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
11:17:55 RMAN-00571: ===========================================================
11:17:55 RMAN-03002: failure of recover command at 01/27/2017 11:17:55
11:17:55 ORA-00283: recovery session canceled due to errors
11:17:55 RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed
11:17:55  start until cancel
11:17:55 ORA-00283: recovery session canceled due to errors
11:17:55 ORA-16433: The database or pluggable database must be opened in read/write mode.
11:17:55 
11:17:55 RMAN> 

另一个与上述三个不同的是，这一个在恢复时失败

09:14:11 Starting restore at 06-02-2017 09:14:11
09:14:11 allocated channel: ORA_DISK_1
09:14:11 channel ORA_DISK_1: SID=12 device type=DISK
09:14:12 
09:14:12 creating datafile file number=1 name=/oracle/oradata/DB1/DB1_system.dbf
09:14:12 RMAN-00571: ===========================================================
09:14:12 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
09:14:12 RMAN-00571: ===========================================================
09:14:12 RMAN-03002: failure of restore command at 02/06/2017 09:14:12
09:14:12 ORA-01180: can not create datafile 1
09:14:12 ORA-01110: data file 1: '/oracle/oradata/DB1/DB1_system.dbf'
09:14:12 
09:14:12 RMAN> 

---

任何帮助都将不胜感激。谢谢大家!

为了理解出现错误的原因，重要的是要理解脚本中的每一部分的含义：

RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;

恢复数据库将数据文件从备份集中复制回数据库位置。如果备份时数据库已关闭且一致（完全关闭），则备份是一致的

恢复数据库首次尝试通过应用备份存档重做日志、存档重做日志和/或重做日志，使备份一致。然后，它将尝试从备份时间点向前滚动数据库，直到最近的重做日志。由于您是在NOARCHIVELOG模式下运行的，因此此步骤只会产生与您看到的错误类似的错误

ALTER数据库打开重置日志使数据库联机
RESETLOGS
清除重做日志，并且在不完全恢复后需要它（如果数据库无法前滚并应用备份存档日志、存档日志和重做日志中的所有重做）

考虑到这一点，您的脚本应该如下所示：

RUN {
    SHUTDOWN IMMEDIATE;
    STARTUP MOUNT;
    RESTORE DATABASE;
    ALTER DATABASE OPEN RESETLOGS;
}

作为旁注，您还应该从RMAN配置spfile+controlfile自动备份。无论何时备份数据库，都会自动执行此备份

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';

正如JSapkoka所说，您还应该首先恢复spfile和controlfile，完整的恢复脚本如下所示：

RUN {
    SHUTDOWN IMMEDIATE;
    STARTUP NOMOUNT;
    SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'autobackup_format';
    RESTORE SPFILE FROM AUTOBACKUP;
    SHUTDOWN IMMEDIATE;
    STARTUP NOMOUNT;
    RESTORE CONTROLFILE FROM AUTOBACKUP;
    ALTER DATABASE MOUNT;
    RESTORE DATABASE;
    ALTER DATABASE OPEN RESETLOGS;
}

正如您所说，您的数据库正在noarchivelog模式下运行，您不需要恢复它。您还需要在恢复数据库之前恢复spfile和控制文件。谢谢！恢复的原因是，除非我运行它和下面的命令，否则数据库不会恢复联机。我还原数据库的方法是否不正确，是否应该对noarchivelog执行不同的操作？好吧，您仍然需要“以下命令”。。。只是不要像JSapkota说的那样运行recover命令。在noarchivelog模式下，只需运行：还原数据库；更改数据库打开重置日志；谢谢你的详细回答。我无法在没有还原的情况下让它工作，因为数据库正在抛出下面的消息，这就是为什么我在第一个地方添加了恢复的原因，我之所以在第一个地方添加了恢复的原因，这就是为什么我之所以在第一个地方添加了恢复的原因。我之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以我之所以之所以之所以之所以之所以之所以之所以我之所以在第一个地方添加了恢复的原因：我之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以我之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以添加恢复的原因是我之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以我在第一添加恢复的原因是：我之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以之所以我在第一添加恢复：：：：我的原因原因原因原因原因原因：：：sql语句命令在2017年6月2日14:51:09 ORA-01139失败：RESETLOGS选项仅在数据库不完整后有效recovery@rednax如果在备份和还原尝试之间没有打开数据库（如中所示，您只是在测试备份/还原），则数据库不需要擦除重做日志，因为它仍将被视为完全恢复。这就是你在做的吗？不管怎样，试着用“alterdatabaseopen；”代替“alterdatabaseopenresetlogs；”。运气还不好。我对数据库做了一些更改，以确保在重新测试恢复之前有东西要恢复。尝试更改数据库打开重置日志；给出了相同的错误。如果没有RESETLOGS，则获取RMAN-03002:2017年6月2日15:37:09时sql语句命令失败ORA-01190:控制文件或数据文件1来自最后一次RESETLOGS ORA-01110:数据文件1:@rednax检查您的化身，您可能必须重置化身：RMAN>列表化身；RMAN>将数据库重置为化身#；参考：
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';

RUN {
    SHUTDOWN IMMEDIATE;
    STARTUP NOMOUNT;
    SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'autobackup_format';
    RESTORE SPFILE FROM AUTOBACKUP;
    SHUTDOWN IMMEDIATE;
    STARTUP NOMOUNT;
    RESTORE CONTROLFILE FROM AUTOBACKUP;
    ALTER DATABASE MOUNT;
    RESTORE DATABASE;
    ALTER DATABASE OPEN RESETLOGS;
}