Heim  >  Artikel  >  Datenbank  >  使用v$session_longops来监控RMAN备份进度

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

WBOY
WBOYOriginal
2016-06-07 16:45:051305Durchsuche

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

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn