数据库优化案例——————某市中心医院HIS系统

系统环境首先我们来看一下这个系统配置及现状为什么说这个客户经典那就是因为这个客户已经达到可以慢的地方都慢不该慢的地方也慢首先这是一套医院的HIS系统慢到什么程度呢各种功能卡死不管是交款、医嘱、开药一些列几乎所有的功能都慢。但是卡慢的现象只出现在上午的高峰期先来看看系统配置 数据库版本是SQL SERVER 2008R2数据量大概1个多T服务器64CPU 、128G内存服务器只运行数据库。咋一看服务器确实有点老了数据量也大了内存和CPU什么的明显不够用了数据库指标那么我们再看一下数据库的一些表象每秒请求数量语句执行情况等待情况等待时间CPU指标内存一些指标磁盘队列-------------------还很多指标就不一一展示了------------------看到这些基本的指标除了慢你能看出什么问题出在哪里怎么样快速解决能有一个优化的步骤呈现在眼前么优化阶段一常规优化很多时候系统慢要究其原因难道上线时候就这么慢那不可能厂商根本无法交付的那么问题来了什么时候开始慢的对系统做过哪些调整简单的调研开始...给我的只有不到半天的调研时间...得知的基本问题就是系统在最近一月增加了很多功能有上线了很多其他系统接口那么直接就搞新功能、新程序接口语句 我认为并不是这样从一名数据库从业人员来说看到这样的系统一定要先解决大面积等待问题个人经验来看很多系统大面积等待解决系统会有个很大的提升和改善配合一些常规的调优手段阶段一开始了,主要给系统大面积创建影响高开销大的索引调整系统参数优化tempDB、开启快照读等....具体不细说了前面系列文章中都有预期一般系统上面一轮优化会有明显的改善我认为这一轮以后系统会明显变快语句CPU会下降到70%左右内存压力也会有所减少。结果自信满满的我第二天去了各个科室....部分功能依然超时还是各种慢...CPU依然90%以上内存压力依然明显。但是收集的数据来看长时间语句数量已经大幅降低系统等待阻塞情况也明显好转。优化前优化后优化前优化后优化阶段二针对语句再次分析解决大面积语句阻塞的系统发现现在的情况主要有如下几个由于内存不足导致的IO压力。系统CPU依然彪高。部分功能语句依然慢消耗的资源很高。再次对系统调研哪些功能慢执行的语句是什么。系统的接口语句问题。系统中还有哪些消耗资源高的语句是否能优化。调研后我遇到了最常见也是最大的问题 语句慢由于程序很多人看到这会说程序慢就改呗那有啥问题 问题就在于你来做优化直接了当的和人家开发人员说你程序太烂必须改如果你是程序开发人员你会有什么样的反应他会说对不起影响太大改不了那么这个优化项目黄了或者你要付出更大的代价绕过这样的问题。分析中发现程序使用了大量各种自定义函数有一定经验的人都应该知道语句在筛选的列上使用函数是没有办法使用索引查找的这样相对于这种单表数据就几百甚至几千万的表是何等的灾难但是不能冒然突出修改程序那还能怎么优化呢大概分析后得出结论程序主要消耗在几部分部分业务功能语句慢。接口语句慢主要是视图供其他程序调用。还有报表程序。