MS SQL Server会随着时间的过去而变慢吗？

您是否有以下经历，并且找到了解决方法：

我们网站的后端很大一部分是MS SQL Server2005。每两周或两周，该网站的运行就会开始变慢-我发现使用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 Server运行的所有内容的快照。很好的是，即使您的CPU由于某种原因被钉在100％上，并且活动监视器拒绝加载（我确定其中有些人在那里），该查询仍然返回，并且您可以看到哪个查询正在杀死您的数据库。

当我运行此程序时，或者在SQL开始放慢速度的时候运行“活动监视器”，我看不到任何引起该问题的特定查询-它们的运行速度都较慢。如果我重新启动MS SQL Service，那么一切都很好，它可以加快速度-一两个星期，直到再次发生。

我能想到的一切都没有改变，但这只是几个月前才开始的...想法？

- 添加

请注意，发生此数据库速度降低时，无论我们每小时获得10万次页面浏览量（一天中的繁忙时间）还是每小时一万次页面浏览量（缓慢的时间）都没关系，所有查询都比正常完成花费更长的时间。服务器并没有真正处于压力之下-CPU并不高，磁盘使用率似乎并没有失控...这感觉像是索引碎片或类似的东西，但这似乎不是案件。

就我上面粘贴的查询的结果而言，我确实无法做到这一点。上面的查询列出了执行任务的用户的登录名，整个查询等。并且，我真的不想在网上分发数据库，​​表，列和登录名：）...可以告诉您当时运行的查询是正常的，我们的网站一直运行的标准查询，没有任何异常。

-3月24日

自上次重新启动以来已经过去了大约两个星期。我做了几处更改：我发现了一些查询，在这些查询中我们大量使用了临时表，这些表完全没有必要，并且让我们的开发人员更改了他们的工作方式。我将一些不断（缓慢但肯定地）增长的数据库的大小调整为适合其增长的智能大小。我还调整了所有内容的自动增长设置，使其更加智能化（它们都设置为1MB增长）。最后，我整理了一下MSDB。我们进行日志传送，实际上并不需要保留数年之久的备份点，我编写了一些脚本，将其保留了仅几个月。我将继续更新此线程，因为现在判断问题是否已解决还为时过早。

我们找到了。原来，这实际上是一台Web服务器，其中一个应用程序池有问题。一遍又一遍地运行同一组查询（在临时表中处理）会陷入困境。它将不断循环，最终使SQL Server感到悲伤。一旦找到了这个令人讨厌的机器/应用程序池，并且“放下”了所有东西，就解决了。

您必须问自己，SQL服务重启时会发生什么？很多东西，但有两个相关的要点浮现在脑海：

1）SQL内存已释放。

其可能的（不知道如何可能），如果你的MaxMemory设置被设置得太高，SQL服务增长到使用所有可用的内存，和Windows开始交换重要的东西出到交换文件。检查并确保将MaxMemory设置为合理的值，为该框上需要运行的其他内容留出足够的额外内存（是专用的SQL Server还是应用程序服务器？）

2）TempDB是从默认大小重建的。

检查默认的tempdb文件大小，尤其是TempDB日志文件的默认大小和增长间隔。如果将增长间隔设置得太低，则日志会建立一些令人难以置信的内部碎片，这可能会大大降低正常使用速度。请参阅Kimberly Tripp撰写的这 两篇优秀的博客文章。

您是否大量使用临时表或游标？检查所有游标是否已关闭并正确释放。还请注意链接的服务器-对于旧的链接的Informix服务器，我们必须使用错误的驱动程序，这意味着我们必须重新启动服务器。

如果看起来很怪异，那就寻找怪异的东西。

如果调整SQL Server设置无济于事，请尝试Windows任务管理器：转到“进程”选项卡，然后依次选择“选项”>“列”>“添加CPU时间，句柄，读取，写入，其他和内存”选项。

返回到进程列表。对于每个列，按从高到低的顺序排序，并查看前5个过程。有什么不寻常的吗？例如，进程中的内存泄漏将具有异常数量的句柄。我们有一些* ki打印机，每2秒向DCSLoader进程添加一个句柄。几周后，一台机器列出了许多可用内存和cpu，但是一个进程具有100,000个句柄，几乎不会移动鼠标指针。

还要检查您的计划任务列表。告诉您的AV不要扫描.mdf文件。

戴夫

您是否查看了等待统计信息？您在上面的查询中列出了“ last_wait_type”列。该列可能包含有关查询正在等待什么的一些详细信息（网络，CPU等）。

如果您的备份“恢复模型”为“ FULL”，那么对数据库进行备份再对事务日志进行备份是否会有所改善？在磁盘空间不足的系统上，这种情况可以解释问题。

我似乎拥有与您的配置非常相似的配置（16 Gb，已升级到32 Gb，以及具有1 TB磁盘的MD1000，双四核xeon）。

已经帮我诊断一样，在过去的离奇问题的唯一事情是beta_lockinfo通过厄兰Sommarskog。在时间较慢时运行它并进行比较。

另外，在SP2之前的SQL 2005中，我遇到了很多疯狂的问题，但是SP3确实很稳定。

希望这会提供更多有用的信息：

SELECT  D.text SQLStatement,
        A.Session_ID SPID,
        C.BlkBy,
        ISNULL(B.status, A.status) Status,
        A.login_name Login,
        A.host_name HostName,
        DB_NAME(B.Database_ID) DBName,
        B.command,
        ISNULL(B.cpu_time, A.cpu_time) CPUTime,
        ISNULL((B.reads + B.writes), (A.reads + A.writes)) DiskIO,
        A.last_request_start_time LastBatch,
        A.program_name
FROM    sys.dm_exec_sessions A
        LEFT JOIN sys.dm_exec_requests B
        ON A.session_id = B.session_id
        LEFT JOIN (
                   SELECT   A.request_session_id SPID,
                            B.blocking_session_id BlkBy
                   FROM     sys.dm_tran_locks AS A
                            INNER JOIN sys.dm_os_waiting_tasks AS B
                            ON A.lock_owner_address = B.resource_address
                  ) C
        ON A.Session_ID = C.SPID
        OUTER APPLY sys.dm_exec_sql_text(sql_handle) D
WHERE   DB_NAME(B.Database_ID) = 'YourDBName' -- Comment out line for all db's
ORDER BY ISNULL(B.cpu_time, A.cpu_time) + ISNULL((B.reads + B.writes), (A.reads + A.writes)) DESC

确保db正常运行：

DBCC CHECKDB -- Checks the allocation and structural integrity of all the objects in the specified database.
DBCC UPDATEUSAGE (bybox) -- Reports and corrects pages and row count inaccuracies in the catalog views

留意以下日志空间：

DBCC SQLPERF(LOGSPACE)

如果您看到扩展正在进行中，那肯定会减慢速度。如果运行此命令，您将看到日志空间越来越接近100％，则日志将扩大，并且百分比会随着其空间的增加而缩小。希望您在备份​​开始执行并清除日志之前永远不会看到它扩展。

主要是白痴配置。发生。

• 首先，您实际上应该在维护运行中定期运行索引碎片整理。在进行备份之前或之后，将其安排为活动。

• 其次，不要自动增长数据库，尤其是不要自动收缩数据库。取决于负载，自动增长/自动收缩基本上是自杀设置。

从来没有像这样使SQL Server变慢。您可以在压力很大的时候发布该查询的结果吗？确定您当时没有任何事情会使SQL Server过载吗？