大连YDEY出差记录

过程：

本次出差去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是否有更好的处理方式，便用现场处理，提高效率。