











下列系统监视计数器来检测物理磁盘级IO瓶颈:
下面DMV查询可以用来确认文件级的IO性能信息:
SELECT database_id, DB_NAME(database_id), file_id, io_stall_read_ms, io_stall_write_ms FROM sys.dm_io_virtual_file_stats(NULL, NULL)
io_stall_read_ms 和 io_stall_write_ms这两列表示的是SQL Server启动后等待向文件发出读和写指令的时间。为了获取有意义的数据,需要在短时间内对这些数据进行快照。然后将它们同基线数据相比较。
还可以通过检查等待锁来确认全部的IO瓶颈。最重要的等待锁是PAGEIOLATCH 和 PAGEIOLATCH_EX。当一个任务在锁存器上等待一个IO请求中的缓冲区时,这两种等待锁就会启动。
SELECT wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms FROM sys.dm_os_wait_stats WHERE wait_type LIKE 'PAGEIOLATCH%' ORDER BY wait_type
wait_time_ms 列包括一个工作进程在悬挂状态下花费的时间和在可运行状态下花费的时间,而 singnal_wait_time_ms 表示的只是一个工作进程在可运行状态下花费的时间。因此,这两者(wait_time_ms – signal_wait_time_ms)的差别实际上代表了等待IO完成所花的时间。上面查询返回的是SQL Server启动后的等待。要想获得有意义的数据,同样需要在短时间内对这些数据进行快照,然后对比。
IO瓶颈的隔离和排查,下面DMV查询返回引发IO最多的前10位查询或批处理。
SELECT TOP 10
(total_logical_reads/execution_count) AS avg_logical_reads,
(total_logical_writes/execution_count) AS avg_logical_writes,
(total_physical_reads/execution_count) AS avg_physical_reads,
execution_count,
(SELECT SUBSTRING(text, statement_start_offset/2+1,
(CASE WHEN statement_end_offset = -1 THENLEN(CONVERT(nvarchar(max), text)) * 2
ELSE statement_end_offset END - statement_end_offset)/2)
FROM sys.dm_exec_sql_text(sql_handle)) AS query_text
FROM sys.dm_exec_query_stats
ORDER BY (total_logical_reads + total_logical_writes) DESC
在许多可以通过减少基IO数目以改进查询性能的方法中,首先应该检查有用的索引有没有丢失。下面DMV查询就可以用来确认丢失的索引及它们的有用性:
SELECT t1.object_id,t2.user_seeks, 52.user_scans, t1.equality_columns,t1.inequality_columns
FROM sys.dm_db_missing_index_details AS t1,sys.dm_db_missing_index_group_stats AS t2, sys.dm_db_missing_index_groupsAS t3
WHERE database_id = DB_ID() AND object_id = OBJECT_ID('tablename') ANDt1.index_handle = t3.index_handle AND t2.group_handle =t3.index_group_handle
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。