【故障處理】序列cache值太小致使CPU利用率太高

想關注我嗎？請點擊圖片上方藍字小麥苗關注即可，關注後您將能夠每日得到最實用的數據庫技術。請將小麥苗公衆號置頂，小麥苗不喜歡被壓着，~O(∩_∩)O~

小麥苗的今日寄語

LDD，若是有一天，你走進個人內心，你必定會哭，由於裏面裝滿你的點滴。若是有一天，我走進你的內心，我也必定會哭，由於裏面找不到個人身影。

       

今天帶給你們的是序列cache值太小致使CPU利用率太高的一個案例，說到底也就是關於等待事件的處理。看完本文，但願你們能夠學到下邊4個方面的內容：

① enq: SQ - contention等待事件的解決

② 通常等待事件的解決辦法

③ DFS lock handle等待事件

④ 與序列有關的等待事件

固然，你們看文章的同時能夠點擊下邊的音樂感覺做者小麥苗最近悲傷的心情。

【故障處理】序列cache值太小致使CPU利用率太高          

 

1  BLOG文檔結構圖

 

 

 

 

2  前言部分

 

2.1  導讀和注意事項

各位技術愛好者，看完本文後，你能夠掌握以下的技能，也能夠學到一些其它你所不知道的知識，~O(∩_∩)O~：

① enq: SQ - contention等待事件的解決

② 通常等待事件的解決辦法

③ DFS lock handle等待事件

④ 與序列有關的等待事件

  Tips：

① 本文在ITpub（http://blog.itpub.net/26736162）、博客園(http://www.cnblogs.com/lhrbest)和微信公衆號（xiaomaimiaolhr）有同步更新

② 文章中用到的全部代碼，相關軟件，相關資料請前往小麥苗的雲盤下載（http://blog.itpub.net/26736162/viewspace-1624453/）

③ 若文章代碼格式有錯亂，推薦使用搜狗、360或QQ瀏覽器，也能夠下載pdf格式的文檔來查看，pdf文檔下載地址：http://blog.itpub.net/26736162/viewspace-1624453/，另外itpub格式顯示有問題，能夠去博客園地址閱讀

④ 本篇BLOG中命令的輸出部分須要特別關注的地方我都用灰色背景和粉紅色字體來表示，好比下邊的例子中，thread 1的最大歸檔日誌號爲33，thread 2的最大歸檔日誌號爲43是須要特別關注的地方；而命令通常使用黃色背景和紅色字體標註；對代碼或代碼輸出部分的註釋通常採用藍色字體表示。

  List of Archived Logs in backup set 11

  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time

  ---- ------- ---------- ------------------- ---------- ---------

  1    32      1621589    2015-05-29 11:09:52 1625242    2015-05-29 11:15:48

  1    33      1625242    2015-05-29 11:15:48 1625293    2015-05-29 11:15:58

  2    42      1613951    2015-05-29 10:41:18 1625245    2015-05-29 11:15:49

  2    43      1625245    2015-05-29 11:15:49 1625253    2015-05-29 11:15:53

 

[ZHLHRDB1:root]:/>lsvg -o

T_XDESK_APP1_vg

rootvg

[ZHLHRDB1:root]:/>

00:27:22 SQL> alter tablespace idxtbs read write;

 

====》2097152*512/1024/1024/1024=1G 

 

本文若有錯誤或不完善的地方請你們多多指正，ITPUB留言或QQ皆可，您的批評指正是我寫做的最大動力。

 

 

 

3  故障分析及解決過程

 

 

3.1  故障環境介紹

 

項目	source db
db 類型	RAC
db version	10.2.0.5.0
db 存儲	ASM
OS版本及kernel版本	AIX 64位 6.1.0.0

 

 

3.2  故障發生現象及報錯信息

早上同事過來跟我說昨天有一套數據庫作測試的時候，CPU利用率很高，他已經抓取了CPU和AWR，讓我幫忙分析分析，首先發生問題的時間段是19點到23點，nmon數據截圖以下：

 

能夠看到CPU的利用率是很是高的，下邊咱們來看看AWR中的數據：

 

 

