我一直在与 DBA 和几个硬件人员争论我们 SQL 服务器上的性能问题。通常一切都很好，但是在过去的几周里，我们在 sql server 中遇到了巨大的滞后峰值。很明显，SQL Server 正在等待磁盘 I/O。但是我一直被告知这是因为 SQL Server 要求异常高的 I/O。事实并非如此。从运行中可以看出没有任何异常，所有DBA关心的只是导致阻塞的原因等等，这是无用的。例如，我们看到备份的主要内容是对 ASPState 数据库的操作，我们使用它来管理 Web 服务器上的 ASP 会话状态。这些操作通常不会出现在 Sp_who2 活动结果上，因为它们发生得如此之快。数据库处于简单恢复模式，日志记录很少。然而，在这些延迟高峰期间，我们可以看到数据库上的大量选择和更新操作被阻塞或等待。我确信正在发生的事情是某人或某项工作正在运行导致用于该数据库日志和数据文件的 RAID 阵列上大量磁盘使用的东西。问题是要证明这一点，因为没有人愿意承认他们正在做一些正在扼杀我们网站的事情。
我的问题是什么性能计数器或我可以记录的任何内容将有助于显示 SQL Server 正在等待 I/O，但不是因为它要求比正常情况更多，而是因为磁盘忙于响应来自 sql server 的请求像往常一样快吗？
我有一个进程渴望 tempdb，但我正在努力识别这个进程。
\n\n我有什么方法可以实现这一目标？
\n\n\n\n\n我们已收到警报，因为 Tempdb 现在已占据您之前在 T:\\ 驱动器上回收的空间。同样，磁盘上还剩余 10MB。从今天早上 10:18 开始，我可以在 REP 实例上的数据文件中看到许多自动增长事件。总共有 330 个自动增长事件，每个事件大小为 512MB，总计 168GB。
\n\n事后很难强调什么在 Tempdb 中使用了这个空间，您是否知道今天有任何进程可能以这种方式使用 Tempdb？
\n
/ ------------------------------------------------- ----------- \\
\n\n确定自动增长事件发生的频率
\n\n当 SQL Server 执行自动增长事件时，触发自动增长事件的事务必须等到自动增长事件完成后才能完成。当自动增长事件发生时，这些自动增长事件会导致您的性能略有下降。因此，最好能够适当调整数据库大小，以便很少发生自动增长事件。
\n\n如果您对系统上自动增长事件发生的频率感兴趣，您可以使用跟踪捕获这些事件。通过了解哪些数据库正在执行自动增长事件，您可以调整这些数据库文件增长属性，以便它们执行自动增长事件的频率降低。您可以使用探查器 \xe2\x80\x9cData File Auto-grow\xe2\x80\x9d 和/或 \xe2\x80\x9cLog File Auto-grow\xe2\x80\x9d 事件来跟踪这些数据库自动增长事件。如果您运行的是 SQL Server 2005 或更高版本，则默认跟踪已捕获这两个自动增长事件。如果您还没有\xe2\x80\x99t 关闭默认跟踪，那么您可以使用默认跟踪文件来查找这些自动增长事件。如果您已关闭默认跟踪，则可以启用它，或者设置新的探查器跟踪以捕获 \xe2\x80\x9cData File Auto-grow\xe2\x80\x9d 和 \xe2\x80\x9cLog File Auto-grow \xe2\x80\x9d 事件。
\n\n默认跟踪记录到文件中。我在清单 4 中提供了代码，向您展示如何从默认跟踪文件中提取所有自动增长事件。如果您创建自己的探查器跟踪会话来捕获这些自动增长事件，那么您将需要修改此脚本以满足您的探查器跟踪设置。
\n\n\n\n马塞洛·米奥雷利\n2014 年 3 月 11 日
\n\n\\*--------------------------------------------------*/\nDECLARE @filename NVARCHAR(1000);\nDECLARE @bc …