由于工程需要经常将客户的现场数据导出到公司的开发环境中，随着客户现场数据量的不断增大，原先
使用的导出导入的方法需要花费越来越长的时间，所以一下RMAN的效率，验证是否能用恢复RMAN备
份的方法来代替以往的EXP/IMP方法。原本想过用传输表空间的方法，但是由于我们通常在创建数据库的
时候就给业务所用的表空间创建了很大的数据文件，这样在传输表空间的copy数据文件的步骤上会花费
很长的时间，所以还是决定一下RMAN了。
测试目的： 实现对于JHJKREC用户的数据转移。
在10.101.48.71机器上测试。
测试环境： P42.8G单CPU，1G内存，80G单硬盘， 2000 Server，817
跟JHJK用户相关的数据文件的总共大小为：21.4G
其中JHJKREC用户的对象总共大小为：2.1G
1。RMAN作full备份，用时20分钟，生成文件大小5.47G
EXP作JHJKREC用户数据导出，用时2分20秒，生成文件大小546M
2。RMAN作数据恢复，用时23分钟（包括restore数据文件，recover数据库）
IMP作JHJKREC用户数据导入，用时55分钟
3。RMAN备份在非归档模式下需要关闭数据库然后启动数据库到mount状态
EXP在非归档模式下不需要关闭数据库，但是数据表本身是不一致的
结论： 利用RMAN备份的时间明显长于EXP的时间，备份出的文件也远大于EXP出的文件
但是恢复的时间却要少于IMP所需要的时间。
利用RMAN恢复，还需要备份控制文件，而且由于是非归档模式，还需要检查当前能够恢复到的最大SCN，然后在SQLPLUS中recover database until change scn，然后再alter database open resetlogs，整个操作比EXP/IMP繁琐，对于现场业务人员来说可能较为困难，所以使用RMAN还是使用导出导入作数据转移，还是见仁见智吧。
以下为测试中RMAN和导出导入使用的命令，基本上没有作任何优化。
RMAN的备份脚本：
@@connect.rcv
# Backup up database at full level
#
shutdown immediate;
startup mount;
run{
allocate channel d1 type disk;
set limit channel d1 kbytes 2097150;
backup full database
format 'E:\rman_bak\dbfull_%d_%s_%p_%t'
tag='dbfull';
release channel d1;
}
alter database open;
exit;
RMAN的恢复脚本：
@@connect.rcv
shutdown immediate;
startup mount;
run {
sql "alter session set nls_date_language=AMERICAN";
sql "alter session set nls_date_format=''yyyy-mm-dd hh24:mi:ss''";
set until time '2004-9-7 15:30:00';
allocate channel ch1 type disk;
restore database;
release channel ch1;
}
exit;
EXP的脚本：
userid=jhjkrec/jhjkrec
file=e:\rman_bak\jhjkrec.dmp
owner=jhjkrec
direct=n
compress=n
feedback=1000
IMP的脚本：
userid=jhjkrec/jhjkrec
file=e:\rman_bak\jhjkrec.dmp
ignore=y
fromuser=jhjkrec
touser=jhjkrec
feedback=1000
【责编:admin】
--------------------next---------------------