其它的項目就不列出了，從等待事件中能夠很明顯的看出enq: SQ - contention和DFS lock handle這2個等待事件異常。Top 5 Timed Events這個部分也是AWR報告中很是重要的部分，從這裏能夠看出等待時間在前五位的是什麼事件，基本上就能夠判斷出性能瓶頸在什麼地方。一般，在沒有問題的數據庫中，CPU time老是列在第一個。在這裏，enq: SQ - contention等待了172254次，等待時間爲69652秒，平均等待時間爲69652/172254=404毫秒，等待類別爲Configuration即配置上的等待問題。

 

3.3  故障分析

根據AWR報告的內容，咱們知道只要解決了enq: SQ - contention和DFS lock handle這2個等待事件便可解決問題。那麼咱們首先來了解一些關於這2個等待事件的知識。

===============================================================================

enq: SQ - contention/row cache lock/DFS lock handle這三個等待事件都與Oracle 的Sequence 有關。

 

SELECT *

  FROM V$EVENT_NAME

 WHERE NAME IN

       ('row cache lock', 'enq: SQ - contention', 'DFS lock handle');

 

使用以下的SQL咱們能夠查詢到鎖的名稱和請求的MODE，表的mode值參考表格：

select chr(bitand(p1,-16777216)/16777215)||

chr(bitand(p1, 16711680)/65535) "Lock",

bitand(p1, 65535) "Mode"

from v$session_wait

where event = 'DFS enqueue lock acquisition';

Table C-1 Lock Mode Values

Mode Value	Description
1	Null mode
2	Sub-Share
3	Sub-Exclusive
4	Share
5	Share/Sub-Exclusive
6	Exclusive

 

SELECT * FROM V$LOCK_TYPE D WHERE D.TYPE IN ('SV','SQ');

 

Oracle 爲了管理Sequence 使用瞭如下三種鎖。

① row cache lock:在調用SEQUNECE.NEXTVAL過程當中，將數據字典信息進行物理修改時獲取。賦予了NOCACHE屬性的SEQUENCE上發生，等待事件爲row cache lock。

② SQ鎖:在內存上緩存（CACHE）的範圍內，調用SEQUENCE.NEXTVAL 期間擁有此鎖。賦予了CACHE 屬性的SEQUENCE 上發生。賦予了CACHE 屬性的SEQUENCE 調用NEXTVAL 期間，應該以SSX 模式得到SQ 鎖。許多會話同時爲了獲取SQ 鎖而發生爭用過程當中，若發生爭用，則等待enq: SQ - contention事件。enq: SQ - contention 事件的P2 值是Sequence 的OBJECT ID。所以，若利用P2 值與DBA_OBJECTS 的結合，就能夠知道對哪一個SEQUENCE 發生了等待現象。

③ SV鎖:RAC上節點之間順序獲得保障的狀況下，調用SEQUENCE.NEXTVAL期間擁有。賦予CACHE + ORDER屬性的SEQUENCE 上發生，等待事件爲DFS lock handle，解決辦法爲：儘可能設置爲NOORDER並增大其CACHE值。

根據建立Sequence時賦予的屬性，整理等待事件的結果以下：

v NOCACHE: row cache lock

v CACHE + NOORDER: enq: SQ - contention

v CACHE + ORDER(RAC): DFS lock handle

 

建立SEQUENCE賦予的CACHE 值較小時，有enq: SQ - contention等待增長的趨勢。CACHE值較小時，內存上事先CACHE的值很快被耗盡，這時須要將數據字典信息物理修改後，再次執行CACHE的工做。在此期間，由於一直擁有SQ 鎖，相應的enq: SQ - contention 事件的等待時間也會延長。很不幸的是，在建立SEQUENCE 時，將CACHE 值的缺省值設定爲較小的20。所以建立使用量多的SEQUENCE 時，CACHE 值應該取1000 以上的較大值。

另外，偶爾一次性同時建立許多會話時，有時會發生enq: SQ - contention 等待事件。其理由是V$SESSION.AUDSID（auditing session id）列值是利用Sequence建立的。Oracle 在建立新的會話後，利用名爲SYS.AUDSES$的Sequence 的nextval，建立AUDSID 值。SYS.AUDSES$ Sequence 的CACHE 大小的缺省值設定爲20。許多會話同時鏈接時，能夠將SYS.AUDSES$ Sequence 的CACHE大小擴大至1000，以此能夠解決enq: SQ - contention 等待問題。 10g下默認20,11g下默認爲10000，經過以下的SQL能夠查詢：

