1

运行通过我的 ASPX 页面构建的大型 SQL 查询后，我看到 sql profiler 中列出了以下两项。

 Event Class            TextData                                           ApplicationName             CPU    Reads   Writes
    SQL:BatchCompleted     Select N'Testing Connection...'               SQLAgent - Alert Engine     1609     0 0
    SQL:BatchCompleted     EXECUTE msdb.sbo.sp_sqlagent_get_perf_counters SQLAgent - Alert Engine     1609     96    0

这些 CPU 与查询相同，那么该查询实际上需要 1609*3=4827 吗？

case 也会发生同样的事情：

Audit Logout

我可以限制这个吗？我正在使用 sql server 2005。

4

4 回答 4

3

首先，您在 SQL Profiler 中看到的一些内容是累积的，因此您不能总是将数字相加。例如，SPCompleted 事件将显示构成它的所有 SPStatementCompleted 事件的总时间。不确定这是否是您的问题。

提高 CPU 的唯一方法是实际改进您的查询。确保它使用索引，最小化读取的行数等。与经验丰富的 DBA 一起研究其中一些技术，或者阅读一本书。

我能想到的唯一其他缓解措施是限制运行查询的 CPU 数量（这称为并行度或DOP）。您可以在服务器级别设置它，或在查询级别指定它。如果您有一个多处理器服务器，这可以确保单个长时间运行的查询不会接管机器上的所有处理器——它将留下一个或多个处理器空闲给其他查询运行。

于 2009-01-07T18:43:10.563 回答
2

SQL Server 2008 有一个新的“资源调控器”可能会有所帮助。我不知道您是否使用 SQL Server 2008，但您可能想看看这里

于 2009-01-07T14:51:36.240 回答
2

不，总共需要 1609 毫秒的 CPU。持续时间是多少？我打赌相同或更多，因为我怀疑 SQL 代理查询是否使用并行性。

您是否尝试使用 CPU 减少后台进程？如果是这样，那么您可以通过禁用 SQL 代理（例如，没有备份）并使用开关 -x重新启动 SQL Server 来减少功能

您也无法停止“审核注销”事件……这就是您断开或关闭连接时发生的情况。

但是，您是否正在最大化处理器？如果是这样，您需要区分用于查询的“用户”内存和用于分页或（上帝禁止）在 RAID 5 磁盘上生成奇偶校验的“系统”内存。

高 CPU 通常可以通过更多 RAM 和更好的磁盘配置来解决。

于 2009-01-07T20:05:37.603 回答
1

这是连接字符串的问题。如果审核注销占用了您的 CPU 太多，请尝试使用不同的连接字符串。

于 2010-10-24T09:59:02.237 回答