捕获等待类数据

　　SQL服务器已经提供了等待类的观点，但是遗憾的是，这些观点大多数情况下有些模糊因此难以发挥作用。从SQL Server 7.0和2000开始，数据库管理员可以使用企业管理器来查看等待类。问题是所有企业管理器提供的都是等待类的名称和进程等待的时长。当SQL Server Management Studio被引入SQL Server 2005的时间，主动查询和对话的观点都得到了保存。此外，数据库管理员会获得一个等待类和等待时间。

　　目前，观察SQL服务器中统计的最佳方法是使用动态管理查看(DMVs)。如果你仍在运行SQL Server 2000或更旧的版本，那就无法使用这一功能。与查看统计关系最密切的动态管理查看是sys.dm_exec_requests，sys.dm_exec_query_stats和sys.dm_os_wait_stats。

　　l sys.dm_exec_requests： 该动态管理查看提供了与 给定SQL服务器上执行的每个请求相关的信息。当看到等待状态的时候，你所关心的只是其中的某些部分：尤其是sql_handle, wait_type, wait_time, last_wait_type 和 wait_resource。

　　l sys.dm_exec_query_stats： 该查看返回了用于缓冲查询的性能统计信息。通过使用sys.dm_exec_requests中的sql_handle细则来加入查看，就可以获取等待发生频率的图片。记住，该查看不会给出详细信息。

　　l sys.dm_os_wait_stats： 该查看提供所有SQL服务器上等待状态的图片。它提供所有不同等待状态的列表和状态任务的详细信息，包括状态中等待任务的数量和所有等待时间以及平均等待时间。

　　情境一：识别问题查询

　　数据库管理员遭遇的最恼人的问题是“问题查询”(图一)。通常这样的查询是程序员定义的运行缓慢的查询。数据库管理员通常会听说这类查询“在开发的时候能正常运行”或“已经正常运行一段时间”。有时，反复的性能投诉会使数据库管理员寻找这一问题产生的原因以提高其性能。

　　图一

　　在这两种情况中，传统的研究方法涉及到开放若干工具，如SQL Server Profile和Windows Performance Monitor，再尝试捕获实时问题。具体来说，大多数数据库管理员都会看到具有较高等待时长，大量读取/写入的查询以及那些被频繁重复运行的查询。

　　不过在这两种情况中，基本的数据可能会有误导作用。例如，频繁重复运行但是运行得很快的查询一般不会形成阻碍。如果基本查询能高效快速地运行，一般应该不存在什么问题。但是如果查询的等待类持续总是相同，如ASYNC_IO_COMPLETION，那就可能是有问题了。

　　情境二：解决锁定问题

　　SQL服务器锁定通常是一个令人费解的问题。然而，使用等待类分析，要找到所需的锁定以及锁定的方式就容易得多。

　　大多数SQL服务器都会经历瞬间锁定和阻塞状况。只有当这些锁定导致长时间阻塞时才出现问题。列出锁定种类的等待类，如LCK_M_SCH_M，能准确识别进程等待的东西(图二)。图二示例中，一个等待锁定的进程需要修改表或视图的框架，因此该进程需要等待前面的插入，更新或删除数据的进程才能完成。

　　另一个潜在的问题是单独阻塞进程的自然扩展：阻塞链。一旦一个进程处于等待资源并阻断另一个进程的状态，另一个进程就很有可能会结束等待。解决的方案是找到阻塞链的源头。一旦等待类的源头找到并解决，其他进程就会不再受影响。

　　图二

　　情境三：找到硬件瓶颈

　　识别硬件资源的瓶颈可能是最复杂的情况。虽然会有一些指示瓶颈的症状，但是却似乎没有等待类以外的其他方法可用来确定硬件问题。

　　在本例中，关键是要找到与磁盘子系统(PAGELATCHIO_*)，CPU(CXPACKET)或通用存储系统(RESOURCE_*)相关的等待类。当等待超过几秒后，这些等待类就会指示硬件故障。

　　例如，我们假设由一个经常运行20分钟左右的查询，且该查询使用三个表格来确定第四个表格的更新。程序员已经提供反馈显示该查询已经随机启动超过四小时;查询运行的快慢速度之间没有可辨认模式。一个数据库管理员能够确定这样的查询一般会产生怎样的等待类，以及每个等待类的持续时间。如果等待类与硬件瓶颈相关，就该看看系统中那些在类似等待类中等待时长超出预期的其他查询。