![MS SQL Server 随着时间的推移而变慢?](https://linux22.com/image/508026/MS%20SQL%20Server%20%E9%9A%8F%E7%9D%80%E6%97%B6%E9%97%B4%E7%9A%84%E6%8E%A8%E7%A7%BB%E8%80%8C%E5%8F%98%E6%85%A2%EF%BC%9F.png)
你们中是否有人经历过以下情况并找到了解决方案:
我们网站的大部分后端都是 MS SQL Server 2005。每周或每两周,网站运行速度就会开始变慢 - 而且我发现 SQL 中的查询需要越来越长的时间才能完成。我有一个喜欢使用的查询:
USE master
select text,wait_time,blocking_session_id AS "Block",
percent_complete, * from sys.dm_exec_requests
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2 order by start_time asc
这非常有用...它提供了当前 SQL 服务器正在运行的所有程序的快照。好消息是,即使您的 CPU 由于某种原因被固定在 100% 并且活动监视器拒绝加载(我相信你们中的一些人遇到过这种情况),此查询仍会返回,您可以看到哪个查询正在终止您的数据库。
当我在 SQL 开始变慢时运行此程序或活动监视器时,我没有看到任何导致问题的特定查询 - 它们全都运行得更慢。如果我重新启动 MS SQL 服务,则一切都会正常,它会立即加速 - 持续一两周,直到再次发生。
我认为没有什么改变,但这只是几个月前才开始的......有想法吗?
- 添加
请注意,当数据库速度变慢时,无论我们每小时获得 100K 页面浏览量(一天中较繁忙的时间)还是每小时获得 10K 页面浏览量(较不繁忙的时间),查询都比正常情况下需要更长的时间才能完成。服务器并没有真正承受压力 - CPU 并不高,磁盘使用率似乎没有失控......感觉像是索引碎片或类似的东西,但事实似乎并非如此。
至于粘贴我上面粘贴的查询结果,我真的做不到。上面的查询列出了执行任务的用户的登录信息、整个查询等等。我真的不想在网上公布我的数据库、表、列和登录信息的名称 :)... 我可以告诉你,当时运行的查询是正常的,是我们网站一直在运行的标准查询,没有什么不正常的。
--3月24日
距离上次重启已经过去了大约两周。我做了一些更改:我发现一些查询大量使用了完全不必要的临时表,并让我们的开发人员更改了他们的操作方式。我将一些不断(缓慢但稳步)增长的数据库的大小调整为适合其增长的智能大小。我还调整了所有数据库的自动增长设置,使其更加智能(它们全部设置为 1MB 增长)。最后,我清理了 MSDB。我们进行日志传送,实际上不需要保留多年的备份点,我已经编写了一些脚本,将其保留在几个月内。我会继续更新此帖子,因为现在判断问题是否已解决还为时过早。
答案1
我们找到了。原来是 Web 服务器的一个应用程序池出了问题。它会卡在一遍又一遍地运行同一组查询(碰巧处理临时表)。它会一直循环,最终导致 SQL 服务器崩溃。一旦找到并“关闭”这个有问题的机器/应用程序池,一切都解决了。
答案2
你必须问自己,SQL 服务重启时会发生什么?有很多东西,但我想到了两个相关点:
1)SQL内存被释放。
它是可能的(不确定可能性有多大),如果您的 MaxMemory 设置过高,SQL 服务将增长到使用所有可用内存,并且 Windows 开始将重要内容交换到交换文件。检查以确保 MaxMemory 设置为合理的值,为该框上运行的其他任何内容留出足够的额外内存(它是专用的 SQL 服务器吗?还是也是应用服务器?)
2) TempDB 根据默认大小重建。
检查默认的 tempdb 文件大小,尤其是 TempDB 日志文件的默认大小和增长间隔。如果增长间隔设置得太低,则日志可能会积累一些令人难以置信的内部碎片,这会大大降低正常使用速度。请参阅这些 二金伯利·特里普 (Kimberly Tripp) 的精彩博客文章。
答案3
您是否大量使用临时表或游标?检查所有游标是否已正确关闭和释放。还要注意链接服务器 - 我们必须为旧的链接 Informix 服务器使用有缺陷的驱动程序,这意味着我们必须定期重新启动服务器。
答案4
戴夫,
您检查过等待统计数据了吗?您上面给出的查询列出了“last_wait_type”列。该列可能包含有关查询正在等待的内容(网络、CPU 等)的一些详细信息。