详解NBU异机恢复ORACLE数据库

1.概述
1.1源库和目标库都为单机
1.2都是使用的裸设备，且目标库已经存在过

2.源库准备情况：
2.1存在近期的一个全库（level 0 ) 备份
2.2存在近期的一份归档备份
2.3存在近期的一个控制文件备份
2.4可通过list命令确认备份时间，备份集及备份集状态
2.5可打开控制文件的自动备份
2.5可创建一个pfile文件作为备用

3.目标库准备
3.1比对目标库和源库的所有裸设备个数和名称（建议名称也相同）
  select name from v$datafile union all
  select name from v$tempfile union all
  select name from v$controlfile union all
  select member name from v$logfile;
3.2先关闭数据库（如果是Open或者mount)
shutdown immediate;

3.3删除原来的参数文件（init和spfile)
  改名或者删除都可
  mv inittest.ora inittest.ora.bak
  mv spfiletest.ora spfiletest.ora.bak

3.4删除源口令文件
  删除原口令文件，新建或者拷贝原来的都可

3.5 dd 所有的在线日志
  如果不dd ，则报错误ORA-19698
  ORA-19698: %s is from different database: id=string, db_name=string Cause: Catalog failed becasuse the database id in file header does not match the one in control file.

  大概意思是redo 里面的控制文件id和控制文件的dbid 不匹配
 
  dd if=/dev/zero f=/dev/rlog1 bs=1024 count=1000
  ..
  dd if=/dev/zero f=/dev/rlogN bs=1024 count=1000
 
3.6设置oracle的环境变量，特别是确认ORACLE_SID的值和源库相同
export ORACLE_SID=test

3.7还原spfile
rman target/
rman>startup nomount
rman>run{
ALLOCATE CHANNELT CH00 TYPE 'SBT_TAPE';
SEND 'NB_ORA_SERV=NBU_SERVE,NB_ORA_CLIENT=NBU_CLIENT';
restore spfile from '03nnnocg_1_1';
release channel CH00;
}

有2点说明：
1.SEND 参数，需要和源库备份时的参数相同
2.'03nnnocg_1_1' 为包含spfile的备份片，可从源库list backup of spfile;查看哪个备份片包含spfile

3.8 核对初始化文件

sql>shutdown immediate
sql>startup nomount
sq>create pfile from spfile;
核对文件看看是否需要调整的，如果调整，则需要再跟军调整后的文件创建个新的spfile文件

3.9 还原控制文件
RMAN>startup nomount;
rman>set dbid=nnnnnn
rman>run{
ALLOCATE CHANNELT CH00 TYPE 'SBT_TAPE';
SEND 'NB_ORA_SERV=NBU_SERVE,NB_ORA_CLIENT=NBU_CLIENT';
restore controlfile from '03nnnocg_1_1';
release channel CH00;
}

3.10 mount 控制文件
rman>alter database mount;

3.11 restore database
rman>
run{
ALLOCATE CHANNELT CH00 TYPE 'SBT_TAPE';
ALLOCATE CHANNELT CH01 TYPE 'SBT_TAPE';
SEND 'NB_ORA_SERV=NBU_SERVE,NB_ORA_CLIENT=NBU_CLIENT';
restore datatabase;
release channel CH00;
release channel CH01;
}

3.12 recover database
run{
ALLOCATE CHANNELT CH00 TYPE 'SBT_TAPE';

SEND 'NB_ORA_SERV=NBU_SERVE,NB_ORA_CLIENT=NBU_CLIENT';
recover datatabase;
release channel CH00;
}

说明：上述recover操作后，会在应用完最后一个归档日志后，直接报错出来
RMAN-00571 ..
RMAN-00569 ..
RMAN-00571 ..
RMAN-03002 ..
RMAN-06054：media recovery requesting unknow log:thread 1 seq 10 lowscn 166250;

这里的seq 10 是目标库未找到的，即下一个需要seq 10 的归档日志，但是带库备份集中不存在，所以只能终止退出。

如果只是测试，可以基于时间点，基于scn或者基于sequence 的方式来恢复，可以正常退出而不报错，但是原理是相同的，
个人更倾向于使用基于sequence 的方式来恢复，如下：
recover database until sequence 10;

这个10 ，在recover时并不被应用，而是应用到它前面那个号即9。

3.13 继续recover
如果是对于生产环境的迁移，可以继续采取这个小节的方法，在有严格的时间窗口限制时，这个方法还是比较可靠和可行的
3.13.1 在源库人为切换日志N次(日志组数+1）
alter system archive log current;
..
alter system archive log current;

目的是避免有业务测数据未被归档
3.13.2 将10开始的之后所有的归档拷贝到目标库归档路径下

3.13.3 继续恢复
sql>recover database using backup controlfile until cancel;
回车后，可以看到多行信息，最关键的是说下一个需要的日志序列号为10，如果确认10已经被拷贝过来了，可直接回车,
当应用到最后一个时，就直接异常退出了，这时的异常并不是问题。
至此恢复可以认为告一段落了。

3.14 open 数据库
sql>alter database open resetlogs;

3.15 处理临时表空间

先删除原临时文件
alter database tempfile 'temp1' drop;
alter database tempfile 'temp2' drop;

select name from v$tempfile;

alter tablespace temp add tempfile 'temp1' size 1000m reuse;
alter tablespace temp add tempfile 'temp1' size 2000m reuse;

3.16 日志切换
alter system switch logfile;
alter system switch logfile;
alter system switch logfile;

3.16 启动侦听
lsnrctl start;

3.17 查看报警日志

此操作在整个过程中建议持续输出观察

3.18 通知业务侧进行测试

 

--The end of Beijing

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/388619/viewspace-750469/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/388619/viewspace-750469/