DFS lock handle & latch free

下图是高峰时段数据库中前五项等待事件：
[img]http://www.orasql.com/bbs/download/file.php?id=57[/img]

通过上面top5 event可以看出系统在业务高峰期间，DFS lock handle和latch free分别排在第二和第三，占用了23%的DB time，通常情况下是不正常的，应用程序逻辑或者应用SQL可能存在问题，影响数据库性能。
DFS lock handle：这一event是在RAC环境中，会话等待获取一个全局锁的句柄时产生的。在RAC中，全局锁的句柄是由DLM(Distributed Lock Manager 分布式锁管理器)所管理和分配的。大量发生这一event说明全局锁句柄资源不够分配了。决定DLM锁数量的参数是_lm_locks，9i以后，它是一个隐含参数，默认值是12000。没有特殊情况，这一值对于一个OLTP系统来说是足够的。所以不能盲目地直接增加资源，而是需要找到导致资源紧张的根本原因。锁资源紧张，说明存在大量事务获取了锁，但是事务没有提交、回滚。一般会存在某个事务导致锁资源紧张，可以看出在top5 event中有另外一个等待事件：latch free。
Latch Free：当进程想要获取锁存器而此时该锁存器正被其他进程持有时产生Latch Free(锁存器空闲)等待事件，类似于排队，Oracle使用锁存器来保护数据结构。一次只能在一个进程在获得锁存器后修改或检查数据结构。其他需要访问该数据结构的进程必须等待，直到它们获得锁存器后才可以进行操作。
从该时段实例1的ASH视图中以这2个等待事件为条件查询，从下图可以看出在业务高峰期的3小时内，一个节点出现DFS lock handle 等待事件500多次，LATCH FREE等待事件400多次，且引起这2个等待事件的SQL 90%为6zqqgm5k6nyt6。从总的等待时间来看，数据库在等待事件LATCH FREE上消耗大量时间，大量的锁资源申请，从而引起DFS lock handle事件。

[img]http://www.orasql.com/bbs/download/file.php?id=58[/img]

通过SQL_ID查询到排名靠前的SQL如下：

SELECT UNICARD_NO FROM TF_R_UNICARD WHERE PRESENT_TAG = '0' AND LIMIT_DATE + 0 > SYSDATE + 90 AND UNICARD_STATE||NULL = '0' AND UNICARD_VALCODE||NULL = :B3 AND ROWNUM <= :B2 AND RESERVED1 = :B1 AND (RESERVED2 <> '99' OR RESERVED2 IS NULL) FOR UPDATE

SQL的执行计划如下：

[img]http://www.orasql.com/bbs/download/file.php?id=59[/img]

看到SQL有一个FOR UPDATE的操作，每次执行都会申请一个行级锁，另外从执行计划看有PX操作，业务高峰期频繁的执行引起LATCH FREE和DFS lock handle等待事件，影响到数据库性能。
针对这个SQL，一是不让它走并行。另外如果是执行一次引起多个行级锁，那么增加where条件，尽量减少锁资源的浪费。如果每次只会产生一个行级锁，SQL本身的优化空间不大，建议尽量减少事务处理时间，优化事务处理过程，尽早将事务提交或者回滚，从而加快锁资源释放的速度，提升数据库性能。