备份软件对oracle数据库进行恢复（BE对linux下oracle恢复)

做Recovery需要什么数据：
1、FULL CLOSED备份 shutdown数据库（不要用shutdown abort强行关闭），实施一个文件级备份，备份全部的Oracle相关文件，包括Windows系统文件，系统状态和Oracle程序文件和数据文件等内容。 这个冷备份对于快速恢复Oracle数据库系统非常要害，假如没有它，系统被破坏后只能重新安装再恢复，这要比直接恢复冷备份慢得多，也更复杂。 每当数据库或表单的物理结构或逻辑结构有变化时都应该重新创建这个冷备份。
2. FULL ONLINE备份 这个备份要通过Backup Exec Agent for Oracle Server来完成，要备份全部表空间，归档日志和控制文件，通过这种方式备份，Oracle会将所有缓存内容写入文件，将online redo log做归档，所以数据库备份中包含的是备份时数据库的即时点信息，完整而且有效。以后做恢复时，可以恢复到最后一次FULL ONLINE备份的状态。

恢复过程：
1. 重新安装Windows系统和Remote Agent for Windows Server，为恢复Oracle服务器预备环境。
2. 恢复最后一次FULL CLOSED备份，重新启动计算机。 此时Windows系统，Oracle数据库系统都是完整的，只是Oracle数据库中可能不是最新的数据。Backup Exec Agent for Oracle Server也不用重新安装了。
3. 用SQLPlus用SYS以sysdba身份连接到数据库系统，关闭数据库。 shutdown immediate < enter >
4. 通过介质服务器恢复最新的FULL ONLINE备份，恢复作业属性的高级选项中，确保选中了“Restore over Existing files（覆盖现存文件）” 选项。 要想成功的恢复数据库，在最后一次FULL CLOSED备份之后的所有redo log必须都已经成功归档并备份。少了哪一个，数据库就无法恢复到最后的FULL ONLI NE备份时的状态。 通过Oracle的alert log可以看到数据库的恢复需要哪些归档日志，以及你应该把它们恢复到什么位置。
5. 恢复完成后，用SYS用户以sysdba身份连接到数据库，将数据库加载到mount阶段： startup mount < enter >
6. 数据库mount完成后，执行recover过程： recover database using backup controlfile < enter > 数据库会提示你需要哪些日志： ORA-00279: Change 36579 generated at needed for thread 1 ORA-00289: Suggestion : \Oracle_Home\Oradata\\%SID%T00036579.ARC ORA-00280: {=Suggested filename AUTO FROM logsource CANCEL} 最简单的方法是选自动恢复： auto < enter > 系统会在init.ora文件中定义的位置上查找所有必需的日志并依次应用它们，最后一个要应用的日志是online redo log，实际上它并不包括任何的transaction，只有一个SCN，可以略过，但是自动恢复过程会因为找不到相应的文件而报错： ORA-00308: cannot open archived log E:\ORACLE\ORADATA\KIMSTAD\ARCHIVE\KIMSTADT00036949.ARC ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot find the file specified. 为此输入以下命令（until cancel参数使我们可以在需要的时候中止恢复过程）： recover database until cancel using backup controlfile 这样在数据库恢复的最后阶段再次提示前面的错误时，我们就可以中止恢复过程：cancel < enter > 这时除了最后一个online redo log以外，所有的commit transaction都已经提交到数据库之中了，完成后会显示：
Media recovery canceled 实际上恢复过程已经正常完成了。 最后是打开数据库并同步日志序列号：
    alter database open resetlogs < enter >
至此，Oracle数据库被成功恢复到最后一次Full Online备份。 说明：Oracle 8i可以用internal账号完成DBA操作。9i取消了internal账号，SYS账号代替它了。为了以DBA身份登录，启动SQL Plus时应该加nolog参数，进入之后再登录，connect username/passWord as sysdba。

实际BE恢复过程备份服务器版本

mount 状态对应 BE的数据库状态显示为“已装入”

咨询了华赛孙工，
他说
抛开BE不谈，
进行rman 恢复的时候，如果在线联机日志不存在(redo*.log)，restore 那一块不会出错，
但是用rman recover数据库的的时候，
rman会去找一个不存在的归档日志，最后报找不到而出错。
此时如果想打开数据库，
只有手工 alter database open resetlogs;来打开数据库。

