如果您接到有关 SQL 服务器性能问题的电话/寻呼,您首先会做什么?
开始跟踪?弹出 Perfmon?打开活动监视器?
这些都是有用的工具,但您的故障排除“顺序”是什么?
答案1
依靠。
这是一个突然的、毫无征兆的性能极慢问题,还是一个长期存在的总体性能不佳的情况?
如果是前者,我将从与执行相关的 DMV(sys.dm_exec_requests)开始。是否有任何阻塞?是否有查询运行时间过长或使用大量资源。基本上我会寻找一些异常(注意,为了能够看到这一点,我必须知道什么是正常的)
如果是后者,我会使用我在这些文章中所写的方法。
答案2
第一件事?与用户交谈。
有什么改变?
这种表现不佳的情况是新出现的吗?是突然出现的还是逐渐形成的?
您的历史报告(SQLH2)显示上个月的情况是什么?
检查服务器的磁盘空间、内存使用情况、CPU 使用情况(按顺序)。首先,服务器设置是否正确(内存设置)- taskmgr。
亲自检查性能。你觉得它慢吗?
用户是否已经习惯了新系统(无数据)的‘即时’性能,而现在它却开始拖慢速度了?
...然后你就可以开始调查可能的问题了。你必须先建立一个基准,否则你永远不知道什么时候才能完成。
答案3
在我执行上述所有建议之前,我会这样做:
SELECT
@@total_read AS 'Total Read',
@@total_write AS 'Total Write',
@@total_errors AS 'Total Error',
@@io_busy AS 'IO Processing Time (ms)',
@@cpu_busy AS 'CPU Processing Time (ms)',
@@idle AS 'Idle Time (ms)'
[我引用了我的博客文章:http://dbalink.wordpress.com/2009/04/28/monitoring-sql-server-performance-quickie-edition/]
答案4
检查日志文件,尤其是您可能打开的“长查询”日志。如果没有打开,请将其打开。
检查总体机器健康状况 - 可能不是 SQL 服务器,可能是整个机器 - 检查失控进程、总体 CPU 使用率、总体内存使用率 - 您确实使用 cacti 或类似软件绘制这些图表以进行历史比较,对吗?因此,检查图表并查看缓慢的进程何时开始变慢。