此次复制的生产库数文件为9.18TB，实际分配的数据大小为5.16TB，使用RMAN压缩备份后为1.1TB。
复制端数据库采用单实例ASM存储方式管理，Oracle数据库版本为11.2.0.4. 数据文件目录为+DATA，14.5TB，归档日志目录为+ARCH，2TB。
生产库数据文件大小
SQL> select sum(bytes)/1024/1024/1024 GB from dba_segments;
GB
----------
5287.02454
生产库实际分配的大小
SQL> select sum(bytes)/1024/1024/1024 GB from dba_data_files;
GB
----------
9402.70592
注意事项一： 避免set newname脚本中出现同名文件
在rman中使用set newname时候为了保持文件名和生产库一致，可以采用手工命名的方式。例如：
set newname for datafile 1 to ‘+DATA/cmsdb/datafile/system01.dbf’;
这个方式出现了一个潜在的隐患，如果生产库中存在相同名字的数据文件存放在不同的目录中，在编写脚本时候容易出现重名的情况，导致RMAN restore出错。
select name from v$datafile where name like ‘%DATA_P008.dbf%’;
/sgpmdb/oradata/u01/DATA_P008.dbf
/sgpmdb/oradata/u06/DATA_P008.dbf
当我采用vi编辑命令将目录/sgpmdb/oradata/u01 统一改成+DATA/sgpmdb/datafile 就会自己创造出重名的文件。在好几百行的脚本中很难一眼看出这个问题。
:%s#/sgpmdb/oradata/u01/#+DATA/cmsdb/datafile/#g
run{
...
set newname for datafile 1 to '+DATA/cmsdb/datafile/DATA_P008.dbf';
...
set newname for datafile 2 to '+DATA/cmsdb/datafile/DATA_P008.dbf';
…
}
执行RMAN restore 错误信息如下:
ORA-19504: failed to create file “+DATA/cmsdb/datafile/data_p008.dbf”
ORA-17502: ksfdcre:4 Failed to create file +DATA/cmsdb/datafile/data_p008.dbf
ORA-15005: name “cmsdb/datafile/data_p008.dbf” is already used by an existing alias
所以还是建议采用如下的方式让oracle来定义alias，保持文件名唯一。
run{
set newname for datafile 1 to '+DATA';
set newname for datafile 2 to '+DATA';
set newname for datafile 3 to '+DATA';
…...
}
注意事项二： 后台执行nohup的进程问题
vi编辑好RMAN脚本后，建议使用nohup命令在后台执行，避免执行过程中被以外干扰。
nohup ./rman_scripts.cmd &
rman在后台执行时，屏幕没有输出，可以通过tail -f ./nohup.out的方式来监控rman输出。
也可以通过ps -ef | grep 的方式来观察程序是否在后台执行。这里需要注意的是 ps -ef | grep 后要输入的是什么？
容易犯的错误是 ps -ef | grep nohup
这个命令是没有返回结果的。如果错误的认为刚刚输入的命令没有起作用，而再次执行 nohup. /rman_scripts.cmd的话，悲剧产生了。该脚本被执行了2次！
如果是restore命令的话，并且采用了set newname for datafile 1 to '+DATA’;的写法数，+DATA磁盘组中就会存在两份数据文件，最终将磁盘空间撑爆。
正确的用法是 ps -ef | grep rman_scripts.cmd
以上总结都是在此次项目中出现的问题。在漫长的数据库恢复过程中，每一个错误都会耽误大量的时间，一定要小心谨慎。
在CentOS 6.4下安装Oracle 11gR2(x64)
Oracle 11gR2 在VMWare虚拟机中安装步骤
Debian 下 安装 Oracle 11g XE R2
：