SQL Server 2000 的简单性能指标

发布于 2024-07-23 10:33:42 字数 288 浏览 3 评论 0原文

我使用(和更新)的报告需要很长时间(有些需要几个小时)。 我觉得这太长了,之前就问过这个问题。 在浏览了各种讨论 SQL 性能的网站后,他们都采取了 DBA 的立场。 然而我不是,我的同事也不是(我想如果我们有 DBA 那么我们就不会有这个问题)。

我想要的是一种简单的方法来返回前 10 个左右运行最多和性能最差的脚本。 我希望有一个很好的 SET METRICS ON 开关,但我想如果是这样的话,那么网站就不会继续记录配置文件。

我最不想做的就是导致性能进一步下降,而记录配置文件听起来像是性能杀手。

The reports that I use (and update) are taking a long time (some take hours). I felt this is far too long and asked previously about this. After taking a long look at various web sites that discuss SQL performance, they all take the stance of being DBA's. However I'm not, and neither are my colleagues (I guess if we had a DBA then we wouldn't have this problem).

What I want is a simple way of returning the top 10 or so most run and worst performing scripts. I would of hoped there is a nice SET METRICS ON switch, but I guess if that was the case then the sites wouldn't go on about recording profiles.

The last thing I want to do is to cause performance to drop even further and recording a profile sounds like a performance killer.

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

对你再特殊 2024-07-30 10:33:42

您至少有以下选择。

  • 查看 SQL 分析器 中执行不良的查询的计划并尝试要优化它,请从那里逐个查询进行查询。
  • 或者使用脚本(见下文)通过分析 SQLServer 的有关您可以创建哪些索引的统计信息来为您提供建议
  • 或使用数据库引擎优化顾问建议和/或创建索引您可以加快查询速度
  • 或使用 redgate 的 SQL 响应 为您提供超出您消化能力的信息

最后,自动化工具将为您带来很大帮助。 对于您的情况来说,这甚至可能已经足够了,但请记住,没有任何自动化工具能够胜过熟练的 DBA,因为自动化工具无法重写您的查询。


SET CONCAT_NULL_YIELDS_NULL OFF
--Joining the views gives a nice picture of what indexes 
--would help and how much they would help
SELECT 
  'CREATE INDEX IX_' + UPPER(REPLACE(REPLACE(COALESCE(equality_columns, inequality_columns), '[', ''), ']', ''))
    + ' ON ' + d.statement + '(' + COALESCE(equality_columns, inequality_columns) 
  + CASE WHEN equality_columns IS NOT NULL THEN  
        CASE WHEN inequality_columns IS NOT NULL THEN ', ' + inequality_columns 
        END END 
    + ')' + CASE WHEN included_columns IS NOT NULL THEN ' INCLUDE (' + included_columns + ')' END
  , object_name(object_id)
  , d.*
  , s.*
FROM    sys.dm_db_missing_index_details d 
      LEFT OUTER JOIN sys.dm_db_missing_index_groups g ON   d.index_handle = g.index_handle
      LEFT OUTER JOIN sys.dm_db_missing_index_group_stats s ON  g.index_group_handle = s.group_handle
WHERE   database_id = db_id()
ORDER BY avg_total_user_cost DESC

You have at least following options.

  • look at the plan of a bad performing query in SQL Analyzer and try to optimize it, query by query from there.
  • or use a script (see below) to give you advice by analyzing SQLServer's statistics on what indexes you could create.
  • or use the Database Engine Tuning Advisor to suggest and/or create indexes for you to speed up your queries
  • or use a tool like redgate's SQL Response to give you more information than you can digest

In the end, automated tools will get you a long way. It may even be enough in your case but keep in mind that there is no automated tool that will be able to outperform a skilled DBA for the mear fact that automated tools can not rewrite your queries.


SET CONCAT_NULL_YIELDS_NULL OFF
--Joining the views gives a nice picture of what indexes 
--would help and how much they would help
SELECT 
  'CREATE INDEX IX_' + UPPER(REPLACE(REPLACE(COALESCE(equality_columns, inequality_columns), '[', ''), ']', ''))
    + ' ON ' + d.statement + '(' + COALESCE(equality_columns, inequality_columns) 
  + CASE WHEN equality_columns IS NOT NULL THEN  
        CASE WHEN inequality_columns IS NOT NULL THEN ', ' + inequality_columns 
        END END 
    + ')' + CASE WHEN included_columns IS NOT NULL THEN ' INCLUDE (' + included_columns + ')' END
  , object_name(object_id)
  , d.*
  , s.*
FROM    sys.dm_db_missing_index_details d 
      LEFT OUTER JOIN sys.dm_db_missing_index_groups g ON   d.index_handle = g.index_handle
      LEFT OUTER JOIN sys.dm_db_missing_index_group_stats s ON  g.index_group_handle = s.group_handle
WHERE   database_id = db_id()
ORDER BY avg_total_user_cost DESC
梦归所梦 2024-07-30 10:33:42

您应该能够浏览 sys.dm_exec_query_stats 表,该表保存有关数据库的所有查询的信息。

SELECT  creation_time  
    ,last_execution_time 
    ,total_physical_reads
    ,total_logical_reads  
    ,total_logical_writes
    , execution_count 
    , total_worker_time
    , total_elapsed_time 
    , total_elapsed_time / execution_count avg_elapsed_time
    ,SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
     ((CASE statement_end_offset 
      WHEN -1 THEN DATALENGTH(st.text)
      ELSE qs.statement_end_offset END 
        - qs.statement_start_offset)/2) + 1) AS statement_text
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY last_execution_time,total_elapsed_time / execution_count DESC;

为您提供有关历史查询所花费时间的基本计时信息。

You should be able to go thru the sys.dm_exec_query_stats table, which keeps information on all queries against a database.

SELECT  creation_time  
    ,last_execution_time 
    ,total_physical_reads
    ,total_logical_reads  
    ,total_logical_writes
    , execution_count 
    , total_worker_time
    , total_elapsed_time 
    , total_elapsed_time / execution_count avg_elapsed_time
    ,SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
     ((CASE statement_end_offset 
      WHEN -1 THEN DATALENGTH(st.text)
      ELSE qs.statement_end_offset END 
        - qs.statement_start_offset)/2) + 1) AS statement_text
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY last_execution_time,total_elapsed_time / execution_count DESC;

Gives you basic timing information of how long, historically, queries took.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文