RMAN异机恢复遭遇ORA-01547、ORA-01152、ORA-01110错误案例

测试环境：

    操作系统  ：  Red Hat Enterprise Linux ES release 4 (Nahant Update 4)   VMWARE

    数据库     ：  Oracle Database 10g Release 10.2.0.4.0 - Production

    简要介绍，一台服务器A位于虚拟机VMWARE上，由于测试需要，在VMWARE上克隆了该系统作为服务器B，过了一段时间，由于数据变更，需要将服务器A上的ORACLE数据库还原恢复到服务器B上。

案例介绍：

由 于这两台服务器的数据库实例名称相同、以及对应的环境基本一致（恢复目录相同，数据文件、控制文件都是一致），所以虽然是RMAN异机备份，但是这种异机 恢复相对而言比较简单，不需要修改实例名称、数据库名称、指定数据文件位置等等。一般来说，这种环境的恢复还原基本没啥问题。下面介绍操作过程以及解决方 法。

Step 1：通过FTP将对应的备份文件以及归档日志放置到相应的目录位置。

Step 2：还原数据库的spfile文件。

Step 3： 关闭数据库后，利用还原spfile的初始化文件启动数据库

Step 4： 恢复数据库控制文件。

Step 5： 将数据库启动到mount状态

RMAN> alter database mount;

database mounted

released channel: ORA_DISK_1

Step 6： restore 数据库（中间太多数据文件restore，使用.....替代）

Step 7 ： recover database

截图如下所示

关于ORA-01547的解释如下所示：

此错误的最可能的原因是执行不完全恢复前。忘记从一个足够旧的备份还原一个或 多个数据文件。

Step 8：

   1: RMAN> alter database open resetlogs;

   2:  

   3: RMAN-00571: ===========================================================

   4:  

   5: RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

   6:  

   7: RMAN-00571: ===========================================================

   8:  

   9: RMAN-03002: failure of alter db command at 04/02/2014 12:04:53

  10:  

  11: ORA-01152: file 1 was not restored from a sufficiently old backup

  12:  

  13: ORA-01110: data file 1: '/u01/app/oracle/oradata/EPPS/system01.dbf'

  14:  

  15: RMAN>

  16:  

  17: RMAN> exit

关于open resetlogs选项，是指打开数据时，重置联机重做日志（online redo log），即将重做日志的sequence置零，为什么要重置重做日志呢？不完全恢复后，原来的联机重做日志（online redo log）里面包含的是未做恢复前的数据，而这些数据对于恢复后的数据库不再有效，所以数据库会要求在open之前先对联机重做日志（online redo log）的sequence置零。Resetlogs命令表示一个数据库逻辑生存期的结束和另一个数据库逻辑生存期的开始，每次使用Resetlogs命 令的时候，SCN不会被重置，不过ORACLE会重置日志序列号，而且会重置联机重做日志内容（相当于把所有的联机日志重新“格式化”）。

解决方法

此时可以通过设置隐藏参数_allow_resetlogs_corruption之后，使数据库在Open过程中，跳过某些一致性检查，从而使数据库可能跳过不一致状态。操作步骤如下

截图如下所示

使用了隐藏参数_allow_resetlogs_corruption后，需要从参数文件（pfile或spfile中）移除隐藏参数，并对数据库进行导入导出比较好，不过此处都是测试数据库，重要性不是很高。在此忽略这些步骤。