针对enq: TX - row lock contention等待事件进行进一步分析，看一下对应sql是否有什么问题

看看这个存储过程是否有问题?

Call Zl_¹ÒºÅÐòºÅ״̬_Lock(:V001, :V002, :V003, :V004, :V005, :V006)'

从AWR来看，数据库在该时段并无明显的性能问题，数据库和操作系统资源使用及负载很低，也没有特别严重的影响性能的SQL语句。建议从客户方获取更加详细的反馈信息，同时关注报告中前几条SQL语句，看看能不能进一步优化。

首先第一个问题，也是大多数医院HIS系统的问题，表名，SQL中存在中文，导致SQL的version count非常高，这直接影响了SQL的执行效率，这个问题应该一直存在。

而反应比平常慢，应该是文成说的，zlSocketServices.exe程序调用存储过程执行bdvtt3s520dww这个update语句时锁表了，所以前台很感觉到很卡。

可以上传一个其他日期相同时间段的AWR做下对比分析。

今天上午也同样出现了卡顿状况，我看打的几个报告上这次显示的就比较明显了，新上传的附件大家可以帮看看

根据TOP 事件 找db file sequential read
enq: TX - row lock contention 定位产生dbfile顺序读取和行锁等待的sql语句

第一：分析sql_id 为avrqtgw6kxcr1 是否没有走索引而全表扫描了。查看查看改SQL执行计划，添加索引或者优化SQL。
第二:分析sql_id为bdvtt3s520dww UPDATE语句产生了行锁等待，没有及时提交，释放锁。研究应用逻辑。
第三:分析sql_id 为d92z6f9q6znmg Call Zl_挂号序号状态_Lock(:V001, :V002, :V003, :V004, :V005, :V006) 详细代码调试是否有问题