吵吵   2014-04-24  阅读:1,502

上夜班是一个很痛苦的事情,如果夜班的时候网络还不稳定,那就是一个非常痛苦的事情。

但是服务器的维护和备份是一件不得不做的事情,而且最好的选择还是晚上负载小的时候。

因此,我一直在思考有没有途径来优化数据库,让上夜班的人员有一个比较流畅的体验。

我原来上夜班的时候,一到四点多的时候,网络就开始不稳定了,LIS会打不开,接口会掉线,整整一个多小时都是要死不活的过。从技术的角度来讲,维护和备份会降低性能,但是不可能会拒绝服务的,这一定是有某些问题。

找了半天发现是生成索引的问题,如下图所示的“重新生成索引”配置界面,如果我们不勾选“重建索引时保持索引联机”,将导致在20多分钟的索引重建的时间里面,我们压根没有办法用LIS了。

重新生成索引

勾选之后,服务器在建立索引期间会备份一份索引至tempdb里面,这个时候如果有访问,数据库会照常运行,测试起来也没有慢多少。

重建索引要耗费20多分钟,那么每天都建立索引有必要么?

我们可以通过这个命令来看碎片的多少,以决定我们是否需要重新建立索引:
DBCC SHOWCONTIG(patients)

DBCC SHOWCONTIG 正在扫描’patients’ 表…
表: ‘patients’ (1842105603);索引ID: 0,数据库ID: 8
已执行TABLE 级别的扫描。
– 扫描页数…………………………..: 257808
– 扫描区数…………………………: 32275
– 区切换次数…………………………: 32274
– 每个区的平均页数……………………: 8.0
– 扫描密度[最佳计数:实际计数]…….: 99.85% [32226:32275]
– 区扫描碎片………………: 94.44%
– 每页的平均可用字节数…………………: 616.9
– 平均页密度(满)…………………: 92.38%
DBCC 执行完毕。如果DBCC 输出了错误信息,请与系统管理员联系。

从上面的输出来看,磁盘的密度达 92.38%,我们压根就没有必要重新建立索引。

因此,最终我使用了以下策略来优化LIS数据库:

1、“重建索引时保持索引联机”,将重建索引变成了一个月一次。

2、将完整备份改为每周一次的完整备份,和每日一次的差异备份。

3、考虑到服务器的cpu使用率不高,备份选择“压缩”。备份数据减小,备份速度加快。

4、采用独立的磁盘整列,用于数据库备份,这样子此盘写入的速度,那叫一个飞快啊。

通过以上的改进,数据库维护得到优化,只有每周四完整备份的时候,LIS会变的慢一点,其它日子就压根没有感觉了!

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

吵吵 吵吵

发表评论

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