enq:SQ-contention / DFS lock handle（SV）

Oracle 为了管理Sequence 使用了以下三种锁。

 

*  row cache lock : 在调用Sequnece.nextval 过程中，将数据字典信息进行物理修改时获取。赋予了NOCACHE 属性的Sequence 上发生。

*  SQ 锁 : 在内存上缓存（cache）的范围内，调用Sequence.nextval 期间拥有此锁。赋予了CACHE 属性的Sequence 上发生。

*  SV 锁 : RAC 上节点之间顺序得到保障的情况下，调用Sequence.nextval期间拥有。赋予了CACHE+ORDER 属性的Sequence 上发生。

 

      赋予了CACHE 属性的Sequence 调用nextval 期间，应该以SSX 模式获得SQ 锁。许多会话同时为了获取SQ 锁而发生争用过程中，若发生争用，则等待enq:SQ-contention 事件。enq:SQ-contention 事件的P2 值是Sequence 的OBJECT ID。因此，若利用P2 值与DBA_OBJECTS 的结合，就可以知道对哪个Sequence 发生了等待现象。

 

      创建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 等待问题。

 

      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 是可以在全局范围内使用的锁，单实例环境或多实例环境同样可以发生。根据创建Sequence时赋予的属性，整理等待事件的结果如下：

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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/21601207/viewspace-687277/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/21601207/viewspace-687277/