【等待事件】等待事件系列（5.1）--Enqueue(队列等待)

【等待事件】等待事件系列（5.1）--Enqueue(队列等待)

1  BLOG文档结构图

2  前言部分

2.1  导读和注意事项

各位技术爱好者，看完本文后，你可以掌握如下的技能，也可以学到一些其它你所不知道的知识，~O(∩_∩)O~：

① Enqueue队列等待

② Enq数据字典

③ enq: AE - lock

④ enq: MR锁

⑤ enq: DX - contention

⑥ enq: SQ - contention 序列等待

2.2  相关参考文章链接

3   Enqueue(队列等待)

3.1  简介

Enqueue是一种保护共享资源的锁定机制,是协调访问数据库资源的内部锁。该锁定机制保护共享资源，以避免因并发操作而损坏数据，比如通过锁定保护一行记录，避免多个用户同时更新。Enqueue采用排队机制，即FIFO(先进先出)来控制资源的使用。

Enqueue是一组锁定事件的集合，如果数据库中这个等待事件比较显著，还需要进一步追踪是哪一个类别的锁定引发了数据库等待。

Enqueue这个词其实是LOCK的另一种描述语。当我们在AWR报告中发现长时间的Enqueue等待事件时，说明数据库中出现了阻塞和等待，可以关联AWR报告中的Enqueue Activity部分来确定是哪一种锁定出现了长时间等待。

所有以“enq：”打头的等待事件都表示这个会话正在等待另一个会话持有的内部锁释放，它的名称格式是enq:enqueue_type - related_details。数据库动态性能视图v$event_name提供所有以“enq：”开头的等待事件的列表。

SELECT * FROM V$EVENT_NAME WHERE NAME LIKE 'enq%';

SELECT D.PARAMETER1, COUNT(1)

  FROM V$EVENT_NAME D

 WHERE NAME LIKE 'enq%'

 GROUP BY D.PARAMETER1;

可以看出11.2.0.4中大约有512种Enqueue等待事件。

这一类的等待事件P1参数一般有“name|mode”和“type|mode”2种形式，其中：

Name： enqueue 的名称和类型。

Mode： enqueue的模式。

可以使用如下SQL查看当前会话等待的enqueue名称和类型（当然，这里的视图不仅仅可以是v$session_wait，只要包含p1的值即可，比如v$session、DBA_HIST_ACTIVE_SESS_HISTORY等视图）：

SELECT   CHR (TO_CHAR (BITAND (P1, -16777216)) / 16777215)

         || CHR (TO_CHAR (BITAND (P1, 16711680)) / 65535)

            "LOCK",

         TO_CHAR (BITAND (P1, 65535)) "MODE"

  FROM   V$SESSION_WAIT

WHERE   EVENT = 'ENQUEUE'

Oracle 的enqueue 包含以下模式：

Oracle的enqueue有如下类型：

所有队列等待锁：

3.1.1  Enq数据字典

受到排队锁影响的数据库资源，我们称之为"排队资源"。Oracle使用内部数组结构来处理排队资源，可以通过x$ksqrs(内核服务排队资源)或v$resource视图来查看。

SELECT S.ADDR, S.TYPE, S.ID1, S.ID2 FROM V$RESOURCE S;

SELECT * FROM x$ksqrs;

v$resource_limit视图可查看排队锁资源的总体使用情况。查询系统资源的使用情况：

SELECT S.RESOURCE_NAME,

       S.CURRENT_UTILIZATION AS "当前使用数",

       S.MAX_UTILIZATION     AS "系统最大使用数",

       S.INITIAL_ALLOCATION  AS "系统初始化参数分配数",

       S.LIMIT_VALUE

  FROM V$RESOURCE_LIMIT S

 WHERE S.RESOURCE_NAME IN ('enqueue_resources',

                           'enqueue_locks',

                           'dml_locks',

                           'processes',

                           'processes');

排队锁使用单独的数组而不是排队资源数组来管理排队锁，通过查询x$ksqeq(内核服务排队对象)或v$enqueue_lock视图来看到这种结构。

v$equeue_lock视图(除TX和TM锁)

SELECT S.ADDR,

       S.KADDR,

       S.SID,

       S.TYPE,

       S.ID1,

       S.ID2,

       S.LMODE,

       S.REQUEST,

       S.CTIME,

       S.BLOCK

  FROM V$ENQUEUE_LOCK S;

从equeue等待事件中，解码排队类型及模式：

SELECT s.sid,

s.event,

s.p1,

s.p1raw,

chr(bitand(s.p1, -16777216) / 16777215) ||

chr(bitand(s.p1, 16711680) / 65535) AS "TYPE",

MOD(s.p1, 16) AS "MODE"

FROM v$session_wait s

WHERE s.event = 'enqueue'；

V$ENQUEUE_STATISTICS用于显示队列锁的统计数据：

V$ENQUEUE_STATISTICS displays statistics on the number of enqueue (lock) requests for each type of lock. V$ENQUEUE_STATISTICS encompasses V$ENQUEUE_STATand gives more detailed information (several rows for same enqueues with different reasons).

其视图结构定义如下：

