一則備庫CPU報警的思考

今天收到一封報警郵件，這引起了我的注意。當然過了一會，有收到了CPU使用率恢復的郵件。
報警郵件內容如下：

ZABBIX-監控系統:
------------------------------------
報警內容: Disk I/O is overloaded on ora_statdb2_s_xxx@xxxxx
------------------------------------
報警級別: PROBLEM
------------------------------------
監控專案: CPU iowait time：14.1 %
------------------------------------
報警時間:2016.01.05-03:31:26
看到這封報警郵件，不知道大家作何感想，有什麼疑問嗎？
首先第一個疑問，為什麼備庫會報出CPU異常的郵件，到底是什麼操作導致。
第二，為什麼是備庫報警，主庫為什麼沒有報警。
第三，怎麼去杜絕或者減少這類報警。
其實對這個問題做了分析，就會發現裡面還是有一些治標治本的含義。
首先來逐步分析這個問題，為什麼備庫會報出CPU異常，這是一個OLAP的資料庫，11gR@,CPU使用異常，是否是因為備庫在做大量的報表查詢？
要想驗證這個問題，可以用一個直接了當的sql來說明。
SQL> select username,count(*)from v$session group by username;
USERNAME                         COUNT(*)
------------------------------ ----------
                                       32
PUBLIC                                  3
SYS                                     1
所以其他的設想都不存在，這個庫沒有其它的應用程式連線，可以簡單來說就是在默默接收歸檔。
那麼備庫的CPU使用率為什麼這麼高，我們也可以結合很多原因來看，當然從資料庫日誌裡面也能看出一些端倪來，那就是歸檔切換頻率還是蠻高的。
可以看到網路卡的繁忙程度，其實在一個時間段裡還是比較集中的。

那麼就可以從主庫來分析一下歸檔的情況了。
當然我也確實比較懶，能看到圖形報告就肯定不願意多去拿更多的命令去分析了。
主庫的歸檔切換頻率如下，可以看到系統在特定的時間段裡還是比較繁忙的。

但是話說回來，這是一個OLAP,怎麼比OLTP還繁忙。
如果排除系統的原因，那麼更多的可能性就是sql語句了。不過還有一個問題需要弄明白，是不是每天都會這樣，因為不是每天都收到報警郵件。
我們來看看七天之內的歸檔情況。可以看到在每天的固定時間段裡，歸檔切換還是比較頻繁的，尤其在今天更為明顯。

當然這個地方我還要補充一下，圖形結果都是片面的，更好的說明還有一個文字的報告。
也是下面的文字報告給我了思路。

如果仔細看看，發現其實在每週的週二都會有一個時間段產生大量的歸檔。
如此一來，想必有些朋友應猜出來了，應該是scheduler導致，這個也是我最後定位問題的一個很好的方向。結合一個星期還不夠，結合了大半個月的資料才發現了這個規律。
那麼可以去檢視awr報告看看哪些scheduler在執行。
還是用指令碼吧。62033是問題時間段附近的快照號。就得到了下面的sql列表。
$ sh showsnapsql.sh 62033
---------- ------------- ---------------- ---------- ----------
     62033 75ubgcf0pdrkr                0 1802s      19%
     62033 36s5j5zrztscz                0 1802s      19%
     62033 882jz57wm9cj7                0 1802s      19%
     62033 gab74zwuduz76                0 1678s      18%
     62033 0fhgdzus0hu2t                0 1628s      17%
毫無疑問，這幾個裡面應該就有我們需要找到的目標，可以看到top 5的sql語句都是執行了近半個小時，executions都為0.所以還是有很大的可能性。
抓取到了幾個大查詢sql,幾個update,當然最重要的就是其中的一個scheduler了。
SQL_FULLTEXT
----------------------------------------------------------------------------------------------------
BEGIN proc_update_cardinfo(); END;
其實top 5中的sql語句都會直接間接在這個scheduler中呼叫的儲存過程中存在。而這個語句的一個核心語句就是下面的形式。
SQL_FULLTEXT
----------------------------------------------------------------------------------------------------
UPDATE TESTINFO A SET A.MAX_LEVEL = NVL((SELECT USER_CLASS FROM ROLE_CLASS_INFO B WHERE A.GROUPID =
B.GROUP_ID AND B.CN_GUID = A.ROLE_GUID), A.MAX_LEVEL) WHERE DRAWED = 'Y'
表裡的資料都在億級，所以全表也會很長時間，消耗也是非常的大。
當然後續就是看看這個語句，還有什麼改進的空間，這個還是得和開發的同學好好討論一下。
然後最後的問題，為什麼主庫沒有這類的報錯。
有兩個資料可以佐證，那就是主庫的記憶體是132G,備庫是32G,主庫的CPU是24，而備庫是8，相差比較懸殊，也難怪會出現這樣的問題。
所以通過備庫的CPU報警我們發現備庫存在大量的日誌切換，然後把注意力很自然轉移到主庫，發現在特定的時間段裡會產生大量的歸檔，而大量的歸檔的產生會給備庫造成一些系統壓力，導致CPU負載過高，但是根本的是為什麼主庫的歸檔產生非常多，和主庫中的而一個scheduler有關，所以最後的根本就是調優這個scheduler看看，有多大的改進空間。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1972211/，如需轉載，請註明出處，否則將追究法律責任。