当前位置：文江博客话题详情

如何记录并查找最昂贵的查询？

发布于 2024-07-08 10:54:08 字数 156 浏览 6 评论 0原文

sql2k8 中的活动监视器允许我们看到最昂贵的查询。好的，这很酷，但是有没有办法可以记录此信息或通过查询分析器获取此信息？我真的不想打开 Sql 管理控制台并查看活动监视器仪表板。

我想找出哪些查询写得不好/架构设计得不好等等。

非常感谢您的帮助！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

久夏青 2024-07-15 10:54:08

使用 SQL Server Profiler（在 SSMS 的工具菜单上）创建记录这些事件的跟踪：

 RPC：已完成 
   SP：已完成 
   SP:Stmt已完成 
   SQL:批量完成 
   SQL:StmtCompleted

您可以从标准跟踪模板开始并对其进行修剪。您没有指定这是针对特定数据库还是整个服务器，如果是针对特定数据库，请包含 DatabaseID 列并为您的数据库设置过滤器 (SELECT DB_ID('dbname') ）。确保每个事件都包含逻辑读取数据列。设置跟踪以记录到文件中。如果您要让此跟踪在后台无人值守地运行，则最好设置最大跟踪文件大小，例如 500MB 或 1GB（如果您有足够的空间）（这完全取决于服务器上的活动量，因此您将不得不吸吮它并查看）。
短暂启动跟踪，然后暂停。转到文件 -> 导出 -> 脚本跟踪定义并选择您的数据库版本，然后保存到文件。您现在拥有一个创建跟踪的 SQL 脚本，该脚本的开销比通过探查器 GUI 运行要少得多。当您运行此脚本时，它将输出跟踪 ID（通常是 @ID=2）；记下这一点。
一旦您有了跟踪文件 (.trc)（由于达到最大文件大小而完成了跟踪，或者您使用以下命令停止了正在运行的跟踪
执行 sp_trace_setstatus @ID, 0
EXEC sp_trace_setstatus @ID, 2

您可以将跟踪加载到探查器中，或使用 ClearTrace （非常方便）或将其加载到表中，如下所示：

SELECT * INTO TraceTable
FROM ::fn_trace_gettable('C:\location of your trace output.trc', default)

然后您可以运行查询来聚合数据，如下所示：

SELECT COUNT(*) AS TotalExecutions, 
    EventClass, CAST(TextData as nvarchar(2000))
 ,SUM(Duration) AS DurationTotal
 ,SUM(CPU) AS CPUTotal
 ,SUM(Reads) AS ReadsTotal
 ,SUM(Writes) AS WritesTotal
FROM TraceTable
GROUP BY EventClass, CAST(TextData as nvarchar(2000))
ORDER BY ReadsTotal DESC

一旦确定了成本高昂的查询，您就可以生成并检查实际的执行计划。

Use SQL Server Profiler (on the tools menu in SSMS) to create a trace that logs these events:
```
 RPC:Completed
 SP:Completed
 SP:StmtCompleted
 SQL:BatchCompleted
 SQL:StmtCompleted
```
You can start with the standard trace template and prune it. You didn't specify whether this was for a specific database or the whole server, if it is for specific Db's, include the DatabaseID column and set a filter to your DB (SELECT DB_ID('dbname')). Make sure the logical Reads data column is included for each event. Set the trace to log to a file. If you are leaving this trace to run unattended in the background, it is a good idea to set a maximum trace file size say 500MB or 1GB if you have plenty of room (it all depends on how much activity there is on the server, so you will have to suck it and see).
Briefly start the trace and then pause it. Goto File->Export->Script Trace Definition and pick your DB version, and save to a file. You now have a sql script that creates a trace that has much less overhead than running through the profiler GUI. When you run this script it will output the Trace ID (usually @ID=2); note this down.
Once you have a trace file (.trc) (either the trace completed due to reaching the max file size or you stopped the running trace using
EXEC sp_trace_setstatus @ID, 0
EXEC sp_trace_setstatus @ID, 2

You can load the trace into profiler, or use ClearTrace (very handy) or load it into a table like so:

SELECT * INTO TraceTable
FROM ::fn_trace_gettable('C:\location of your trace output.trc', default)

Then you can run a query to aggregate the data such as this one:

SELECT COUNT(*) AS TotalExecutions, 
    EventClass, CAST(TextData as nvarchar(2000))
 ,SUM(Duration) AS DurationTotal
 ,SUM(CPU) AS CPUTotal
 ,SUM(Reads) AS ReadsTotal
 ,SUM(Writes) AS WritesTotal
FROM TraceTable
GROUP BY EventClass, CAST(TextData as nvarchar(2000))
ORDER BY ReadsTotal DESC

Once you have identified the costly queries, you can generate and examine the actual execution plans.

回复收藏 0 原文

半仙 2024-07-15 10:54:08

以下脚本为您提供结果。

SELECT TOP 10 
SUBSTRING(qt.TEXT, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.TEXT)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, 
qs.last_logical_reads,
qs.total_logical_writes, qs.last_logical_writes,
qs.total_worker_time,
qs.last_worker_time,
qs.total_elapsed_time/1000000 total_elapsed_time_in_S,
qs.last_elapsed_time/1000000 last_elapsed_time_in_S,
qs.last_execution_time,qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY qs.total_logical_reads DESC

The Following script gives you the result.

SELECT TOP 10 
SUBSTRING(qt.TEXT, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.TEXT)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, 
qs.last_logical_reads,
qs.total_logical_writes, qs.last_logical_writes,
qs.total_worker_time,
qs.last_worker_time,
qs.total_elapsed_time/1000000 total_elapsed_time_in_S,
qs.last_elapsed_time/1000000 last_elapsed_time_in_S,
qs.last_execution_time,qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY qs.total_logical_reads DESC

回复收藏 0 原文

苍暮颜 2024-07-15 10:54:08

我以前从未听说过这个工具，但 Microsoft 提供了一组报告，可以出色地为您提供准确的信息 - 包括最慢的查询。查看他们的性能仪表板报告。

不确定它们是否与 SQL 2008 兼容，但值得一试。

回复收藏 0 原文

养猫人 2024-07-15 10:54:08

SQL Server Profiler 能满足您的需要吗？我还没有使用过 2008，所以我不知道该工具是否仍然存在，但如果是，我相信您可以设置跟踪来记录满足特定条件的查询（例如那些执行并驱动 CPU 的查询）一定的阈值）。

我们已经在我们的项目中使用了它，它在帮助我们解决执行不良的查询方面做得非常好（尽管不要让它全职运行，而是依靠通用的 Windows 性能计数器来进行性能健康跟踪）。

回复收藏 0 原文

我一直都在从未离去 2024-07-15 10:54:08

有一个新工具， SQL Server 2008 中的 Performance Studio 构建在服务器自动维护的动态管理视图之上，提供了服务器性能的概述。值得一看。

回复收藏 0 原文

溇涏 2024-07-15 10:54:08

(DELL)Quest SQL Optimizer for SQL Server 9.0 引入了查找 SQL 模块，该模块允许用户找到 SQL Server 中资源最密集的 SQL。
https://support.quest.com/softwaredownloads.aspx?pr=268445262

回复收藏 0 原文

~没有更多了~