sql server发生的等待统计信息

SELECT * FROM sys.dm_os_wait_stats
WHERE wait_time_ms>0
ORDER BY wait_time_ms DESC

只有sql server重启的时候才会自动清除等待统计信息,可以通过 DBCC SQLPERF("sys.dm_os_wait_stats", CLEAR)命令清除统计信息。

通过一个临时表和waitfor delay 语句跟踪一段时间内发生的变化,从而判断当前正在发生的等待。

IF OBJECT_ID(‘tempdb..#wait_stats‘) IS NOT NULL
DROP TABLE #wait_stats

SELECT * INTO #wait_stats
FROM sys.dm_os_wait_stats
WAITFOR DELAY ‘00:00:05‘

SELECT ws1.wait_type,
    ws2.waiting_tasks_count - ws1.waiting_tasks_count
    AS waiting_tasks_count,
    ws2.wait_time_ms - ws1.wait_time_ms AS wait_time_ms,
CASE WHEN ws2.max_wait_time_ms > ws1.max_wait_time_ms
THEN ws2.max_wait_time_ms
ELSE ws1.max_wait_time_ms
END AS max_wait_time_ms,
    ws2.signal_wait_time_ms - ws1.signal_wait_time_ms
    AS signal_wait_time_ms,
    (ws2.wait_time_ms - ws1.wait_time_ms)-(ws2.signal_wait_time_ms - ws1.signal_wait_time_ms)
    AS resource_wait_time_ms
FROM sys.dm_os_wait_stats AS ws2
JOIN #wait_stats AS ws1 ON ws1.wait_type=ws2.wait_type
WHERE ws2.wait_time_ms - ws1.wait_time_ms > 0
ORDER BY ws2.wait_time_ms - ws1.wait_time_ms DESC

在查看资源等待时间和信号等待时间的差别的时候,最好观察两者在总时间内所占的比例。

SELECT SUM(signal_wait_time_ms) AS total_signal_wait_time_ms,
    SUM(wait_time_ms - signal_wait_time_ms) AS resource_wait_time_ms,
    SUM(signal_wait_time_ms) * 1.0 / SUM(wait_time_ms) * 100 AS signal_wait_percent,
   SUM(wait_time_ms - signal_wait_time_ms) * 1.0 / SUM(wait_time_ms) * 100 AS resource_wait_percent
FROM sys.dm_os_wait_stats
时间: 2024-11-05 18:55:30

sql server发生的等待统计信息的相关文章

SQL Server 执行计划利用统计信息对数据行的预估原理以及SQL Server 2014中预估策略的改变

前提  本文仅讨论SQL Server查询时, 对于非复合统计信息,也即每个字段的统计信息只包含当前列的数据分布的情况下, 在用多个字段进行组合查询的时候,如何根据统计信息去预估行数的. 利用不同字段的统计信息做数据行数预估的算法原理,以及SQL Server 2012和SQL Server 2014该算法的差异情况, 这里暂时不涉及复合统计信息,暂不涉及统计信息的更新策略及优化相关话题,以及其他SQL Server版本计算方式. 统计信息是什么 简单说就是对某些字段的数据分布的一种描述,让SQ

SQL Server 执行计划利用统计信息对数据行的预估原理二(为什么复合索引列顺序会影响到执行计划对数据行的预估)

本文出处:http://www.cnblogs.com/wy123/p/6008477.html 关于统计信息对数据行数做预估,之前写过对非相关列(单独或者单独的索引列)进行预估时候的算法,参考这里. 今天来写一下统计信息对于复合索引在预估时候的计算方法和潜在问题. 本文原形来自于是个实际业务问题,某SQL在利用一个符合索引做查询的时候,发现始终会出现预估误差较大的情况, 而改变复合索引的列顺序,这个预估行数的误差会发生变化, 也就是说,Create  index idx_index1 ON T

SQL查询各阶段的统计信息

        我们常常会遇到各种分类统计问题,需要将这些结果一次显示出来.这次老师提出的要求是我想看60分以下多少人,60~70多少人,70~80多少人,80~90多少人,90~100多少人.他们以前做的统计信息是,相同分数的有多少人,不同的分数都会在chart图表里显示一列,这样的效果通常是不被需要的,而且数据多的时候也会乱七八糟,没有美感,所以老师提出上面开始的要求.         他们以前的效果对应的sql语句是: <span style="font-size:18px;&quo

SQL Server性能优化——等待——SLEEP_BPROOL_FLUSH

前言: 有一个用于历史归档的数据库(简称历史库),经过一定时间的积累,数据文件已经达到700多GB,后来决定某些数据可以不需要保留,就把这部分数据truncate了,空余出600多GB的空间,也就是说,经过收缩后,理论上数据库只有100多G.为此,我经过重建各个表(表数量不多,但单表数量还是有几千万)的聚集索引后,准备进行收缩. 但是当收缩开始时,即使把每次收缩的范围缩小到500MB,速度也极其慢,经常几个小时都没反应.经过查看等待信息之后发现有一个SPID=18的会话(SPID<=50的均为系

SQL Server 发生错误:1807

SQL Server 不能创建数据库了,发生错误:1807 未能获得数据库'model'上的排它锁.请稍后重试操作. 解决: declare   @sql   varchar(100)         while   1=1     begin         select   top   1   @sql   =   'kill   '+cast(spid   as   varchar(3))     from     master..sysprocesses         where  

SQL调优技巧:统计信息(文末福利)

点击上方"异步社区",选择"置顶公众号" 技术干货,第一时间送达 统计信息类似于战争中的侦察兵,如果情报工作没有做好,打仗就会输掉战争.同样的道理,如果没有正确地收集表的统计信息,或者没有及时地更新表的统计信息,SQL的执行计划就会跑偏,SQL也就会出现性能问题.收集统计信息是为了让优化器选择最佳执行计划,以最少的代价(成本)查询出表中的数据. 统计信息主要分为表的统计信息.列的统计信息.索引的统计信息.系统的统计信息.数据字典的统计信息以及动态性能视图基表的统计信

SQL Server遍历所有表统计行数

DECLARE CountTableRecords CURSOR READ_ONLY FOR SELECT sst.name, Schema_name(sst.schema_id) FROM sys.tables sst WHERE sst.TYPE = 'U' DECLARE @name VARCHAR(80), @schema VARCHAR(40) OPEN CountTableRecords FETCH NEXT FROM CountTableRecords INTO @name, @s

SQL Server 2008中查看锁信息

;with tran_locks as(select resource_type,db_name(resource_database_id) as db_name,resource_description   ,object_name(resource_associated_entity_id,resource_database_id) as object_name,request_mode,request_type,request_status,request_session_id   fro

SQL Server 统计信息维护策略的选择

SQL Server 统计信息维护策略的选择 问题描述: 在对OLTP系统的一个上千万的表做归档后,循环分批删除源表数据时,业务应用收到超时告警,如下: V1.1.1.1: ****Process - QueryTransactionFor****: 23075129 Timeout expired.   The timeout period elapsed prior to completion of the operation or the server is not responding.