SELECT st.inst_id, eqt.NAME, st.ksqsttyp, st.ksqstrsn, st.ksqstreq,

      st.ksqstwat, st.ksqstsgt, st.ksqstfgt, st.ksqstwtm, st.ksqstexpl,

      st.ksqstevidx

  FROM xksqstst,xksqstst,xksqeqtyp eqt

 WHERE (st.inst_id = eqt.inst_id)

  AND (st.ksqsttyp = eqt.resname)

  AND (st.indx > 0);

这里包含了非常重要的一个信息，就是锁定及其描述：

SELECT d.EQ_NAME, d.EQ_TYPE,d.REQ_REASON, d.REQ_DESCRIPTION FROM V$ENQUEUE_STATISTICS d;

SELECT * FROM V$ENQUEUE_STATISTICS;

SELECT * FROM V$ENQUEUE_LOCK;

SELECT * FROM V$ENQUEUE_STAT;

3.2  enq: AE - lock

SELECT * FROM V$EVENT_NAME WHERE NAME  LIKE 'enq: AE%';

从Oracle Database 11g开始，除了每个文件要获得MR锁之外，每个登录数据库的会话现在都会缺省获得一个AE锁：

3.3  enq: MR锁

SELECT * FROM V$EVENT_NAME WHERE NAME  LIKE 'enq: MR%';

可能很多朋友都注意过，在V$LOCK视图中，最常见的其实是MR锁，也就是介质恢复锁（Media Recovery）：

MR锁用于保护数据库文件，使得文件在数据库打开、表空间Online时不能执行恢复。当进程对数据文件执行恢复时，需要排他的获得MR锁。当数据库打开时，每个文件上都分配一个MR锁。注意在以上输出中ID1代表文件号，其中也包含了201号临时文件。

3.4  enq: DX - contention

SELECT * FROM V$EVENT_NAME WHERE NAME = 'enq: DX - contention';

DX：Distributed transaction entry

enq: DX - contention是一个分布式事务锁。

enq: DX - contention 和inactive transaction branch这两个事件是相伴的。这两个等待事件是和DBLINK相关的，metalink上有相关的文章：High CPU by Sessions Holding DX Enqueue; Others Waiting 'enq: DX - contention' [ID 1275884.1]

大意就是执行dblink语句时候，由于人为取消终止或网络等问题导致语句触发上面的等待事件

在Oracle中enq: DX 队列锁一般用意保护分布式事务(used to protect distributed transactions)，对应的就存在 enq: DX – contention等待事件。

Id1 / Id2 含义

id2总是0。id1 代表其希望锁定的记录，所以总是distributed transaction elements队列中的一个条记录数（一个整数），由实例参数”distributed_transactions”决定。

3.4.1  案例

http://www.ssc.stn.sh.cn/html/zsk/ITyw/2012-04/5793.html

http://blog.itpub.net/4227/viewspace-709121/

http://www.codeweblog.com/oracle-enq-dx-contention-of-the-resolution-process/

3.5  enq: SQ - contention 序列等待

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

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。

在下面的链接中讲到了RAC 之间序列同步:

       Sequences in Oracle 10g RAC

       http://www.pythian.com/news/383/sequences-in-oracle-10g-rac/

How does RAC synchronize sequences?

In Oracle 10g RAC, if you specify the “ordered” clause for a sequence, then a global lock is allocated by the node when you access the sequence.

This lock acquisition happens only at the first sequence access for the node (A), and subsequent uses of the sequence do not wait on this lock. If another node (B) selects from that sequence, it requests the same global lock and once acquired it returns the sequence's next value.

The wait event associated with this activity is recorded as “events in waitclass Other” when looked in gv$system_event. So much for event groups, it couldn't be more obscure. That view shows overall statistics for the session.

However if you look in the gv$session_wait_history it shows as “DFS lock handle” with the “p1″ parameter been the object_id of the sequence. This second view has a sample of the last 10 wait events for a session.

In a SQL_TRACE with waitevents (10046 trace) it will be a “DFS lock handle” but in AWR or statspack reports it will be “events in wait class Other”. So much for consistency.

3.5.1  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.

The session needs to get the lock handle.

该等待事件的发生，若不是SV锁的话，多半为bug引起。

DFS lock handle"这一event是在RAC环境中，会话等待获取一个全局锁的句柄时产生的。在RAC中，全局锁的句柄是由DLM(Distributed Lock Manager 分布式锁管理器)所管理和分配的。大量发生这一event说明全局锁句柄资源不够分配了。决定DLM锁数量的参数是_lm_locks，9i以后，它是一个隐含参数，默认值是12000。没有特殊情况，这一值对于一个OLTP系统来说是足够的。我们不能盲目地直接增加资源，而是需要找到导致资源紧张的根本原因。锁资源紧张，说明存在大量事务获取了锁，但是事务没有提交、回滚。那么，又是什么导致了这些事务不结束呢?应用程序代码不完善，没有提交事务?或者那些事务还在等待别的资源?

3.5.2  我碰到的案例

【故障处理】序列cache值过小导致CPU利用率过高 ：http://blog.itpub.net/26736162/viewspace-2123996/

  About Me

小麦苗出品，实用经典，简单易懂，接地气！-----技术应用型博客，主打实用性，只讲实用的，不讲没用的，多做实验，多思考！ QQ：642808185 网名：小麦苗 blog：http://blog.itpub.net/26736162 微信公众号:xiaomaimiaolhr QQ群:230161599