使用v$session_longops来监控RMAN备份进度

这次备份的数据库是个大块头，数据文件达到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> /