前言：

本文为本系列最后一篇，作为DBA，你必须经常关注磁盘的I/O问题，一旦出现问题，要尽快分析出是什么问题。SQLServer同样提供了一些列与I/O相关的DMO来做监控。

本文介绍如何使用DMO来监控I/O子系统的性能并找到I/O瓶颈。通过本文，可以区分不同数据库的I/O使用模式。一旦发现有数据库的I/O很高，可能需要考虑把数据库迁移到单独的磁盘，或者深入研究I/O产生的问题。

准备工作：

本文将演示如何监控数据库文件的I/O情况，将在SQLServer 2008R2上的AdventureWorks数据库上做演示。

步骤：

1、  打开SQLServer，连到AdventureWorks。

2、  输入以下脚本监控SQLServer实例上的日志文件和数据文件：

SELECT  DB_NAME(VFS.database_id) AS DatabaseName ,MF.name AS LogicalFileName ,MF.physical_name AS PhysicalFileName ,CASE MF.typeWHEN 0 THEN 'Data File'WHEN 1 THEN 'Log File'END AS FileType ,VFS.num_of_reads AS TotalReadOperations ,VFS.num_of_bytes_read AS TotalBytesRead ,VFS.num_of_writes AS TotalWriteOperations ,VFS.num_of_bytes_written AS TotalWriteOperations ,VFS.io_stall_read_ms AS TotalWaitTimeForRead ,VFS.io_stall_write_ms AS TotalWaitTimeForWrite ,VFS.io_stall AS TotalWaitTimeForIO ,VFS.size_on_disk_bytes AS FileSizeInBytes
FROM    sys.dm_io_virtual_file_stats(NULL, NULL) AS VFSINNER JOIN sys.master_files AS MF ON VFS.database_id = MF.database_idAND VFS.file_id = MF.file_id
ORDER BY VFS.database_id DESC

3、  在新窗口输入以下脚本，清空数据缓存：

USE AdventureWorks
GO
DBCC DROPCLEANBUFFERS
GO
SELECT  *
FROM    [Sales].[SalesOrderDetail]
GO

4、  现在再次执行第二步中的脚本，看看情况。

5、  执行下面的语句，查看是否有IO挂起操作：

SELECT  DB_NAME(VFS.database_id) AS DatabaseName ,MF.name AS LogicalFileName ,MF.physical_name AS PhysicalFileName ,CASE MF.typeWHEN 0 THEN 'Data File'WHEN 1 THEN 'Log File'END AS FileType ,PIOR.io_type AS InputOutputOperationType ,PIOR.io_pending AS Is_Request_Pending ,PIOR.io_handle ,PIOR.scheduler_address
FROM    sys.dm_io_pending_io_requests AS PIORINNER JOIN sys.dm_io_virtual_file_stats(DB_ID('AdventureWorks'), NULL)AS VFS ON PIOR.io_handle = VFS.file_handleINNER JOIN sys.master_files AS MF ON VFS.database_id = MF.database_idAND VFS.file_id = MF.file_id
GO

分析：

首先要切记不要随便在正式环境使用DBCC DROPCLEANBUFFERS命令，这个将会在一段时间内严重影响性能。

在本例中，对于sys.dm_io_pending_io_requests可能在本机中会没有数据，因为在单机情况下基本上很少io操作，从而挂起的可能性大大降低，但是在正式环境，多用户连接和操作时，就很有可能发生挂起情况。

上面提到的DMO对查找I/O子系统问题很有帮助，根据这些信息，再进一步找到高I/O的数据库，同时检查所在磁盘的I/O情况。