DFS lock handle waiting for an event

RAC environment very frequent use of sequence (sequence). Then ' the DFS Lock handle ' wait events often occur. 

The usual approach is to increase the cache sequence without using the sort option that is NOORDER. 

The default when creating a sequence cache 20, the non-sort NOORDER. 
By following statement update sequence cache: 

ALTER Sequence SEQ_name cache 200 is ; 
 

 

the RAC and Sequences [ ID 853,652.1 ] in the passage: 

 

the When Caching + Ordering IS Used and the RAC IS Enabled (cluster_database = to true), 
 the then The Wanting the session to GET a NEXTVAL The of A Sequence need to GET
an exclusive instance SV lock before inserting or updating the sequence values 
in the the shared pool. When multiple sessions want the nextval of the same sequence,
then some sessions will wait on 'DFS lock handle' waitevent with id1 equal to 
the sequence number.

========================================================================================

If you are using Oracle sequences very frequently in a RAC environment,

most often you will see that one of the most timed events is “DFS Lock Handle”.

Commonly you should set the sequence to have a larger cache size and with the NOORDER option, which is the default,

for best performance.

 

Performance of combined options worst to best:

• NOCACHE with ORDER
• NOCACHE with NOORDER
• CACHE with ORDER
• CACHE with NORTH

Few more things to note

• High volume insert intensive applications using Sequence generated keys add extra overhead
  NOCACHE is the worst for performance
• CACHE NOORDER is the best for performance
• Services may help improve performance even for CACHE NOORDER sequences if the insert application uses a service with only one Preferred Instance.
• This eliminates the Interconnect traffic and synchronisation overhead required to coordinate the next value from amongst all the instances when using CACHE ORDER