SELECT * FROM dba_sequences d WHERE d.sequence_name ='AUDSES$';

 

RAC 上建立SEQUENCE 時，在賦予了CACHE屬性的狀態下，若沒有賦予ORDER 屬性，則各節點將會把不一樣範圍的SEQUENCE 值CACHE 到內存上。好比，擁有兩個節點的RAC 環境下，建立CACHE 值爲100 的SEQUENCE 時，1號節點使用1～100，2 號節點使用101～200。若兩個節點之間都經過遞增方式使用SEQUENCE，必須賦予以下ORDER 屬性。

      SQL> CREATE SEQUENCE ORDERED_SEQUENCE CACHE 100 ORDER;

若是是已賦予了CACHE+ORDER 屬性的SEQUENCE，Oracle 使用SV 鎖進行行同步。即，對賦予了ORDER 屬性的Sequence 調用nextval 時，應該以SSX模式擁有SV 鎖。在獲取SV 鎖過程當中，若是發生爭用時，不是等待row cache lock 事件或enq: SQ - contention 事件，而是等待名爲DFS lock handle 事件。正因如此，V$EVENT_NAME 視圖上不存在相似"enq:SV-contention"的事件。DFS lock handle 事件是在OPS 或RAC 環境下，除了高速緩衝區同步以外，還有行高速緩衝區或庫高速緩衝區的爲了同步獲取鎖的過程當中等待的事件。若要保障多個節點之間Sequence順序，應該在全局範圍內得到鎖，在此過程當中會發生DFS lock handle 等待。在獲取SV 鎖的過程當中發生的DFS lock handle等待事件的P1 、P2 值與enq: SQ - contention 等待事件相同（ P1=mode+namespace、P2=object#）。所以從P1 值能確認是不是SV 鎖，經過P2值能夠確認對哪些Sequence 發生過等待。SV 鎖爭用問題發生時的解決方法與SQ 鎖的狀況相同，就是將CACHE 值進行適當調整，這也是惟一的方法。

在RAC 等多節點環境下，Sequence 的CACHE 值給性能帶來的影響比單節點環境更嚴重。所以，儘可能賦予CACHE+NOORDER 屬性，並要給予足夠大的CACHE值。若是須要保障順序，必須賦予CACHE+ORDER 屬性。但這時爲了保障順序，實例之間不斷髮生數據的交換。所以，與賦予了NOORODER屬性的時候相比性能稍差。

有一點必需要注意，沒有賦予CACHE屬性時，無論ORDER 屬性使用與否或RAC 環境與否，一直等待row cache lock 事件。row cache lock是能夠在全局範圍內使用的鎖，單實例環境或多實例環境一樣能夠發生。

沒有賦予CACHE屬性時，無論ORDER屬性是否或RAC環境是否，一直等待ROW CACHE事件，ROW CACHE LOCK是否能夠在全局範圍內使用的鎖，單實例環境或多實例環境同時能夠發生。

Oracle Sequence默認是NOORDER，若是設置爲ORDER；在單實例環境沒有影響，在RAC環境此時，多實例實際緩存相同的序列，此時在多個實例併發取該序列的時候，會有短暫的資源競爭來在多實例之間進行同步。因次性能相比noorder要差，因此RAC環境非必須的狀況下不要使用ORDER，尤爲要避免NOCACHE ORDER組合。

可是若是使用了Cache，若是此時DB 崩潰了，那麼sequence會從cache以後從新開始，在cache中沒有使用的sequence會被跳過。即sequence不連續。因此只有在多節點高峯併發量很大的狀況且對連續性要求不高的狀況下，才使用：noorder + cache。

DFS lock handle

The session waits for the lock handle of a global lock request. The lock handle identifies a global lock. With this lock handle, other operations can be performed on this global lock (to identify the global lock in future operations such as conversions or release). The global lock is maintained by the DLM.

Wait Time: The session waits in a loop until it has obtained the lock handle from the DLM. Inside the loop there is a wait of 0.5 seconds.

Parameter	Description
name	See "name and type"
mode	See "mode"
id1	See "id1"
id2	See "id2"

The session needs to get the lock handle.

該等待事件的發生，若不是SV鎖的話，多半爲bug引發。

id1

The first identifier (id1) of the enqueue or global lock takes its value from P2 or P2RAW. The meaning of the identifier depends on the name (P1).

id2

