场景描述：
生产机因为病毒感染或被恶性攻击现在无法启动了，辛好前几天晚用rman(catalog方式)做了一次全库备份，
备份文件及备份后的所产生的规档日志都在别一台机上保存着，请问在重装OS及oracle后该如何恢复？
目前catalog数据库是正常工作的。
生产机的OS宕机，rman灾难恢愎(原创)

本人在学习rman过程中，突然碰到一个千载难逢的"好机会"来学习rman,因为是生产机，所以以下操作目标是用最短的时间来恢愎数据，所有操作没有特别的研究为什么，不过还是在此抛砖引玉，希望对rman初学者有个参考的价值。

场景描述：
生产机因为病毒感染或被恶性攻击现在无法启动了，辛好前几天晚用rman(catalog方式)做了一次全库备份，
备份文件及备份后的所产生的规档日志都在别一台机上保存着，请问在重装OS及oracle后该如何恢复？
目前catalog数据库是正常工作的。

解决方案：
我的全库备份脚本如下：
RMAN> run{
2> allocate channel d1 type disk maxpiecesize=500m;
3> backup full database
4> format 'c:oraclermandb_%d_%s_%p_%t';
5> release channel d1;
6> }


1.查看了一下原因目标库的DBID：
C:>sqlplus rman/rman@rman

SQL*Plus: Release 9.2.0.1.0 - Production on 星期四 4月 7 14:26:57 2005

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

连接到:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production

SQL> select * from db;

DB_KEY DB_ID HIGH_CONF_RECID LAST_KCCDIVTS CURR_DBINC_KEY
---------- ---------- --------------- ------------- --------------
45 1729098935 0 554810295 46


2.设置DBID
C:>rman

恢复管理器: 版本9.2.0.1.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

RMAN> set dbid 1729098935

正在执行命令: SET DBID
3.在新安装的机器上注册实例并启动到nomount(原来备份过pfile)
C:>oradim -new -sid cnpl -pfile c:oraclermaninitcnpl.ora -intpwd cnpl515

4.启动侦听，配制tnsname.ora
C:>sqlplus "sys/cnpl515@cnpl as sysdba"

SQL*Plus: Release 9.2.0.1.0 - Production on 4 8 14:43:06 2005

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

已连接到空闲例程
SQL> startup nomount pfile=c:oraclermaninitcnpl.ora (pfile文件可以随便写一个，或把原来那个copy回来再用，但一定要把规档的那几行参数注销掉)
ORACLE
例程已启动
Total System Global Area 135338868 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes

5.回到rman恢复controlfile
(这步要注意，一定要在新机器上创建与原来一模一样的目录，rman不会自动创建目录的,
本例为c:oracleoradatacnpl)
C:>rman catalog rman/rman@rman

恢复管理器: 版本9.2.0.1.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

连接到恢复目录数据库

RMAN> set dbid 1729098935

正在执行命令: SET DBID

RMAN> connect target sys/cnpl515@cnpltsd

连接到目标数据库: CNPL（未安装）

RMAN> restore controlfile;

启动 restore 于 08-4月 -05

分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=10 devtype=DISK
通道 ORA_DISK_1: 正在开始恢复数据文件备份集
通道 ORA_DISK_1: 正在恢复控制文件
输出文件名=C:ORACLEORADATACNPLCONTROL01.CTL
通道 ORA_DISK_1: 已恢复备份段 1
段 handle=C:ORACLERMANDB_CNPL_1_1_555085654 tag=TAG20050408T143003 params=NUL
L
通道 ORA_DISK_1: 恢复完成
正在复制控制文件
输出文件名=C:ORACLEORADATACNPLCONTROL01.CTL
输出文件名=C:ORACLEORADATACNPLCONTROL02.CTL
输出文件名=C:ORACLEORADATACNPLCONTROL03.CTL
完成 restore 于 08-4月 -05

RMAN>

6.到新机器上启动新数据库到mount
SQL>
SQL> alter database mount;

SQL>
7.回到rman,进行restore database;

RMAN> restore database;

启动 restore 于 08-4月 -05

