oracle恢复init文件,详解NBU异机恢复ORACLE数据库-CSDN博客

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;

目的是避免有业务测数据未被归档

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;

3.16 启动侦听

lsnrctl start;

3.17 查看报警日志

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

3.18 通知业务侧进行测试

--The end of Beijing