这次备份的数据库是个大块头，数据文件达到10TB。 可是管理方只允许使用4个通道备份，直接扼杀了备份速度。通过glance命令查看cpu，磁盘、内存的压力都不高，即使开8个通道或是16个通道也没问题。该主机是双节点RAC，每台主机配有32个cpu，并且是在周末业务较低的时候备份。
这4个通道的限制就如同一辆法拉利挂着一档行驶在高速公路上，这要多久才能跑完...
1，备份之前了解一下目标数据库的状态
看看dba_segments,实际数据块的总大小为5TB
SQL> select sum(bytes)/1024/1024/1024 GB from dba_segments;
GB
----------
5287.02454
看看dba_data_files，数据文件总大小大约为10TB
SQL> select sum(bytes)/1024/1024/1024 GB from dba_data_files;
GB
----------
9402.70592
临时备份路径为/orabak,磁盘空间大小为为9TB
bdf
/dev/vx/dsk/bakdg/bakvol
9961472000 634128 9883018840 0% /orabak
2，这是一个普通压缩方式的数据库全备脚本，包含控制文件、参数文件和归档日志文件。最突出的部分是这4通道，让人痛不欲生。
vi backup.cmd
rman target / <<EOF
run{
allocate channel c1 device type disk maxpiecesize = 20G;
allocate channel c2 device type disk maxpiecesize = 20G;
allocate channel c3 device type disk maxpiecesize = 20G;
allocate channel c4 device type disk maxpiecesize = 20G;
backup tag 'sh_db_full' as compressed backupset format '/orabak/sh_db_full_%U' database
include current controlfile;
sql 'alter system archive log current';
backup tag 'sh_arch' as compressed backupset archivelog all format '/orabak/sh_arch_%U';
release channel c1;
release channel c2;
release channel c3;
release channel c4;
}
EOF
3，在Oracle用户下授权备份脚本
chmod 755 backup.cmd
4，在后台执行备份脚本
nohup backup.cmd &
5，通过nohup.out日志来监控rman备份输出
备份时间为2014/10/12日 16:45
tail -f nohup.out
6，通过glance命令来观察备份时的系统状态，发现CPU的使用率只有23%，磁盘压力只有15%，4个通道所占用的cpu分别为100%左右。其实我们的可以资源非常多，却不允许使用。
Glance 11.13.007 16:47:43 jccmsdb1 ia64 Current Avg High
------------------------------------------------------------------------------------------------------------------------------------
CPU Util SSN NU UW W | 23% 23% 33%
Disk Util F F | 15% 11% 30%
Mem Util S SU UF F | 70% 70% 70%
Networkil U UR R | 54% 54% 54%
------------------------------------------------------------------------------------------------------------------------------------
PROCESS LIST Users= 9
User CPU % Thrd Disk Memory Block
Process Name PID Name (2400% max) Cnt IO rate RSS VSS On
------------------------------------------------------------------------------------------------------------------------------------
oraclesgpmdb 12326 oracle 100 1 51.9 92.0mb 104mb PRI
oraclesgpmdb 12280 oracle 100 1 54.2 92.0mb 104mb PRI
oraclesgpmdb 12281 oracle 99.6 1 54.4 92.0mb 104mb PRI
oraclesgpmdb 12304 oracle 99.4 1 57.6 92.0mb 104mb PRI
ora_m000_sgp 28333 oracle 15.6 1 0.0 131mb 163mb PRI
perl 18601 root 9.1 1 0.0 712kb 724kb died
ora_dia0_sgp 6943 oracle 7.6 1 0.0 134mb 136mb SLEEP
java 9109 root 7.4 41 0.7 305mb 759mb SLEEP
df 18605 root 6.2 1 0.0 84kb 160kb died
glance 19308 quest 6.0 1 0.0 20.1mb 23.9mb STRMS
ocssd.bin 16787 grid 5.1 19 2.8 138mb 138mb SLEEP
vxfsd 342 root 4.5 217 117.3 79.1mb 89.0mb SYSTM
7，通过v$session_longops视图查看rman备份的进度，这部分也是本片博客要阐述的重点。
SQL> /