吵吵   2014-10-27  阅读:1,707

近来,科里面的同事反应,LIS运行的越来越慢了。

查来查去,依旧是有很多的的阻塞,这个问题我已经设置过自动脚本来杀阻塞进程了,这个问题请出门左转找历史文章。

心想着SQL SERVER数据库当真是不如oracle啊,才这么点数据量就不行了?才54G啊。

每次进入服务器,看到cpu的使用率不过百分之十,并发链接才1k多,就觉得不应该啊,肯定是某些地方出问题了,听说连京东商城都用的微软的数据库,应该不至于这么弱。

于是呼,网上找了本DBA的书来瞧了瞧两天,之后再来分析数据库。

1、写错了SQL语句。

在进程阻塞查杀日志中看到被查杀进程极易阻塞的语句:

kill 132 [SQLSTATE 01000]
EventType Parameters EventInfo

Language Event 0 SELECT patients.pat_id , patients.pat_mid , patients.pat_sid , patients.pat_name , patients.pat_sex , patients.pat_age , patients.pat_d_name , patients.pat_in_no , ….. char(4) as tat FROM patients , depart , lis_user_vs_stype WHERE ( patients.pat_d_name = depart.dep_name ) and ( patients.pat_mid = lis_user_vs_stype.stype ) and ( ( lis_user_vs_stype.uname = ‘xxx’ ) and ( patients.pat_priority_indicator = 2 ) and ( patients.pat_flg = 0 ) )
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。 [SQLSTATE 01000]

仔细一看这个SQL语句,这明明就是LIS系统用于监控急救标本的查询语句,实验室为了能够及时的处理急救标本,LIS系统每隔1分钟就会查询一次数据库,看看有没有急救的标本送来,有就弹窗提示。

这个业务流程原本没有什么问题,但是写sql的工程师啊,没有加时间条件,等于把patiens这张几千万条记录的主表,每隔一分钟全部都扫描一次,几十个客户端,一起来刷,能不慢么?处理方法就是加上索引条件如:pat_date kill 462 [SQLSTATE 01000]
EventType Parameters EventInfo
——— ———- ———————
RPC Event 0 sys.sp_cursorclose;1
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。 [SQLSTATE 01000]

后来问问惠桥的工程师,得到的回答是:系统中用游标太多了,多到,没法给你改。我了个去啊!

3、更多优化。

其实说到这里,剩下的东西都是我从书上看到了,没有实验过的了,不过我觉得在高并发情况下,优化数据库,应该是有用的,可惜不关我的事情了,哎。

1)垂直分割。将老一点的数据分开去,分割到其他库中去,不过这样子程序写起来就有些麻烦了。

2)横向分割。将一些大表进行分割。因为大部分的数据是用不到的,表分区是个很好的办法。

3)读写分离。这个是神器啊,将读写进行分离,可以有效降低查询的压力。

4)SSD硬盘。听说能够将IO的能力提升上百倍,呵呵,我们的LIS没有IO压力,写入速度才0.1M/S.

我们的数据库现在搞了个故障转移集群,这个家伙除了出故障有用,对提高数据库性能一点用处都木有。真心是郁闷了。

打开manage studio ,将维护计划中的每日维护添加几个大表的重建索引,就算告一段落吧。

我问:”老大,你知道DBA是什么吗?“

“哪个国家的篮球协会?”

吵吵微信朋友圈,请付款实名加入:

吵吵 吵吵

一条回应:“恵桥LIS数据库的性能调优”

  1. 明月说道:

    DBA,是个很专业的技术。你还有钻研劲!

发表评论

电子邮件地址不会被公开。 必填项已用*标注