【故障处理】序列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源创计划”，欢迎正在阅读的你也加入，一块儿分享。