Oracle异机恢复

; //注：此642是指恢复archivelog时,从Sequence为4620的备份开始还原。
　　　　BS 关键字 大小 设备类型占用时间 完成时间
　　　　------- ---------- ----------- ------------ ----------
　　　　1 149.20M DISK 00:00:01 22-7月 -16
　　　　BP 关键字: 1 状态: AVAILABLE 已压缩: NO 标记: TAG20160722T152937
　　　　段名:/tmp/archlog_DBINFO_1

　　　　备份集 1 中的已存档日志列表
　　　　线程序列 低 SCN 时间下限 下一个 SCN 下一次
　　　　---- ------- ---------- ---------- ---------- ---------
　　　　1 642 126150727 19-7月 -16 126275396 22-7月 -16


6. 修改数据文件恢复的新路径【报错参考，见文末尾】
　　# 查看恢复的控制文件中记录的redolog的位置.
　　# select group#, member from v$logfile;
　　注：这些需要放到run 运行块中。
　　RMAN> run {
　　　　allocate channel a1 type disk;
　　　　allocate channel a2 type disk;
　　　　set until sequence=4631 thread=1;
　　　　set newname for datafile ‘/dev/udpay/lv_system01_1024m‘ to ‘/oracle/oradata/udpay/1024m_system01.dbf‘;
　　　　set newname for datafile ‘/dev/udpay/lv_undo01_8192m‘ to ‘/oracle/oradata/udpay/8192m_undotbs01.dbf‘;
　　　　set newname for datafile ‘/dev/udpay/lv_tools01_256m‘ to ‘/oracle/oradata/udpay/256m_users01.dbf‘;
　　　　set newname for datafile ‘/dev/udpay/lv_users01_256m‘ to ‘/oracle/oradata/udpay/256m_tools01.dbf‘;
　　　　set newname for datafile ‘/dev/udpay/lv_perf_256m‘ to ‘/oracle/oradata/udpay/256m_perf.dbf‘;
　　　　set newname for datafile ‘/dev/udpay/lv_whtapp_data01‘ to ‘/oracle/oradata/udpay/whtapp_data01.dbf‘;
　　　　set newname for datafile ‘/dev/udpay/lv_whtapp_data02‘ to ‘/oracle/oradata/udpay/whtapp_data02.dbf‘;
　　　　set newname for datafile ‘/dev/udpay/lv_whtapp_data03‘ to ‘/oracle/oradata/udpay/whtapp_data03.dbf‘;
　　　　set newname for datafile ‘/dev/udpay/lv_whtapp_index01‘ to ‘/oracle/oradata/udpay/whtapp_index01.dbf‘;
　　　　set newname for datafile ‘/dev/udpay/lv_indx01_256m‘ to ‘/oracle/oradata/udpay/indx01.dbf‘;

　　　　restore database; //这里就是直接采用默认RMAN备份路径中恢复数据文件。

　　　　#注: RMAN中使用sql来执行SQL命令时,SQL命令需要用双引号引起来, 并且,双引号内部有单引号,则单引号要写两次.
　　　　# 下面双引号内部的都是单引号,并且都是双写的。
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo11_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo11.log‘‘";
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo12_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo12.log‘‘";
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo21_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo21.log‘‘";
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo22_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo22.log‘‘";
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo31_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo31.log‘‘";
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo32_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo32.log‘‘";
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo41_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo41.log‘‘";
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo42_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo42.log‘‘";
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo51_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo51.log‘‘";
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo52_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo52.log‘‘";
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo61_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo61.log‘‘";
　　　　sql "alter database rename file ‘‘/dev/udpay/lv_redo62_256m‘‘ to ‘‘/oracle/oradata/udpay/256m_redo62.log‘‘";

　　　　switch datafile all;
　　　　release channel a1;
　　　　release channel a2;
　　}

8. 在RMAN中执行数据库一致性恢复
　　rman target /
　　RMAN> recover database;
　　------------------------------------------------------------------------------------------------------------------------------
　　出现下面错误是正常的：
　　RMAN-00571: =========================================
　　RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===
　　RMAN-00571: =========================================
　　RMAN-03002: failure of recover command at 06/24/2015 16:02:25
　　RMAN-06054: media recovery requesting unknown log: thread 1 scn 277200603
　　------------------------------------------------------------------------------------------------------------------------------

　　若失败则回到sqlplus 中尝试：
　　sqlplus /nolog;
　　SQL> conn / as sysdba
　　SQL> alter database open resetlogs;


补充1：
　　这是另一次恢复Oracle数据库时,出现的错误：
　　RMAN> alter database open resetlogs;
　　RMAN-00571: ===========================================================
　　RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
　　RMAN-00571: ===========================================================
　　RMAN-03002: alter db 命令 (在 07/24/2016 16:36:40 上) 失败
　　ORA-01152: 文件 1 没有从过旧的备份中还原
　　ORA-01110: 数据文件 1: ‘/home/oracle/ora/oradata/dbinfo/system01.dbf‘

