oracle seq等待事件,AWR分析之DFS lock handle等待事件 | 信春哥，系统稳，闭眼上线不回滚！...

在给客户巡检时发现DFS lock handle等待事件。

在RAC环境中，会话等待获取一个全局锁的句柄时产生DFS lock handle等待事件，这个等待事件通常和sequence有关，如果2个实例都有并发的session使用sequence，这时有可能遭遇 DFS LOCK HANDLE等待事件。

ORACLE为了在RAC环境下为了sequence的一致性，使用了三种锁：row cache lock、SQ锁、SV锁。

row cache lock:在调用sequence.nextval过程中，将数据字典信息进行物理修改时获取，赋予了nocache属性的sequence上有可能会发生,目的是在sequence指定nocache的情况下调用sequence.nextval过程中保证序列的顺序性。

SQ锁：在内存上缓存(cache)范围内，调用sequence.nextval期间拥有此锁，赋予了cache+noorder 属性的sequence上可能会发生。当多个用户同时访问一个sequence的时候，是在oracle SGA中读取sequence当前的合理数值(cache范围内的值)，如果并发访问太大，cache的大小不够，那么就会产生sequence cache相关的等待事件enq: SQ – contention。

SV锁：RAC上节点之间如果要保障sequence的顺序，必须给sequence赋予cache+order属性，调用sequence.nextval期间有可能会发生DFS lock handle等待事件。

若没有给sequence赋予ORDER属性，则各节点将会把不同范围的Sequence值CACHE到内存上，比如拥有两个节点的RAC环境下，创建CACHE值为20的 sequence时，1节点会使用1-20，2节点会使用21-40。 使用时从各自节点取sequence，这样就导致sequence所在字段数据顺序不是连续的，如果要求sequence所在字段的数据连续，就必须给sequence赋予ORDER属性。

下面是相关实验。

实验一：NOORDER属性，RAC两个节点使用各自CACHE范围内的sequence值。

实例1：

SQL> create sequence sq_test cache 20;

Sequence created.

SQL> select sq_test.nextval from dual;

NEXTVAL

----------

1

实例2：

SQL> select sq_test.nextval from dual;

NEXTVAL

----------

21

默认情况下，sequence是NOORDER属性，而且两个实例分别分配了各自的cache，两个实例使用自己的cache，这样sequence所在字段的数据不是按sequence顺序存放的。

实验二：ORDER属性，RAC两个节点使用同一个CACHE。

实例1：

SQL> drop sequence sq_test;

Sequence dropped.

SQL> create sequence sq_test cache 20 order;

Sequence created.

SQL> select sq_test.nextval from dual;

NEXTVAL

----------

1

实例2：

SQL> select sq_test.nextval from dual;

NEXTVAL

----------

2

可见，ORDER属性的sequence，RAC各个节点使用公用的CACHE，这样各节点之间就需要进行大量的数据交换，可能会级联产生相关的gc等待事件，影响性能。