利用RMAN转移数据和EXP/IMP转移的实测比较

核心提示：由于工程需要经常将客户的现场数据导出到公司的开发环境中，随着客户现场数据量的不断增大，利用RMAN转移数据和EXP/IMP转移的实测比较，原先使用的导出导入的方法需要花费越来越长的时间，所以测试一下RMAN的效率，还是见仁见智吧，以下为测试中RMAN和导出导入使用的命令，验证是否能用恢复RMAN备份的方法来代替以往的E

　　由于工程需要经常将客户的现场数据导出到公司的开发环境中，随着客户现场数据量的不断增大，原先使用的导出导入的方法需要花费越来越长的时间，所以测试一下RMAN的效率，验证是否能用恢复RMAN备份的方法来代替以往的EXP/IMP方法。原本想过用传输表空间的方法，但是由于我们通常在创建数据库的时候就给业务所用的表空间创建了很大的数据文件，这样在传输表空间的copy数据文件的步骤上会花费很长的时间，所以还是决定测试一下RMAN了。
　　
　　测试目的：
　　实现对于JHJKREC用户的数据转移。
　　
　　在10.101.48.71机器上测试。
　　
　　测试环境：
　　P42.8G单CPU，1G内存，80G单硬盘，windows 2000 Server，Oracle817
　　
　　跟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