序列cache值过小导致CPU利用率过高

1、故障环境如下表所示：

2、故障发生现象及报错信息

有一套数据库做测试的时候，CPU利用率很高，同事已经抓取了CPU和AWR的信息。发生问题的时间段是19点到23点，其中，nmon数据截图如下所示：

可以看到CPU的利用率是非常高的，下边来看看AWR中的数据：

从等待事件中可以很明显地看出“enq: SQ - contention”和“DFS lock handle”这两个等待事件异常。“Top 5 Timed Events”部分也是AWR报告中非常重要的部分，从这里可以看出等待事件排在前五位的是哪些事件，从而基本上就可以判断出性能瓶颈在什么地方。在这里，“enq: SQ - contention”等待了172254次，等待时间为69652秒，平均等待时间为69652/172254=404毫秒，等待类别为Configuration即配置上的等待问题。

3、有关序列等待的基础知识

根据AWR报告的内容，基本可以断定，只要解决了“enq: SQ - contention”和“DFS lock handle”这两个等待事件即可解决问题。其实，“enq: SQ - contention”、“row cache lock”、“DFS lock handle”和“enq: SV -  contention”这4个等待事件都与Oracle的序列有关，如下所示：

1SELECT *
2 FROM V$EVENT_NAME
3WHERE NAME IN ('row cache lock','enq: SQ - contention','DFS lock handle','enq: SV -  contention');

其中，PAREMETER1的值为“name|mode”或“type|mode”的事件为队列等待。在这类等待事件中，name代表队列的名称，type代表队列的类型，mode代表队列的模式。使用如下的SQL可以查询到锁的名称和请求的mode值：

1SELECT CHR(BITAND(P1,-16777216)/16777215)||CHR(BITAND(P1, 16711680)/65535) "LOCK",
2    BITAND(P1, 65535) "MODE"
3FROM V$SESSION_WAIT
4WHERE EVENT IN ('enq: SQ - contention','DFS lock handle','enq: SV -  contention');

其中，MODE值如下表所示：

使用如下的SQL可以查询SQ和SV这两种锁的解释：

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

事实上，Oracle为了管理序列使用了如下表所示的三种锁：

在RAC上创建序列时，在赋予了CACHE属性的状态下，若没有赋予ORDER属性，则各节点将会把不同范围的序列值CACHE到内存上。比如，在拥有两个节点的RAC环境下，创建CACHE值为100的序列，则节点1使用1～100，节点2使用101～200。若两个节点之间都通过递增方式使用序列，则必须赋予ORDER属性。Oracle序列默认是NOORDER，如果设置为ORDER，那么在单实例环境没有影响，在RAC环境中，多实例实际缓存相同的序列，此时在多个实例并发取该序列的时候，会有短暂的资源竞争来在多实例之间进行同步。因此，性能相比NOORDER要差，所以RAC环境非必须的情况下不要使用ORDER，尤其要避免NOCACHE ORDER组合。

有一点必须要注意，当没有赋予CACHE属性时，不管ORDER属性使用与否或RAC环境与否，一直等待row cache lock事件。row cache lock是可以在全局范围内使用的锁，单实例环境或多实例环境同样可以发生。如果使用了CACHE，而此时DB崩溃了，那么序列会从CACHE值之后重新开始，在CACHE中没有使用的序列会被跳过，这样就会导致序列不连续。在创建序列时，CACHE的缺省值设定为较小的20。因此创建并发量多的序列时，CACHE值应该取1000以上的较大值。

另外，若一次性同时创建许多会话时，有时会发生enq: SQ - contention等待事件。其原因是V$SESSION.AUDSID列值是利用序列创建的。Oracle在创建新的会话后，利用名为SYS.AUDSES$的序列的NEXTVAL来创建AUDSID值。在Oracle 10g下SYS.AUDSES$的CACHE值默认20，但在Oracle 11g下SYS.AUDSES$的CACHE值默认为10000，通过如下的SQL可以查询：

1SELECT * FROM DBA_SEQUENCES D WHERE D.SEQUENCE_NAME ='AUDSES$';

4、故障解决过程

首先查询出现问题时间段的ASH视图DBA_HIST_ACTIVE_SESS_HISTORY，通过该视图可以找到需要的序列名称。可以有多种查询方法：

1SELECT D.SQL_ID, COUNT(1)
2  FROM DBA_HIST_ACTIVE_SESS_HISTORY D
3 WHERE D.SAMPLE_TIME BETWEEN TO_DATE('20160823170000', 'YYYYMMDDHH24MISS') AND
4       TO_DATE('20160823230000', 'YYYYMMDDHH24MISS')
5   AND D.EVENT = 'enq: SQ - contention'
6 GROUP BY D.SQL_ID;

可以看到SQL_ID为3jhvjgj7kbpmt的SQL最多，查看具体SQL内容：

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

由此可以知道，产生等待的序列名称为ONLNID，另外，也可以从DBA_HIST_ACTIVE_SESS_HISTORY视图的P2值获取到序列的名称，SQL语句如下：

 1 SELECT D.EVENT,
 2        D.P1TEXT,
 3        D.P1,
 4        D.P2TEXT,
 5        D.P2,
 6        CHR(BITAND(P1, -16777216) / 16777215) ||
 7        CHR(BITAND(P1, 16711680) / 65535) "Lock",
 8        BITAND(P1, 65535) "Mode",
 9        D.BLOCKING_SESSION,
10        D.BLOCKING_SESSION_STATUS,
11        D.BLOCKING_SESSION_SERIAL#,
12        D.SQL_ID,
13        TO_CHAR(D.SAMPLE_TIME, 'YYYYMMDDHH24MISS') SAMPLE_TIME,
14        D.*
15   FROM DBA_HIST_ACTIVE_SESS_HISTORY D
16  WHERE D.SAMPLE_TIME BETWEEN TO_DATE('20160823170000', 'YYYYMMDDHH24MISS') AND
17        TO_DATE('20160823230000', 'YYYYMMDDHH24MISS')
18    AND D.EVENT = 'enq: SQ - contention';

由以上的查询结果可知，序列的OBJECT_ID为47989，通过DBA_OBJECTS就可以查询到序列的名称了。另外，LOCK为SQ代表的是序列的CACHE锁（SEQUENCE CACHE），MODE为6代表EXCLUSIVE排它锁。

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

知道了序列名称后，通过DBA_SEQUENCES视图就可以查询到序列的属性了：

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

可以看到，该序列是NOORDER属性，CACHE值为默认的20，对于并发值很高的系统而言，该默认值太低，所以需要调整到1000。可以执行SQL语句“ALTER SEQUENCE ONLNID CACHE 1000;”调整其CACHE值即可解决该问题。

& 说明：

有关该案例的更多内容可以参考我的BLOG：http://blog.itpub.net/26736162/viewspace-2123996/、http://blog.itpub.net/26736162/viewspace-2139754/

本文选自《Oracle程序员面试笔试宝典》，作者：小麦苗