主页 / server / 问题 / 120750
Accepted
Dave Holland
Asked: 2010-03-10 06:42:29 +0800 CST

MS SQL Server 会随着时间的推移而变慢？

  • 772

大家有没有遇到以下情况，有没有找到解决办法：

我们网站后端的很大一部分是 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% 并且 Activity Monitor 拒绝加载（我相信你们中的一些人已经在那里），这个查询仍然会返回，您可以看到哪个查询正在杀死您的数据库。

当我在 SQL 开始减速期间运行此程序或 Activity Monitor 时，我看不到任何导致问题的特定查询 - 它们的运行速度都变慢了。如果我重新启动 MS SQL 服务，那么一切都很好，它会加速 - 一两个星期，直到它再次发生。

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

- 添加

请注意，当数据库速度变慢时，无论我们是每小时获得 100K 页面浏览量（一天中的繁忙时间）还是每小时 10K 页面浏览量（慢速时间），查询都需要比正常时间更长的时间才能完成。服务器并没有真正承受压力——CPU 不高，磁盘使用率似乎没有失控……感觉像是索引碎片或类似的东西，但这似乎不是案子。

至于粘贴我在上面粘贴的查询的结果，我真的不能这样做。上面的查询列出了执行任务的用户的登录名、整个查询等等。我真的不想在网上分发我的数据库、表、列和登录名的名称:)...我可以告诉你，当时运行的查询是正常的，我们网站的标准查询一直在运行，没有什么不正常的。

——3月24日

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

sql-server sql-server-2005

9 个回答

  1. Best Answer

    我们找到了。事实证明，它实际上是一个 Web 服务器，它的一个应用程序池有问题。它会一遍又一遍地运行相同的查询集（这恰好处理临时表）。它只会循环再循环，最终导致 SQL Server 伤心。一旦发现这个有问题的机器/应用程序池并“放下”一切都解决了。

    • 3

  2. 您必须问自己，在 SQL 服务重新启动时会发生什么？很多东西，但我想到了两个相关点：

    1) SQL 内存被释放。

    有可能（不确定可能性有多大），如果您的 MaxMemory 设置设置得太高，SQL 服务会增长到使用所有可用内存，并且 Windows 开始将重要内容交换到交换文件。检查以确保 MaxMemory 设置为合理的值，为该机器上需要运行的其他任何东西留出足够的额外内存（它是专用的 SQL 服务器吗？还是它也是应用程序服务器？）

    2) TempDB 从默认大小重建。

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

    • 2

  3. 您是否大量使用临时表或游标？检查所有游标是否被正确关闭和释放。还要注意链接服务器——我们必须为旧的链接 Informix 服务器使用有缺陷的驱动程序，这意味着我们必须定期重新启动服务器。

    • 1

  4. 如果它看起来很奇怪，那就寻找奇怪的东西。

    如果调整 sql server 设置对尝试 Windows 任务管理器没有帮助：转到进程选项卡，然后选项 > 列 > 添加 cpu 时间、句柄、读取、写入、其他和内存选项。

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

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

    • 0

  5. 戴夫，

    你检查过等待统计吗？您在上面给出的查询列出了“last_wait_type”列。该列可能包含有关查询正在等待什么（网络、cpu 等）的一些详细信息。

    • 0

  6. 如果您的备份“恢复模型”已满，那么备份数据库然后备份事务日志是否会改善一切？在磁盘空间不足的系统上，这种事情可能会解释问题。

    • 0

  7. 我的配置似乎与您的非常相似（16Gb，升级到 32Gb，MD1000 具有 TB 的磁盘，双四核至强）。

    唯一能帮助我诊断出过去类似的奇怪问题的是Erland Sommarskog的 beta_lockinfo。在时间慢的时候运行它并进行比较。

    此外，在 SP2 之前，我在使用 SQL 2005 时遇到了大量问题，但 SP3 确实很稳定。

    • 0

  8. 希望这能提供更多有用的信息：

    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%，然后日志会扩大，百分比会随着它得到一些空间而缩小。希望在备份启动并清除日志之前，您永远不会看到它扩展。

    • 0

  9. 大多是白痴配置。发生。

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

    • 其次，不要自动增长你的数据库，尤其是不要自动收缩它。根据负载自动增长/自动收缩基本上是自杀设置。

    从来没有见过像这样放慢 SQL Server 的速度。您可以在压力很大的情况下发布该查询的结果吗？确定您当时没有任何东西使 SQL Server 超载？

    • -1

相关问题