大连YDEY出差记录
2012-09-06 17:17
190 查看
过程:
本次出差去DYEY配合升级10.30的过程中,给我的总体感觉就是医院信息科能力的强大、专业,这是我从前接触用户中不多见的。由于这个原因,升级过程非常轻松顺利,升级过后虽然也出现了一些边缘模块的小问题,但是由于有研发同事的现场跟踪调试,都得到了立即的处理,而我负责的整体性能这块,通过观察也没有发现非常严重的问题,但是还是有一些SQL语句对性能消耗比较突出,导致系统性能下降,主要集中在以下2点:
1.高频SQL的系统整体性能的影响
通过医院业务高峰期的AWR报告观察,整个医院的性能比升级前还是有所下降,通过分析,发现主要表现在逻辑读增大,原因是一条药品发药刷新的高频SQL性能不好导致,如下:
调整前的性能报告:
通过28号早高峰(9点~10点)的性能报告可以看到,医院的逻辑读每秒有30W,DB TIME达到了300分钟,这些都比升级前有所提高,再分析逻辑读最高的SQL语句,可以发现主要集中在药品发药刷新和体检的一条求和SQL语句上,如下:
通过分析我们发现,这些SQL语句都加了RULE规则,而在目前的CBO环境下,统计信息收集准确,走成本的执行计划效率要优于规则很多,因此我联系了研发人员,请他们把强制规则取消,然后再行观察。
调整后的性能报告:
调整后,第二天的同样时段的高峰期(29号9~10点),逻辑读已经下降到16W,DB TIME也只有199分钟,基本和医院升级前整体性能持平,之前的高频SQL也没有再出现在逻辑读前列的SQL列表中,孙工对于调整后的性能也比较满意。
2.个别子系统的模块SQL影响性能
除了前面提到的高频SQL,在前面的SQL列表中,体检的SQL语句排在性能消耗的前列,而且体检模块的使用本身并不频繁,而他的SQL会出现在这里就表示这条SQL语句确实存在比较严重的性能问题,事实也确实如此。最后我和孙工通过查看分析,给出调整建议后联系研发人员对这些SQL进行调整。
总结:
本次出差归来,给我的总体感觉就是少有的难得轻松,归纳出原因主要有以下几点:
做得比较好的:
1.医院信息科能力的强大,前期升级测试、升级过程都由医院自行完成,而且测试仔细,升级谨慎。
2.公司对医院的全力支持,出现问题都得到第一时间的处理,医院都非常的感动。
做得不好的:
1.程序中SQL语句的性能是影响每次升级性能下降的主要因素,如何有效的规范程序员SQL的书写和性能测试,是以后研发应该重点思考的问题。
2.高频SQL对性能的影响确实很大,需要引起足够的重视,还是应该建立机制进行重点关注。
程序SQL语句中的强制Rule是否有更好的处理方式,便用现场处理,提高效率。
本次出差去DYEY配合升级10.30的过程中,给我的总体感觉就是医院信息科能力的强大、专业,这是我从前接触用户中不多见的。由于这个原因,升级过程非常轻松顺利,升级过后虽然也出现了一些边缘模块的小问题,但是由于有研发同事的现场跟踪调试,都得到了立即的处理,而我负责的整体性能这块,通过观察也没有发现非常严重的问题,但是还是有一些SQL语句对性能消耗比较突出,导致系统性能下降,主要集中在以下2点:
1.高频SQL的系统整体性能的影响
通过医院业务高峰期的AWR报告观察,整个医院的性能比升级前还是有所下降,通过分析,发现主要表现在逻辑读增大,原因是一条药品发药刷新的高频SQL性能不好导致,如下:
调整前的性能报告:
通过28号早高峰(9点~10点)的性能报告可以看到,医院的逻辑读每秒有30W,DB TIME达到了300分钟,这些都比升级前有所提高,再分析逻辑读最高的SQL语句,可以发现主要集中在药品发药刷新和体检的一条求和SQL语句上,如下:
通过分析我们发现,这些SQL语句都加了RULE规则,而在目前的CBO环境下,统计信息收集准确,走成本的执行计划效率要优于规则很多,因此我联系了研发人员,请他们把强制规则取消,然后再行观察。
调整后的性能报告:
调整后,第二天的同样时段的高峰期(29号9~10点),逻辑读已经下降到16W,DB TIME也只有199分钟,基本和医院升级前整体性能持平,之前的高频SQL也没有再出现在逻辑读前列的SQL列表中,孙工对于调整后的性能也比较满意。
2.个别子系统的模块SQL影响性能
除了前面提到的高频SQL,在前面的SQL列表中,体检的SQL语句排在性能消耗的前列,而且体检模块的使用本身并不频繁,而他的SQL会出现在这里就表示这条SQL语句确实存在比较严重的性能问题,事实也确实如此。最后我和孙工通过查看分析,给出调整建议后联系研发人员对这些SQL进行调整。
总结:
本次出差归来,给我的总体感觉就是少有的难得轻松,归纳出原因主要有以下几点:
做得比较好的:
1.医院信息科能力的强大,前期升级测试、升级过程都由医院自行完成,而且测试仔细,升级谨慎。
2.公司对医院的全力支持,出现问题都得到第一时间的处理,医院都非常的感动。
做得不好的:
1.程序中SQL语句的性能是影响每次升级性能下降的主要因素,如何有效的规范程序员SQL的书写和性能测试,是以后研发应该重点思考的问题。
2.高频SQL对性能的影响确实很大,需要引起足够的重视,还是应该建立机制进行重点关注。
程序SQL语句中的强制Rule是否有更好的处理方式,便用现场处理,提高效率。
相关文章推荐
- 硅谷出差行程记录
- 考勤管理中出差记录写入Excel文件
- 上周末出差大连之行
- 出差记录
- 合肥出差记录
- 大连到日本出差/旅游注意事项
- 记录一次出差广东对中间件性能优化的完整报告
- 中层副层以下的有C6人员必须在报销时关联出差记录对比。
- 合肥出差记录
- 大连到日本出差/旅游注意事项
- 大连出差最大的收获
- 大连出差感想
- 写了一个分页存储过程把总记录数也写到返回表的每行了
- JDK+TOMCAT的配置记录
- 在SQL中删除重复记录(多种方法)
- 正则表达式学习记录-处理选项
- python的一些函数用法记录
- <select> 标签使用记录心得
- PowerShell定时记录操作系统行为 推荐
- 记录规则 – 销售只能看到自己的客户,经理可以看到全部