【案例讨论】从案例引发的对SQL Server性能调优的思考

dinglang_2009

yanyangtian4502 发表于 2012-5-17 08:40
咱们来谈谈内存管理吧

说到内存，确实让我比较纠结，有一下几个原因：

你敲代码，又搞架构，又研究数据库...你不怕太杂了？

finalarrow

Mark.

kinwar

请教下这个水平是怎么过度过来的？
还是只侧重于开发、管理、优化等等的哪一模块？
太多了记不了呢。。。

htyro

今天碰到一个很严重的问题，借这个帖子也说一下。

公司的MSSQL服务器在迁移之后，运行很慢，查询性能监控发现avg.disk queue length 的值居然达到了6000多，峰值在7000多，直接导致磁盘阵列的IO被占满。

将SQL服务停止之后，IO逐渐恢复正常，但是在重新启动服务之后，avg.disk queue length的值又逐渐增长，然后启动代理作业，队列的值以每秒100的速度往上直窜，到达6000多之后稳定，此次SQLSERVER数据库十分缓慢，报一堆833错误。

服务器是IBM的3650，内存也有16G，迁移之前是一台3850的机器，当然配置上要好一些，但3650上CPU和内存使用率都很低，为何会出现阵列IO被占满呢？

通过磁盘IO的测试工具测过阵列，速度都在300多MB每秒的读写。


借这个帖子也请教一下，该从哪个方面下手？

hwtong

htyro 发表于 2012-7-17 21:25
今天碰到一个很严重的问题，借这个帖子也说一下。

公司的MSSQL服务器在迁移之后，运行很慢，查询性能监控 ...

迁移之后,最好进行统计信息的更新下.
在维护计划中有这个task.
之后如果还是发现该性能指标很高,那么可以通过

1. SELECT SS.SUM_EXECUTION_COUNT,
   
2.                 T.TEXT,
   
3.                 SS.SUM_TOTAL_ELAPSED_TIME,
   
4.                 SS.SUM_TOTAL_WORKER_TIME,
   
5.                 SS.SUM_TOTAL_LOGICAL_READS,
   
6.                 SS.SUM_TOTAL_LOGICAL_WRITES
   
7. FROM (SELECT S.PLAN_HANDLE,
   
8.                          SUM(S.EXECUTION_COUNT) SUM_EXECUTION_COUNT,
   
9.                          SUM(S.TOTAL_ELAPSED_TIME) SUM_TOTAL_ELAPSED_TIME,
   
10.                          SUM(S.TOTAL_WORKER_TIME) SUM_TOTAL_WORKER_TIME,
    
11.                          SUM(S.TOTAL_LOGICAL_READS) SUM_TOTAL_LOGICAL_READS,
    
12.                          SUM(S.TOTAL_LOGICAL_WRITES) SUM_TOTAL_LOGICAL_WRITES
    
13.           FROM SYS.DM_EXEC_QUERY_STATS S
    
14.           GROUP BY S.PLAN_HANDLE
    
15.           ) AS SS
    
16.           CROSS APPLY SYS.DM_EXEC_SQL_TEXT(SS.PLAN_HANDLE) T
    
17. ORDER BY SUM_TOTAL_LOGICAL_READS DESC

复制代码

这个语句去查询哪些sql的逻辑读很高,之后进行优化.

hwtong

htyro 发表于 2012-7-17 21:25
今天碰到一个很严重的问题，借这个帖子也说一下。

公司的MSSQL服务器在迁移之后，运行很慢，查询性能监控 ...

当然我刚才的那个脚本是需要在sqlserver 2005及之上版本的数据库中才可以运行

htyro

hwtong 发表于 2012-7-18 08:43
迁移之后,最好进行统计信息的更新下.
在维护计划中有这个task.
之后如果还是发现该性能指标很高,那么可 ...

，问题基本上解决了，在更新了几个库的统计信息之后，目前服务器的IO峰值在200多，平时保持在20左右，所有的作业和传输已能正常运行。

怀疑是库里碎片太多导致查询的IO占用太厉害，因为这个库在迁移之前是每天都做一次索引重组的，迁移之后考虑到性能就去掉了。

还是PUB好，昨天找了一天GOOGLE都说要换磁盘换阵列。。。

hwtong

htyro 发表于 2012-7-18 14:32
，问题基本上解决了，在更新了几个库的统计信息之后，目前服务器的IO峰值在200多，平时保持在20左右，所 ...

额 你们那边不是达梦么?
也在用sqlserver?

nywh

普利斯够昂！

limin4506

全部看完，赞一个