那么，
当用华赛的BE进行数据库恢复时，
如果是灾难恢复，当然就没有联机日志,
那么在进行恢复的时候，
华赛的BE就会报错，
说恢复失败，（其实就是因为找不到一个不存在的归档日志），
所以这个时候只需要手动打开rman,选择 alter database open resetlogs就可以了。

我的疑问：
没有联机日志，进行恢复的时候，BE就会报那个错误吗？
为什么软件里面知道这个错误跳不过，不采用个办法让客户认为备份是成功的？
而且之前的还原曾经报成功过，
也是用的灾难恢复的模式，
所以我就有疑问了
我想得到一个官方的书面解释。

利用BE图形界面恢复尝试

\

1.模拟故障，在linux-2上把数据库oracssf删除。
2.灾难恢复，重建数据库，建同样的sid名
3.命令行方式恢复控制文件

RMAN> startup nomount
RMAN>set DBID 1443202165

RMAN> run {
allocate channel ch0 type sbt;
send "NBBSA_SOURCE_MACHINE_NAME=linux-1";
restore controlfile from 'BE_2hk9dmvq_1_1';
release channel ch0;
}

实际BE恢复过程命令行版本

如果华赛BE显示mount 状态不对的时候
，需要手工来进行rman恢复，
应该采用下面的步骤，
只需要用户了解两个参数：备份源客名称（此处为linux-1）
备份介质名称（此处为BE_08k8umie_1_1），这些都可以从BE中找到。

模拟灾难，把库删除并重建。
直接用命令行恢复，
此时BE只是作为一个磁带库起到存储之前rman文件的作用。
2.先利用命令行进行全库恢复。

进行灾难恢复（省去重装操作系统和重装oracle软件，直接用dbca创建同sid的数据库）
省略BE agent的认证配置。
在备份服务器上认证以下，看备份服务器和目标的服务器之间通信情况是否正常。
通信是正常的。
在备份服务器上寻找文件类似“'BE_08k8umie_1_1”

找到了对应的文件名;
对应的dbid为 1443202165
对应的介质为 BE_2hk9dmvq_1_1

先恢复控制文件，命令如下:

RMAN> startup nomount
RMAN>set DBID 1443202165

RMAN> run {
allocate channel ch0 type sbt;
send "NBBSA_SOURCE_MACHINE_NAME=linux-1";
restore controlfile from 'BE_2hk9dmvq_1_1';
release channel ch0;
}

RMAN> alter database mount;

RMAN> run {
allocate channel ch0 type sbt;
send "NBBSA_SOURCE_MACHINE_NAME=linux-1";
restore database;
release channel ch0;
}

RMAN> run {
allocate channel ch0 type sbt;
send "NBBSA_SOURCE_MACHINE_NAME=linux-1";
recover database;
release channel ch0;
}

alter database open resetlogs;

恢复过程有一个报错，内容如下:

RMAN> run {
allocate channel ch0 type sbt;
send "NBBSA_SOURCE_MACHINE_NAME=linux-1";
recover database;
release channel ch0;
}2> 3> 4> 5> 6>

allocated channel: ch0
channel ch0: sid=156 devtype=SBT_TAPE
channel ch0: Symantec/BackupExec/1.1.0

sent command to channel: ch0

Starting recover at 08-MAR-09

starting media recovery

starting up daemon
channel ch0: starting archive log restore to default destination
channel ch0: restoring archive log
archive log thread=1 sequence=18
channel ch0: reading from backup piece BE_2gk9dmvi_1_1
starting up daemon
channel ch0: restored backup piece 1
piece handle=BE_2gk9dmvi_1_1 tag=TAG20090308T154906
channel ch0: restore complete, elapsed time: 00:00:15
archive log filename=/u01/app/oracle/flash_recovery_area/ORACSSF/archivelog/2009_03_08/o1_mf_1_18_4v70s2pj_.arc thread=1 sequence=18
channel default: deleting archive log(s)
archive log filename=/u01/app/oracle/flash_recovery_area/ORACSSF/archivelog/2009_03_08/o1_mf_1_18_4v70s2pj_.arc recid=33 stamp=680978082
unable to find archive log
archive log thread=1 sequence=19
released channel: ch0
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/08/2009 16:34:52
RMAN-06054: media recovery requesting unknown log: thread 1 seq 19 lowscn 60500458

根据“BE备份牛人的文档”，上面红色的报警是正常的，

进入sqlplus
alter database open resetlogs;
成功恢复。

总结，当进行恢复(restore)的时候，从备份服务器上查看，发现备份服务器处于正在运行备份作业的状态上。