dictionary cache —— row cache lock/enq: SQ - contention/DFS lock handle

row cache lock

oracle将数据字典信息存于SGA内的行高速缓冲区（或dictionary cache）。行高速缓冲区位于共享池区域，可通过如下命令进行确认。

SQL> select * from v$sgastat where name = 'row cache';

POOL	     NAME			     BYTES
------------ -------------------------- ----------
shared pool  row cache			   7584808

想要修改数据字典内容的进程，应对其相应的row cache object获得row cache lock。

SQL> select name,parameter1,parameter2,parameter3 from v$event_name where name like 'row cache lock';

NAME                           PARAMETER1           PARAMETER2           PARAMETER3
------------------------------ -------------------- -------------------- --------------------
row cache lock                 cache id             mode                 request

其中最具代表性的是sequence，在获取sequence的nextval过程中需要修改数据字典信息时，应该对row cache object以SSX获得row cache lock。SSX模式之间因为不存在共享性，所以多个进程同时对相同sequence调用nextval时，发生对于row cache lock的争用。若在获取row cache lock过程中发生争用，则等待row cache lock事件。
许多进程同时使用没有赋予cache属性的sequence时，可能大量发生row cache lock事件等待。对没有使用cache的sequence，如果调用nextval，则每次数据字典信息都应该被修改，所以应该以SSX模式获得row cache lock。因为SSX之间不存在共享性，所以在此过程中发生争用。

除了sequence之外，几乎没有如此频繁的修改行高速缓冲区信息的。因此，出现row cache等待时，需要确认sequence上是否赋予了nocache属性。赋予cache属性的sequence上，不会发生row cache lock争用引起的性能问题。

 

enq: SQ - contention

Oracle为了管理sequence使用了以下三种锁：
row cache lock：在调用sequence.nextval过程中，将数据字典信息进行修改时获取。赋予了nocache属性的sequence上发生。
SQ锁：在内存上cache的范围内，调用sequence.nextval期间拥有次锁。赋予了cache属性的sequence上发生。
SV锁：rac上节点之间顺序得到保障的情况下，调用sequence.nextval期间拥有。赋予了cache+order属性的sequence上发生。

赋予了cache属性的sequence调用nextval期间，应该以SSX模式获得SQ锁。许多session同时为了获取SQ锁而发生争用过程中，若发生争用，则等待enq: SQ - contention事件。

SQL> select name,parameter1,parameter2,parameter3 from v$event_name where name like 'enq: SQ - contention';

NAME			       PARAMETER1      PARAMETER2      PARAMETER3
------------------------------ --------------- --------------- ---------------
enq: SQ - contention	       name|mode       object #        0

创建sequence赋予的cache值较小时，有enq: SQ - contention等待增加的趋势。

 

DFS lock handle

rac上创建sequence时，在赋予了cache属性的状态下，若没有赋予order属性，则各节点将会把不同范围的sequence值cache到内存上。比如，拥有两个节点的rac环境下，创建cache值为100的sequence时，1号节点使用1~100，2号节点使用101~200.若两个节点之间都通过递增方式使用sequence，必须赋予如下order属性。

create sequence order_sequence cache 100 order;

SQL> select name,parameter1,parameter2,parameter3 from v$event_name where name like 'DFS lock handle';

NAME			       PARAMETER1      PARAMETER2      PARAMETER3
------------------------------ --------------- --------------- ---------------
DFS lock handle 	       type|mode       id1	       id2

如果是已赋予了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 锁争用问题发生时的解决方法与SQ 锁的情况相同，就是将CACHE 值进行适当调整，这也是唯一的方法。

在RAC 等多节点环境下，Sequence 的CACHE 值给性能带来的影响比单节点环境更严重。因此，尽量赋予CACHE+NOORDER 属性，并要给予足够大的CACHE 值。如果需要保障顺序，必须赋予CACHE+ORDER 属性。但这时为了保障顺序，实例之间不断发生数据的交换。因此，与赋予了NOORODER属性的时候相比性能稍差。
有一点必须要注意，没有赋予CACHE 属性时，不管ORDER 属性使用与否或RAC 环境与否，一直等待row cache lock 事件。row cache lock 是可以在全局范围内使用的锁，单实例环境或多实例环境同样可以发生。根据创建Sequence时赋予的属性，整理等待事件的结果如下：

- NOCACHE: row cache lock
- CACHE+NOORDER: enq:SQ-contention
- CACHE+ORDER (RAC): DFS lock handle