生产机的OS宕机，rman灾难恢复

朋友的数据库系统出问题了，以下是他的解决过程，对我学习RMAN很有帮助：

以下是一个案例：

生产机的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:/oracle/rman/db_%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:/oracle/rman/initcnpl.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:/oracle/rman/initcnpl.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:/oracle/oradata/cnpl)
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:/ORACLE/ORADATA/CNPL/CONTROL01.CTL
通道 ORA_DISK_1: 已恢复备份段 1
段 handle=C:/ORACLE/RMAN/DB_CNPL_1_1_555085654 tag=TAG20050408T143003 params=NUL
L
通道 ORA_DISK_1: 恢复完成
正在复制控制文件
输出文件名=C:/ORACLE/ORADATA/CNPL/CONTROL01.CTL
输出文件名=C:/ORACLE/ORADATA/CNPL/CONTROL02.CTL
输出文件名=C:/ORACLE/ORADATA/CNPL/CONTROL03.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:/ORACLE/ORADATA/CNPL/SYSTEM01.DBF
正将数据文件00002恢复到C:/ORACLE/ORADATA/CNPL/UNDOTBS01.DBF
正将数据文件00003恢复到C:/ORACLE/ORADATA/CNPL/CWMLITE01.DBF
正将数据文件00004恢复到C:/ORACLE/ORADATA/CNPL/DRSYS01.DBF
正将数据文件00005恢复到C:/ORACLE/ORADATA/CNPL/EXAMPLE01.DBF
正将数据文件00006恢复到C:/ORACLE/ORADATA/CNPL/INDX01.DBF
正将数据文件00007恢复到C:/ORACLE/ORADATA/CNPL/ODM01.DBF
正将数据文件00008恢复到C:/ORACLE/ORADATA/CNPL/TOOLS01.DBF
正将数据文件00009恢复到C:/ORACLE/ORADATA/CNPL/USERS01.DBF
正将数据文件00010恢复到C:/ORACLE/ORADATA/CNPL/XDB01.DBF
通道 ORA_DISK_1: 已恢复备份段 1
段 handle=C:/ORACLE/RMAN/DB_CNPL_8_1_554919188 tag=TAG20050406T161533 params=NUL
L
通道 ORA_DISK_1: 已恢复备份段 2
段 handle=C:/ORACLE/RMAN/DB_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:/ORACLE/ORA92/RDBMS/ARC00012.001 存在于磁盘
上
存档日志文件名 =C:/ORACLE/ORA92/RDBMS/ARC00012.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:/ORACLE/ORADATA/CNPL/REDO02.LOG 存在于磁盘上
存档日志线程 1 序列 4 已作为文件 C:/ORACLE/ORADATA/CNPL/REDO03.LOG 存在于磁盘上
存档日志线程 1 序列 5 已作为文件 C:/ORACLE/ORADATA/CNPL/REDO01.LOG 存在于磁盘上
存档日志文件名 =C:/ORACLE/ORADATA/CNPL/REDO02.LOG 线程 =1 序列 =3
存档日志文件名 =C:/ORACLE/ORADATA/CNPL/REDO03.LOG 线程 =1 序列 =4
存档日志文件名 =C:/ORACLE/ORADATA/CNPL/REDO01.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宕机的恢愎策略。

针对朋友的案例我提了一些建议：

我觉得应该修改一下全库备份脚本，加上备份归档日志的语句：

RMAN> run{
2> allocate channel d1 type disk maxpiecesize=500m;
3> backup full database
4> format 'c:/oracle/rman/db_%d_%s_%p_%t';
5> sql 'alter system archive log current';
6> backup filesperset 3 archivelog all delete input;
7> release channel d1;
8> }

这样即使没有原来REDOLOG的备份，利用归档日志，也是可以恢复数据库的。