The second identifier (id2) of the enqueue or global lock takes its value from P3 or P3RAW. The meaning of the identifier depends on the name (P1).

mode

The mode is usually stored in the low order bytes of P1 or P1RAW and indicates the mode of the enqueue or global lock request.This parameter has one of the following values:

Table C-1 Lock Mode Values

Mode Value	Description
1	Null mode
2	Sub-Share
3	Sub-Exclusive
4	Share
5	Share/Sub-Exclusive
6	Exclusive

 

Use the following SQL statement to retrieve the name of the lock and the mode of the lock request:

select chr(bitand(p1,-16777216)/16777215)||

chr(bitand(p1, 16711680)/65535) "Lock",

bitand(p1, 65535) "Mode"

from v$session_wait

where event = 'DFS enqueue lock acquisition';

name and type

The name or "type" of the enqueue or globallock can be determined by looking at the two high order bytes of P1 or P1RAW. The name is always two characters. Use the following SQL statement to retrieve the lock name.

select chr(bitand(p1,-16777216)/16777215)||

chr(bitand(p1,16711680)/65535) "Lock"

from v$session_wait

where event = 'DFS enqueue lock acquisition';

 

===============================================================================

有了以上的知識，咱們知道，目前只須要找到產生等待的序列名稱，而後設置其CACHE爲比較大的一個值便可解決問題。

 

3.4  故障解決過程

 

3.4.1  enq: SQ - contention等待事件

咱們查詢出現問題時間段的ASH視圖DBA_HIST_ACTIVE_SESS_HISTORY來找到咱們須要的序列名稱。

能夠有多種查詢方法：

SELECT D.SQL_ID, COUNT(1)

  FROM DBA_HIST_ACTIVE_SESS_HISTORY D

 WHERE D.SAMPLE_TIME BETWEEN TO_DATE('20160823170000', 'YYYYMMDDHH24MISS') AND

       TO_DATE('20160823230000', 'YYYYMMDDHH24MISS')

   AND D.EVENT = 'enq: SQ - contention'

 GROUP BY D.SQL_ID;

 

能夠看到SQL_ID爲3jhvjgj7kbpmt的SQL最多，咱們查看具體SQL內容：

SELECT * FROM V$SQL A WHERE A.SQL_ID IN ('3jhvjgj7kbpmt') ;

 

由此能夠知道，產生等待的序列名稱爲ONLNID,另外，咱們也能夠從DBA_HIST_ACTIVE_SESS_HISTORY視圖的P2值獲取到序列的名稱，以下：

 SELECT D.EVENT,

        D.P1TEXT,

        D.P1,

        D.P2TEXT,

        D.P2,

        CHR(BITAND(P1, -16777216) / 16777215) ||

        CHR(BITAND(P1, 16711680) / 65535) "Lock",

        BITAND(P1, 65535) "Mode",

        D.BLOCKING_SESSION,

        D.BLOCKING_SESSION_STATUS,

        D.BLOCKING_SESSION_SERIAL#,

        D.SQL_ID,

        TO_CHAR(D.SAMPLE_TIME, 'YYYYMMDDHH24MISS') SAMPLE_TIME,

        D.*

   FROM DBA_HIST_ACTIVE_SESS_HISTORY D

  WHERE D.SAMPLE_TIME BETWEEN TO_DATE('20160823170000', 'YYYYMMDDHH24MISS') AND

        TO_DATE('20160823230000', 'YYYYMMDDHH24MISS')

    AND D.EVENT = 'enq: SQ - contention';

 

由以上的查詢結果可知，序列的object_id爲47989，由此也能夠知道序列名稱以下，另外，lock爲SQ表明的是序列的cache鎖（Sequence Cache），mode爲6表明Exclusive排他鎖。

SELECT * FROM DBA_OBJECTS D WHERE D.object_id='47989';

 

知道了序列名稱後，咱們就能夠查詢序列的屬性了：

SELECT * FROM DBA_SEQUENCES D WHERE D.sequence_name='ONLNID' ;

 

能夠看到，該序列是NOORDER屬性，CACHE值爲默認的20，對於併發值很高的系統而言，該默認值過低，因此須要調整到1000，咱們執行SQL:ALTER SEQUENCE NFXS.ONLNID CACHE 1000; 調整其cache值便可解決該問題。

 

 

3.4.2  DFS lock handle等待事件