　　上面这个错误,网上有说：是system01.dbf中的头部的SCN与控制文件中记录的数据文件头部SCN不同.
　　解决方法：
　　　　数据文件头部start scn比控制文件记录的数据库文件头部SCN要新，那么
　　就要使用日志（包括归档日志+联机重做日志）前推控制文件中记录的数据库
　　头部SCN与数据文件start scn一致，就能保证打开数据库。
　　因为是使用备份的控制文件恢复数据库，那么就必须alter database open resetlogs打开数据库

　　sqlplus / as sysdba
　　SQL> startup mount
　　SQL> recover database using backup controlfile until cancel;
         # 注意：这一步，因为备份的控制文件没有记录联机重做日志文件的scn，
　　　#         这里需要手动输入redo文件来取消恢复.
　　ORA-00279: 更改 126276941 (在 07/22/2016 15:43:45 生成) 对于线程 1 是必需的
　　ORA-00289: 建议:
　　/home/oracle/ora/product/11.2.0.3/dbhome_1/dbs/arch1_644_810751417.dbf
　　ORA-00280: 更改 126276941 (用于线程 1) 在序列 #644 中

　　指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
　　/tmp/redo01.log 　　　　 #这是手动输入备份的redolog文件.
　　ORA-00310: 归档日志包含序列 642; 要求序列 644
　　ORA-00334: 归档日志: ‘/tmp/redo01.log‘
　　注:
　　　　总共有10个redolog,我都这样执行了一次,不知道是否有必要.
　　另注:
　　　　我并不十分明白,这究竟是什么原因,我还尝试了使用ArchiveLog文件来恢复.
　　但我发现归档文件依然不包含序列644.最后,我尝试使用“alter database open resetlogs;”
　　提示：
　　　　alter database open resetlogs
　　　　*
　　　　第 1 行出现错误:
　　　　ORA-01139: RESETLOGS 选项仅在不完全数据库恢复后有效
　　　　#  然后,我再次使用：
　　　　alter database open;
　　　　# 竟然打开了。神奇的事件。

补充2：
　　执行：第6步时，出现以下错误：
　　RMAN-00571: ===========================================================
　　RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
　　RMAN-00571: ===========================================================
　　RMAN-03002: restore 命令 (在 07/24/2016 15:47:27 上) 失败
　　RMAN-06026: 有些目标没有找到 - 终止还原
　　RMAN-06023: 没有找到数据文件4的副本来还原
　　RMAN-06023: 没有找到数据文件3的副本来还原
　　RMAN-06023: 没有找到数据文件2的副本来还原
　　RMAN-06023: 没有找到数据文件1的副本来还原

　　此错误：网上描述这是Oracle10以后，出的一个新特性incarnation, 导致的错误。
　　　　注: incarnation 是:为了解决还原resetlogs以前的备份,而出的一个特性;

　　　　

　　这个图是我对incarnation的理解：
　　意思是第一个不完全恢复到SCN(检查点)700处,resetlogs后,incarnation+1,开始使用数据库
　　这时,SCN将从700处继续增加，这时发现有些数据没有，需要在往前还原, 就有了第
　　二次不完全恢复，接着再继续使用DB, 第三次,又发现还需要还原，但是, 是还原到
　　前一次resetlogs后,SCN增长到800的地方的,但从上图可以很清楚的知道, 现在若直接
　　恢复到SCN800处,是第二次resetlogs后,SCN增长到800的地方，但现在要恢复到第一次
　　resetlogs后，SCN增长的800的地方,就需要先回到incarnation 1的场景中。在做恢复就可以了。
　　即：先reset database to incarnation 1; 在进行不完全恢复。

　　还回到上面RMAN恢复时出现错误这个话题：
　　　　由于当前版本是Oracle11.2.0.3，肯定是有Incarnation的问题的, 但事实上，我是做完全恢复，
　　不需要incarnation特性，要想关闭它，可以直接修改 $ORACLE_HOME/dbs/init$ORACLE_SID.ora
　　文件，将其中的下面两个注释掉，即直接在前面加“#”即可。
　　　　#*.db_recovery_file_dest=‘/home/oracle/ora/flash_recovery_area‘
　　　　#*.db_recovery_file_dest_size=4070572032
　　为何要这么做？ 【下面是我的理解,仅做参考】
　　　　因为,异机恢复时，Incarnation特性,找恢复的SCN点时，这个SCN可能与备份集中的SCN一样,就像
　　上面第一次和第二次都包含SCN800一样,因此,它从当前(就上上图中从第二次resetlogs)的SCN中找
　　恢复时指定的SCN点, 而这里是没有这些数据文件的。为了不让Oracle采用这种机制，可将恢复文件
　　位置注释掉，这样Oracle就不会到恢复文件目录中找当前resetlogs后的备份集文件了。

第二个错误：
　　SQL> startup
　　#在Startup时,出现下面这个错误:[下面这个博客总结了这个错误.]
　　# http://www.cnblogs.com/kerrycode/p/3656655.html

　　ORA-01102: cannot mount database in EXCLUSIVE mode

　　出现这种错误的三种情况：
      a、 Oracle的共享内存段或信号量没有被释放；
      b、 Oracle的后台进程（如SMON、PMON、DBWn等）没有被关闭；
      c、 用于锁内存的文件lk<sid>和sgadef<sid>.dbf文件没有被删除。【注:这个文件最好不要删除,而是改名】

Oracle异机恢复

标签：