本文为本系列最后一篇,作为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.type WHEN 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 VFS INNER JOIN sys.master_files AS MF ON VFS.database_id = MF.database_id AND 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.type WHEN 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 PIOR INNER JOIN sys.dm_io_virtual_file_stats(DB_ID('AdventureWorks'), NULL) AS VFS ON PIOR.io_handle = VFS.file_handle INNER JOIN sys.master_files AS MF ON VFS.database_id = MF.database_id AND VFS.file_id = MF.file_id GO
首先要切记不要随便在正式环境使用DBCC DROPCLEANBUFFERS命令,这个将会在一段时间内严重影响性能。
在本例中,对于sys.dm_io_pending_io_requests可能在本机中会没有数据,因为在单机情况下基本上很少io操作,从而挂起的可能性大大降低,但是在正式环境,多用户连接和操作时,就很有可能发生挂起情况。
上面提到的DMO对查找I/O子系统问题很有帮助,根据这些信息,再进一步找到高I/O的数据库,同时检查所在磁盘的I/O情况。