有时候需要将大的数据库发布到客户现场或转移机器时,不得不考虑在异机上恢复已经调整、测试好的库。 dumpdp 全备的方法虽然易用,但在处理对象、索引、空间的时候异常的出错,比如:见有些公司,建表、索引、对象...都是指定了 nologging,dumpdp恢复是默认是指定logging,dumpdp 也没有那么神说还要帮你去检测这些事情,结果一大堆的错误创建失败,几十个动动手改改无所谓,上百个伤不起。所以理想些还是选择 rman 备份恢复。
异机上恢复前准备一个全备或零级备份(也可以用增量备份,但你要把包括从零级备份以来的备份都准备齐全),介意备份,在服务端运行如下代码备份数据库:
run { allocate channel dev type disk; allocate channel dev1 type disk; backup incremental level 0 database format 'e:\backup\%d_%s_%U_%T.bkp' tag 'db_incr0'; backup archivelog all format 'E:\backup\arc_%d_%U_%T.arc' tag 'db_arc_all'; backup archivelog from time 'sysdate-2' tag 'db_arc_2days' format 'e:\backup\arc_%d_%U_2days_%T.arc'; backup current controlfile format 'e:\backup\%d_%U_contr_T.bkp' tag 'db_controlfile'; release channel dev; release channel dev1; }
以上脚本,首先进行一个零级的数据库备份,指定存储路径和标记,然后对当前数据库的归档日志进行全备,完成后在对2天以来的归档日志进行备份,保证有两份归档日志备份;最后备份当前的控制文件,为什么要备份控制文件,备份数据库的时候已经自动备份一次了而且还有恢复目录?根据我个人的经验,主要出于以下缘故:
1.如果有恢复目录,那么备份信息最终会被保存到恢复目录和控制文件,如果没有恢复目录,只保存到控制文件,而归档文件又是后备份的(还原先前备份的控制文件时后面的归档备份信息并未被保存),很大程度异机恢复要靠控制文件,这样会造成异机恢复需要归档时有备份但找不到用不了;
2.异机恢复是有可能有许多别的原因,装载控制文件后恢复目录也会有出错。
所以出于各方面因素考虑,我认为还是在数据库备份、归档日志备份结束相关信息写入控制文件后备份一个控制文件,异机恢复是用它恢复。
备份结束后,进行相关验证检查:
1. 验证数据库可恢复性: restore database validate;
2.查看备份的数据文件:
list backup of database; list backup of datafile 3;
3.查看备份归档日志:
3.1 查看所有备份归档日志:
list backup of archivelog all;
3.2 根据归档日志序列查看备份归档日志:
list backup of archivelog sequence 137;
3.3 查看某个序列到某个序列备份归档日志:
list backup of archivelog sequence between 137 and 200;
3.4 根据时间查看备份归档日志:
list backup of archivelog from time '2013-10-06 14:00:00'; list backup of archivelog from time 'sysdate-2';
查看小于等于指定时间的备份归档日志:
list backup of archivelog until time '2013-10-06 16:00:00';
3.5 根据SCN 查看备份归档日志:
list backup of archivelog from scn 407442698;
查看小于等于指定SCN的备份归档日志:
list backup of archivelog until scn 407442698;
4. 查看备份的控制文件:
list backup of controlfile;
一切就绪,拷贝备份的数据文件、归档文件和pfile文件(手工创建一个,到别的机器上有可能要修改相应路径)到恢复的机器上相同路径下;
异机上恢复数据库:
1.恢复前要建立一个实例,可以用现有的(同一机器上可以有多个同名数据库,但只能有一个同名实例)
windows 平台dos下创建实例: oradim -new -sid orcl
2.根据机器环境修改手工创建的pfile(oracle环境路径、控制文件路径、诊断日志文件....),然后以sys用户进入sqlplus用修改后的pfile文件创建spfile 文件;
create spfile from pfile='dir\pfile.ora';
3.设置环境变量,启动数据库至 nomount 状态,进入 rman 管理器:
rman target /
4.还原控制文件: restore controlfile from 'e:\backup\....' to 'dir';
to 'dir' 未指定是默认使用 spfile上control_files 指定的路径;
5.装载控制文件: alter database mount; (装载控制文件时如果指定数据库名,则指定的数据库名要和spfile 文件中的db_name相同)
6.恢复数据库:
run { allocate channel dev type disk; allocate channel dev1 type disk; set newname for datafile 1 to 'e:\nsoa\SYSTEM01.dbf'; set newname for datafile 2 to 'e:\nsoa\SYSAUX01.DBF'; set newname for datafile 3 to 'e:\nsoa\TBS1.dbf'; set newname for datafile 4 to 'e:\nsoa\USERS01.DBF'; set newname for datafile 10 to 'F:\nsoa\FRDC_TABLESPACE.DBF'; set newname for datafile 11 to 'F:\nsoa\UNDOTBS02.DBF'; set newname for datafile 12 to 'F:\nsoa\UNDOTBS01.DBF'; set newname for datafile 15 to 'F:\nsoa\SYWU.DBF'; restore database; switch datafile all; recover database; sql 'alter database open resetlogs'; release channel dev; release channel dev1; }
对于新的环境,物理路径与控制文件中数据文件的路径相同时无需进行任何操作,可 restore;
如果数据文件路径需要变更,使用 set newname for datafile 1 to 'dir' 方式重新定义,switch datafile all 的意思是切换控制文件中存储的信息(向控制文件表明:我已经重新定义了数据文件路径,请帮我更新过来);switch datafile all 和restore database 的位置不能写错,一定要遵循先 restore 后switch;
recover database 命令会根据当前 restore 后的数据库状态,确认是否需要恢复,然后从控制文件存储的备份归档日志文件中恢复相应归档日志到相应路径下(默认为spfile 中指定的db_recovery_file_dest 路径下)恢复数据库,恢复完成后自动删除该文件;该步骤有可能会失败,需要备份后数据库运行的当前未归档日志。
sql 'alter database open resetlogs' 命令向数据库发出打开的请求(这里有个问题,如果控制文件中日志文件路径在新环境中不存在,打开和新建会失败);处理方法:
1.查询出当前控制文件中记录的日志文件路径: select group#,member from v$logfile;
2.重命名日志文件路径: alter database rename file '...' to '....';
3.执行alter database open resetlogs 打开数据库;
打开数据后执行相关表空间、数据文件...检测,进行一个数据库全备。