2011年2月--2011年7月数据库性能优化过程

开始暴露问题
    2011年2月下旬的一天早上,昨天更新的系统,早上发现数据库的服务器CPU达到100%,而且持续的时间很长,不得回到昨天更新前的版本,但系统还是有较长时间达到100%的情况,问题没有解决,从这正式开始优化线上数据库性能。
 
第一阶段优化
   分析问题:
    一开始老是想找出问题的原因,找了3天还没有头绪,列出以下原因:
   1,JOB的耗时存储过程  --太频繁,执行时间长,1,2分钟
   2,频繁执行同样的SQL  --如查询用户表sys_user 几分钟内执行数千次
   3,tempdb太小
   4,运行SQL太慢
   5,数据库阻塞
     但这些原因,都找不出具体的在那块有问题,好像都有,又好像都没有,时间在一天天过去,但是系统还是100%经常发生,严重影响业务使用,这时只能按照以前的优化经验调整优化思路,不找原因,只要是问题就优化,一个一个处理掉,最终解决系统性能问题
 主要是执行优化方法:
  1,删除全部的主键聚集索引,改成唯一非聚集索引
  2,删除重建全部索引
  3,删除全部外键约束
  4,持续优化SQL
  5,使用行版本隔离级别
  6,根据SQL建立索引
  7,安装SQL 2008 SP2补丁

  8,禁止读取大量数据未分页的SQL,读出数据必须分页50条。

 

第二阶段优化
  经过一个多月的优化,比以前稳定一些,但系统100%的情况还有发生,这时分析下来,可能存在一些原因:
   1,高并发
   2,严重系统缺陷
   3,死锁
   4,缓存问题
   5,循环调用SQL
   6,长事务
   7,未优化的SQL
  为跟踪以上出现的SQL,发现以前用的DMVS性能分析视图远远不够,必须使用SQL Profile等其他工具,这期间的确进步很大
   1,使用SQL Profile监控工具监控高耗CPU的SQL
   2,发现长事务,并优化程序和SQL缺陷
   3,发现SQL事务中的执行语句停顿问题
   4,跟踪引起死锁SQL,并分析死锁原因和优化
   5,使用windows的性能工具分析CPU,Reads发现系统问题
   6,使用SSRS和windows的性能工具每天发送CPU跟踪报表。
   

 第三阶段优化
    经过一,二阶段优化,系统100%比以前的少了很多,但有一天,看SSRS的CPU报表,突然CPU暴涨到100%,而且第二天还有,通过Profile发现是因为缓存更新的原因,由于后台修改数据会触发缓存更新,一旦后台大量更新数据时,前台就会更新大量缓存,这样一来就要很多个SQL请求,CPU就会暴涨到100%,后来修改了程序缓存策略,该问题解决。

    经过这三轮的优化,系统的性能比以前有了明显的改善,系统100%的情况极少。经过这几个月优化,彻底发现以前的知识和经验不足,并一度怀疑自己的能力,为何以前优化系统,1,2个月就大概全部搞定,这次花了这么长时间,可能情况不一样,系统的复杂程度也不一样吧!

  2011年3月3日CPU的趋势图

 

  2011年5月3日CPU的趋势图

 

    2011年7月7日CPU的趋势图

  

 

posted @ 2012-01-12 16:45  zping  阅读(553)  评论(0编辑  收藏  举报