咱們查詢出現問題時間段的ASH視圖DBA_HIST_ACTIVE_SESS_HISTORY來找到咱們須要的序列名稱。

能夠有多種查詢方法：

SELECT D.SQL_ID, COUNT(1)

  FROM DBA_HIST_ACTIVE_SESS_HISTORY D

 WHERE D.SAMPLE_TIME BETWEEN TO_DATE('20160823170000', 'YYYYMMDDHH24MISS') AND

       TO_DATE('20160823230000', 'YYYYMMDDHH24MISS')

   AND D.EVENT = 'DFS lock handle'

 GROUP BY D.SQL_ID;

 

能夠看到SQL_ID爲"67vjwqswg2zvy"的SQL最多，咱們查看具體SQL內容：

SELECT * FROM V$SQL A WHERE A.SQL_ID IN ('67vjwqswg2zvy') ; 

 

SQL的內容爲：

SELECT formatid, globalid, branchid FROM                    SYS.DBA_PENDING_TRANSACTIONS                  ORDER BY formatid, globalid, branchid

很奇怪，這是個系統視圖，爲啥會有DFS lock handle的等待事件產生呢？

 SELECT D.EVENT,

        D.P1TEXT,

        D.P1,

        D.P2TEXT,

        D.P2,

        CHR(BITAND(P1, -16777216) / 16777215) ||

        CHR(BITAND(P1, 16711680) / 65535) "Lock",

        BITAND(P1, 65535) "Mode",

        D.BLOCKING_SESSION,

        D.BLOCKING_SESSION_STATUS,

        D.BLOCKING_SESSION_SERIAL#,

        D.SQL_ID,

        TO_CHAR(D.SAMPLE_TIME, 'YYYYMMDDHH24MISS') SAMPLE_TIME,

        D.*

   FROM DBA_HIST_ACTIVE_SESS_HISTORY D

  WHERE D.SAMPLE_TIME BETWEEN TO_DATE('20160823170000', 'YYYYMMDDHH24MISS') AND

        TO_DATE('20160823230000', 'YYYYMMDDHH24MISS')

    AND D.EVENT = 'DFS lock handle'; 

 

由以上的查詢結果可知，lock爲CI表明的是交叉實例功能調用實例，而並非咱們指望的SV鎖，mode爲5表明Share/Sub-Exclusive。

SELECT * FROM V$LOCK_TYPE D WHERE D.TYPE ='CI';

 

查了metalink可知，該問題是由bug引發。該庫的版本爲10.2.0.5的基礎版本，並無打任何的PSU。

 

3.5  健康檢查

AWR分析完成後，我又收集了一下該庫的健康檢查狀況，看看是否有其它方面的問題。

 

 

能夠看出這個庫並無任何的PSU的信息，而後咱們直接查看檢查的結果：

 

 

能夠看到數據庫有上邊的幾個問題，其中就有cache小於20的問題，咱們點擊鏈接能夠看到：

 

另外，在告警日誌中，咱們也能夠看到，以下的信息，說明prcesses參數設置太小。

 

 

  About Me

.....................................................................................................................................

● 本文做者：小麥苗，只專一於數據庫的技術，更注重技術的運用

● 本文在itpub（http://blog.itpub.net/26736162）、博客園(http://www.cnblogs.com/lhrbest)和我的微信公衆號（xiaomaimiaolhr）上有同步更新，推薦pdf文件閱讀

● QQ羣：230161599 微信羣：私聊

● 本文itpub地址：http://blog.itpub.net/26736162/viewspace-2123996/ 博客園地址：http://www.cnblogs.com/lhrbest/articles/5804363.html

● 本文pdf版：http://yunpan.cn/cdEQedhCs2kFz （提取碼：ed9b）

● 小麥苗分享的其它資料：http://blog.itpub.net/26736162/viewspace-1624453/

● 聯繫我請加QQ好友(642808185)，註明添加原因

● 於 2016-08-24 09:00~2016-08-24 19:00 在中行完成

● 【版權全部，文章容許轉載，但須以連接方式註明源地址，不然追究法律責任】

........................................................................................................................................

長按識別二維碼或微信客戶端掃描下邊的二維碼來關注小麥苗的微信公衆號：xiaomaimiaolhr,學習最實用的數據庫技術。

 

本文分享自微信公衆號 - DB寶（lhrdba）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。