分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=12 devtype=DISK
通道 ORA_DISK_1: 正在开始恢复数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集恢复的数据文件
正将数据文件00001恢复到C:ORACLEORADATACNPLSYSTEM01.DBF
正将数据文件00002恢复到C:ORACLEORADATACNPLUNDOTBS01.DBF
正将数据文件00003恢复到C:ORACLEORADATACNPLCWMLITE01.DBF
正将数据文件00004恢复到C:ORACLEORADATACNPLDRSYS01.DBF
正将数据文件00005恢复到C:ORACLEORADATACNPLEXAMPLE01.DBF
正将数据文件00006恢复到C:ORACLEORADATACNPLINDX01.DBF
正将数据文件00007恢复到C:ORACLEORADATACNPLODM01.DBF
正将数据文件00008恢复到C:ORACLEORADATACNPLTOOLS01.DBF
正将数据文件00009恢复到C:ORACLEORADATACNPLUSERS01.DBF
正将数据文件00010恢复到C:ORACLEORADATACNPLXDB01.DBF
通道 ORA_DISK_1: 已恢复备份段 1
段 handle=C:ORACLERMANDB_CNPL_8_1_554919188 tag=TAG20050406T161533 params=NUL
L
通道 ORA_DISK_1: 已恢复备份段 2
段 handle=C:ORACLERMANDB_CNPL_8_2_554919188 tag=TAG20050406T161533 params=NUL
L
通道 ORA_DISK_1: 恢复完成
完成 restore 于 08-4月 -05

8.进行recover 操作

RMAN> recover database;

启动 recover 于 08-4月 -05
使用通道 ORA_DISK_1

正在开始介质的恢复

存档日志线程 1 序列 12 已作为文件 C:ORACLEORA92RDBMSARC00012.001 存在于磁盘
上
存档日志文件名 =C:ORACLEORA92RDBMSARC00012.001 线程 =1 序列 =12
无法找到存档日志
存档日志线程 =1 序列=13
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 04/08/2005 09:11:33
RMAN-06054: media recovery requesting unknown log: thread 1 scn 523585

出错了，偿试把原来的REDO02.LOG,REDO01.LOG,REDO03.LOG copy回新建的实例的目录下，
再进行recover 操作,结果可以成功recover。
RMAN> recover database;

启动 recover 于 08-4月 -05
使用通道 ORA_DISK_1

正在开始介质的恢复

存档日志线程 1 序列 3 已作为文件 C:ORACLEORADATACNPLREDO02.LOG 存在于磁盘上
存档日志线程 1 序列 4 已作为文件 C:ORACLEORADATACNPLREDO03.LOG 存在于磁盘上
存档日志线程 1 序列 5 已作为文件 C:ORACLEORADATACNPLREDO01.LOG 存在于磁盘上
存档日志文件名 =C:ORACLEORADATACNPLREDO02.LOG 线程 =1 序列 =3
存档日志文件名 =C:ORACLEORADATACNPLREDO03.LOG 线程 =1 序列 =4
存档日志文件名 =C:ORACLEORADATACNPLREDO01.LOG 线程 =1 序列 =5
完成介质的恢复
完成 recover 于 08-4月 -05

RMAN> run{
2> sql 'alter database open resetlogs';
3> }

sql 语句: alter database open resetlogs
RMAN>
RMAN>
9.验证数据
结果当然是令人满意的,所有数据全部完成恢愎。

10.赶紧再做一次全库备份，修改为归档模式，再次投入运营。

后记：所有操作都是在windowns 2000 server平台，oracle9.2.0.1上进行的，不知最后一步进行redo物理copy是否跨平台，
因环境所限无法测试，另外，有没有好的办法可以不进行这种redo的物理copy.因为，这种OS宕机的几率
还是存在的，哪位大虾能提供更完善的应对这种OS宕机的恢愎策略。

您可以按照以下步骤引用本文.本站收到您的引用通知后, 将自动链接您的文章, 以方便别人阅览 .

1. 启动您自己的博客管理页面, 并进入发表新文章的画面, 输入文章的内容. (如果您是ITPUB的博客请点这里.)

2. 复制下面虚线框里的连接字串, 把它们粘贴到您的文章中, 按照您的喜好修改一下表示文字.

3. 确认您选择了"发送引用通知"的选项.

4. 发表您的文章.

好啦, 您的文章就可以被自动链接到本站啦.