用户名:   自动登录 找回密码
密   码:    * 注册




发表新帖 回复这个主题  [ 1 篇帖子 ] 
作者 内容
 文章标题 : DFS lock handle & latch free
帖子发表于 : 2013-04-13 21:36 
离线
头像

注册: 2011-05-01 9:15
帖子: 120
下图是高峰时段数据库中前五项等待事件:
附件:
1.jpg
1.jpg [ 38.23 KiB | 被浏览 12421 次 ]

通过上面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事件。

附件:
2.jpg
2.jpg [ 81.21 KiB | 被浏览 12421 次 ]


通过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的执行计划如下:
附件:
3.jpg
3.jpg [ 74.38 KiB | 被浏览 12421 次 ]


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


页首
 用户资料  
 
显示帖子 :  排序  
发表新帖 回复这个主题  [ 1 篇帖子 ] 


在线用户

注册用户: 没有注册用户


查找:
前往 :  
cron
Powered by OraSql © 2011, 2012, oracle_awen