这次备份的数据库是个大块头，数据文件达到10tb。 可是管理方只允许使用4个通道备份，直接扼杀了备份速度。通过glance命令查看cp
这次备份的数据库是个大块头，数据文件达到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 / 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> /