使用v$session_longops來監控rman備份進度
這次備份的資料庫是個大塊頭，資料檔案達到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> /
SID SERIAL# OPNAME TARGET_DESC HOURS CONTEXT SOFAR TOTALWORK %_complete
---------- ---------- ----------------------------------- --------------- ---------- ---------- ---------- ---------- ----------
6440 52989 RMAN: full datafile backup Set Count 8.30555556 1 35966318 137179774 26.22
6050 62853 RMAN: full datafile backup Set Count 6.25861111 1 43865710 136921086 32.04
3058 52919 RMAN: full datafile backup Set Count 8.01722222 1 36874224 137048704 26.91
1548 52825 RMAN: aggregate input backup 18.7455556 3 115521340 1232568339 9.37
3806 34287 RMAN: full datafile backup Set Count 8.19888889 1 36235504 136924544 26.46
OPNAME=aggregate input的這行資料是聚合行，SID為1548，是RMAN的主會話號，它表示當前RAMN中所有任務的整體進度。
OPNAME=full database backup的行為細節行，一共有4個，每個細節行對應一個通道channel。我們的備份啟動了4個channel，所以這裡就相對4個細節行。如果在這裡能看到16個細節行該多好！
totalwor表示當前行需要處理的工作量，sofar表示已經能夠完成的工作量，%comlete為sofar/totalwork的百分比。
該檢視中聚合行中的總量為1232568339，在RMAN備份中totalwork的單位為blocks（透過UNITS欄位能查到）。透過totalwork總大小1232568339 x 8（資料塊大小） / 1024/1024/1024 = 9.18TB
%_complete完成度是9.37%。
細節行的工作總量完成後，會把完成進度加到聚合行。在備份過程中每次執行該檢視看到細節行的%_complete在增長，而聚合行的%_complete卻不會每次隨著查詢二改變就是這個原因。
備份器件還要關注一下sofar的增長量，如果隔2分鐘以上查詢該檢視發現sofar停止增長了，就應該關注一下v$session_wait檢視看看RMAN回話在等待什麼事件。
我們看看第二天早上的備份進度，一夜都沒備份完
oracle@jccmsdb1:/home/oracle> bdf /orabak
Filesystem kbytes used avail %used Mounted on
/dev/vx/dsk/bakdg/bakvol
9961472000 872303704 9018159296 9% /orabak
SQL> /
SID SERIAL# OPNAME TARGET_DESC HOURS CONTEXT SOFAR TOTALWORK %_complete
---------- ---------- ----------------------------------- --------------- ---------- ---------- ---------- ---------- ----------
6050 62853 RMAN: full datafile backup Set Count 3.25861111 1 95604078 136896374 69.84
6440 52989 RMAN: full datafile backup Set Count 2.95 1 97688238 136890366 71.36
1548 52825 RMAN: aggregate input backup 58.1516667 3 229714732 1232568339 18.64
3058 52919 RMAN: full datafile backup Set Count 3.08333333 1 98322032 136919040 71.81
3806 34287 RMAN: full datafile backup Set Count 4.92305556 1 82772078 136895998 60.46
oracle@jccmsdb1:/home/oracle> ls -ltr /orabak
total 1719089792
drwxr-xr-x 2 root root 96 Oct 10 18:40 lost+found
-rw-r----- 1 oracle oinstall 98304 Oct 12 10:31 datafile6_ptpks4no_1_1.bak
-rw-r----- 1 oracle oinstall 21472854016 Oct 12 18:29 sh_db_full_q5pksqkh_1_1
-rw-r----- 1 oracle oinstall 21472911360 Oct 12 18:32 sh_db_full_q3pksqkf_1_1
-rw-r----- 1 oracle oinstall 21472804864 Oct 12 18:37 sh_db_full_q2pksqke_1_1
-rw-r----- 1 oracle oinstall 21472837632 Oct 12 18:41 sh_db_full_q4pksqkg_1_1
-rw-r----- 1 oracle oinstall 21472772096 Oct 12 20:11 sh_db_full_q5pksqkh_2_1
-rw-r----- 1 oracle oinstall 21472862208 Oct 12 20:15 sh_db_full_q3pksqkf_2_1
-rw-r----- 1 oracle oinstall 21472870400 Oct 12 20:30 sh_db_full_q2pksqke_2_1
-rw-r----- 1 oracle oinstall 21472862208 Oct 12 20:34 sh_db_full_q4pksqkg_2_1
-rw-r----- 1 oracle oinstall 21472878592 Oct 12 21:54 sh_db_full_q5pksqkh_3_1
-rw-r----- 1 oracle oinstall 21472796672 Oct 12 22:06 sh_db_full_q3pksqkf_3_1
-rw-r----- 1 oracle oinstall 21472968704 Oct 12 22:21 sh_db_full_q2pksqke_3_1
-rw-r----- 1 oracle oinstall 21472919552 Oct 12 22:24 sh_db_full_q4pksqkg_3_1
-rw-r----- 1 oracle oinstall 21472804864 Oct 12 23:35 sh_db_full_q5pksqkh_4_1
-rw-r----- 1 oracle oinstall 21472894976 Oct 12 23:58 sh_db_full_q3pksqkf_4_1
-rw-r----- 1 oracle oinstall 21472813056 Oct 13 00:06 sh_db_full_q4pksqkg_4_1
-rw-r----- 1 oracle oinstall 21472903168 Oct 13 00:11 sh_db_full_q2pksqke_4_1
-rw-r----- 1 oracle oinstall 21472993280 Oct 13 01:20 sh_db_full_q5pksqkh_5_1
-rw-r----- 1 oracle oinstall 21472927744 Oct 13 01:48 sh_db_full_q3pksqkf_5_1
-rw-r----- 1 oracle oinstall 21472763904 Oct 13 01:50 sh_db_full_q4pksqkg_5_1
-rw-r----- 1 oracle oinstall 21472878592 Oct 13 02:00 sh_db_full_q2pksqke_5_1
-rw-r----- 1 oracle oinstall 21472788480 Oct 13 03:09 sh_db_full_q5pksqkh_6_1
-rw-r----- 1 oracle oinstall 21473034240 Oct 13 03:39 sh_db_full_q4pksqkg_6_1
-rw-r----- 1 oracle oinstall 21472894976 Oct 13 03:41 sh_db_full_q3pksqkf_6_1
-rw-r----- 1 oracle oinstall 1160511488 Oct 13 03:47 sh_db_full_q3pksqkf_7_1
-rw-r----- 1 oracle oinstall 21472829440 Oct 13 03:57 sh_db_full_q2pksqke_6_1
-rw-r----- 1 oracle oinstall 10962452480 Oct 13 04:06 sh_db_full_q5pksqkh_7_1
-rw-r----- 1 oracle oinstall 5458075648 Oct 13 04:07 sh_db_full_q4pksqkg_7_1
-rw-r----- 1 oracle oinstall 3678208000 Oct 13 04:17 sh_db_full_q2pksqke_7_1
-rw-r----- 1 oracle oinstall 21472804864 Oct 13 05:41 sh_db_full_q6pku1ep_1_1
-rw-r----- 1 oracle oinstall 21472788480 Oct 13 05:55 sh_db_full_q8pku2je_1_1
-rw-r----- 1 oracle oinstall 21472772096 Oct 13 05:57 sh_db_full_q7pku2hk_1_1
-rw-r----- 1 oracle oinstall 21472878592 Oct 13 06:04 sh_db_full_q9pku37d_1_1
-rw-r----- 1 oracle oinstall 21472780288 Oct 13 07:30 sh_db_full_q6pku1ep_2_1
-rw-r----- 1 oracle oinstall 21472911360 Oct 13 07:42 sh_db_full_q8pku2je_2_1
-rw-r----- 1 oracle oinstall 21472944128 Oct 13 07:44 sh_db_full_q7pku2hk_2_1
-rw-r----- 1 oracle oinstall 21472788480 Oct 13 07:53 sh_db_full_q9pku37d_2_1
-rw-r----- 1 oracle oinstall 21472903168 Oct 13 09:18 sh_db_full_q6pku1ep_3_1
-rw-r----- 1 oracle oinstall 21472788480 Oct 13 09:32 sh_db_full_q8pku2je_3_1
-rw-r----- 1 oracle oinstall 21472780288 Oct 13 09:33 sh_db_full_q7pku2hk_3_1
-rw-r----- 1 oracle oinstall 21472878592 Oct 13 09:42 sh_db_full_q9pku37d_3_1
-rw-r----- 1 oracle oinstall 21472985088 Oct 13 11:01 sh_db_full_q6pku1ep_4_1
-rw-r----- 1 oracle oinstall 21472763904 Oct 13 11:21 sh_db_full_q7pku2hk_4_1
-rw-r----- 1 oracle oinstall 21472870400 Oct 13 11:27 sh_db_full_q8pku2je_4_1
-rw-r----- 1 oracle oinstall 21472763904 Oct 13 11:30 sh_db_full_q9pku37d_4_1
此時是週日工作日的正常時段，也是業務高峰期，cpu使用率依然不高才56%而已。
Glance 11.13.007 09:24:26 jccmsdb1 ia64 Current Avg High
------------------------------------------------------------------------------------------------------------------------------------
CPU Util S SN NU UW W | 56% 51% 56%
Disk Util F F |100% 89% 100%
Mem Util S SU UF F | 72% 72% 72%
Networkil U UR R | 56% 56% 56%
------------------------------------------------------------------------------------------------------------------------------------
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 55.0 91.6mb 102mb PRI
oraclesgpmdb 12304 oracle 99.2 1 52.8 92.3mb 101mb PRI
oraclesgpmdb 12281 oracle 99.2 1 60.9 91.6mb 101mb PRI
oraclesgpmdb 12280 oracle 99.0 1 69.4 92.8mb 101mb PRI
oraclesgpmdb 14200 grid 99.0 1 0.0 56.9mb 58.9mb PRI
oraclesgpmdb 22978 grid 98.0 1 0.0 93.8mb 105mb PRI
oraclesgpmdb 22997 grid 90.6 1 0.1 98.6mb 107mb SOCKT
oraclesgpmdb 18182 grid 31.3 1 320.7 55.3mb 56.9mb SYSTM
oraclesgpmdb 14398 grid 30.7 1 801.5 99.5mb 105mb PRI
oraclesgpmdb 6414 grid 24.1 1 0.0 98.1mb 105mb SOCKT
oraclesgpmdb 23038 grid 23.7 1 6.5 99.7mb 105mb SOCKT
ora_lms1_sgp 6965 oracle 19.3 1 0.0 95.9mb 102mb SLEEP
ora_lms0_sgp 6963 oracle 19.0 1 0.0 93.9mb 102mb SLEEP
oraclesgpmdb 29596 grid 13.3 1 6.9 80.2mb 85.3mb SOCKT
oraclesgpmdb 230
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29047826/viewspace-1297207/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- oracle rman備份驗證和備份進度監控Oracle
- oracle rman備份驗證和備份/恢復進度監控Oracle
- 監控資料備份恢復完成進度（EXPDP/IMPDP/RMAN）
- RMAN備份進度查詢
- RMAN備份進度查詢：
- 利用v$session_longops監控長操作SessionGo
- rman備份的時候讀取v$session_longops失敗導致備份失敗SessionGo
- oracle監控表空間,JOB，rman備份Oracle
- 利用v$session_longops監控long RUN操作SessionGo
- [zt] 用v$session_longops監控long RUN操作SessionGo
- 利用v$session_longops監控long RUN操作（轉）SessionGo
- 被動式監控oracle的rman備份情況Oracle
- v$session_longops 檢視回滾進度SessionGo
- 檢視RMAN備份進度的兩條SQLSQL
- 獲取rman備份/恢復執行進度資訊
- Linux下使用pv監控進度Linux
- 監控批量操作進度
- Backup And Recovery User's Guide-備份RMAN備份-使用RMAN備份備份集GUIIDE
- 監控Oracle長時間執行的工作(v$session_longops)OracleSessionGo
- 專案管理必備——使用燃盡圖監控專案整體進度專案管理
- 如何監控工程專案進度？
- 使用RMAN備份資料庫資料庫
- 使用rman備份的指令碼指令碼
- Rman增量壓縮備份來解決備份空間不足
- mongo 監控備份業務賬號建立Go
- 【RMAN】使用增量備份更新資料庫備份映象資料庫
- RMAN備份中冗餘度和Obsolete的備份的關係
- xhr fetch 監控響應進度
- RMAN說，我能備份(9)--RMAN增量備份與備份保留策略
- 來自《三思筆記：一步一步學RMAN06-實戰rman備份》,用rman進行每天自動備份！筆記
- 【RMAN】RMAN備份至ASMASM
- Zabbix監控使用進階
- 使用aop來監控方法進行增強處理
- RMAN說，我能備份(14)--實戰RMAN備份
- rman 備份策略
- RMAN備份原理
- Backup And Recovery User's Guide-備份RMAN備份-用RMAN備份映象拷貝備份GUIIDE
- MONGODB使用MONGDODUMP備份來搭建備份集MongoDB