通過定製orabbix監控分析潛在的Oracle問題 (r6筆記第32天)
在之前的部落格中分享過 簡單定製Orabbix監控項 http://blog.itpub.net/23718752/viewspace-1769773/ 定製的功能在Orabbix中實現非常靈活而且輕巧，還是能夠感受到一種開源風的清爽。 我在orabbix原有模板的基礎上添加了幾個監控項，一個是監控閃回區的使用率，還有一個是監控歸檔的切換頻率，這兩個功能看似微不足道，但是會在細節中反應出資料庫中是否有明顯的異常行為。 中午的時候注意到有一個庫的閃回區使用率和歸檔頻率比較高。還是有一些反常，而從我這邊的資訊來看，沒有得到開發人員的反饋說需要做什麼資料變更。 得到的orabbix監控圖如下： 閃回區的使用情況如下：
歸檔頻率如下：
通過這個圖可以看到還是有一些異常情況的。這個庫是一個統計庫，案例來說併發訪問量應該不高，但是現在從早上的某個時間點開始，歸檔量急劇提升，已經快觸及警報線。 在這個時候也是帶著疑問去檢查了一下這個庫，結果通過ash檢視去看，是否正在進行大量的併發操作，結果沒有任何的active session,然後檢視資料庫負載，又很高。 抓取了一個awr報告來看。赫然發現top1的sql竟然是一個update語句。
Elapsed Elapsed Time Time (s) Executions per Exec (s) %Total %CPU %IO SQL Id ---------------- -------------- ------------- ------ ------ ------ --- 3,604.9 0 N/A 26.9 32.5 68.2 3jggcpxmv6w8g Module: [email protected] (TNS V1-V3) update "xxxx"."TEST_BILLING" set "ID" = 'xxxxxxxxxx'
這個語句可以明顯看出來存在一定的問題，因為這是一個大表，資料量在億級，進行這樣一個dml操作，代價還是相當大的。
為了一探究竟我們來看看到底是誰在執行這樣一個dml。
結果一看還是讓人大吃一驚，竟然是在本地的sys的操作，問題又指向了自己，因為這個庫開發人員是沒有任何許可權直接訪問的。
USERNAME SID SERIAL# PROGRAM MACHINE
--------------- ---------- ------------------------------------------------ --------------------
SYS 22 50043 [email protected],com
但是我確實也沒有做任何的操作，不至於說哪個指令碼很神奇的執行了？
帶著疑問和同事進行排查，最後發現，這個dml語句是在做log miner解析的時候出了點問題。
因為一些資料同步的考慮，需要從另外一個核心庫中同步一部分的資料到這個統計庫中，但是又不想直接在主庫中進行任何的額外配置，這個時候就使用了log miner來定製抽取歸檔中的sql語句，然後部署在這個統計庫中。這個過程是通過crontab來觸發的。
但是在log miner解析的過程中還是出了一點解析的問題，有一條update語句沒有where字句結果就直接應用到這個統計庫中了，結果生成了大量的redo,歸檔切換也很頻繁。
比如說解析log miner的檢視的時候，預設是使用下面的方式。
SELECT sql_redo FROM v$logmnr_contents WHERE seg_owner='XXXX' AND TABLE_NAME IN ('XXXX','XXXXXX') AND OPERATION in ('INSERT','UPDATE','DELETE')
結果某一條語句在解析的過程中出了問題，結果導致對於這類不規範的update語句，應用到統計庫的時候把影響放大了。
可以通過交半年進行過濾，也可以直接在sql中進行過濾。比如修改為下面的形式。
SELECT sql_redo FROM v$logmnr_contents WHERE seg_owner='XXXXX' AND TABLE_NAME IN ('XXXX','XXXX') AND OPERATION in ('INSERT') or (operation in ('DELETE','UPDATE') and upper(sql_redo) like '%WHERE %')
這樣對於update和delete操作都hi進行必要的過濾，那些不指定條件的delete,update操作都可以直接遮蔽。
當然對這個問題的緊急修復也很明確，就是kill那個執行很長時間的session.
Kill session之後的效果如下，可以看到閃回區的使用率一下子降下來了。歸檔頻率也降下來了。
通過這個問題可以看出，定製適合自己的監控項在某種程度上還是能夠起到很好的監控作用。對於某些異常情況還是不要掉以輕心。