统计与诊断数据是任何 SQL故障修复工作的关键所在。如果没有掌握这些数据，就无法确定数据性能问题的根源。数据表的瓶颈可能并不是由索引问题造成的；而可能是数据库文件的保存方式。而这正是Pssdiag和Sqldiag管理器发挥作用的地方。

　　微软在SQL Server中捆绑了一个命令行工具Sqldiag，它可以从SQL Server实例及其所在Windows系统收集信息。它可以采集大量的数据：SQL Server Profiler的堵塞跟踪和数据、Windows性能和事件日志和SQL Server配置信息。

　　Sqldiag的最大缺点是交互性不佳。它是一个命令行工具，使用一个必须手工编辑的XML配置文件。虽然可以为不同统计信息创建多个XML文件，但是这仍然不是使用这个工具最简单的方法。特别是在将Sqldiag作为服务运行的时，它可以非常快捷地实现一站式后台数据收集，但是同样需要大量的手动配置。如果发现需要不停地调整数据采集参数，那么应该多次创建和执行Sqldiag，而非一次。

　　Pssdiagand SqldiagManager是一个开源项目，它为Sqldiag提供了一个图形化界面。这不仅仅是一个显示界面：它可以简化Sqldiag模板配置，支持对程序与相关文件进行打包，从而可以在多个服务器上方便地运行。

　　Pssdiag和Sqldiag管理器（P&SM）支持从7.0开始所有版本的SQL Server，包括2000、2005和2008（Windows Server 2012的支持也在规划中）。此外，它支持所有SQL Server处理器平台（x86/x64和Itanium），因此它支持所有CPU或软件版本。注意，如果使用SQL Server 2000或更早的版本，那么必须单独下载一些工具，因为较早版本的SQL Server不包含这些文件。

　　P&SM的工作原理是对一个程序包进行编译——即一个包含自定义数据采集参数的CAB文件。当运行P&SM时，指定SQL Server实例名称（默认是“*”，表示当前主机的所有实例），选择整个主机与SQL Server实例本身的性能指标、日志事件和诊断数据，就可以编译一个程序包。这些参数都会编译到一个CAB文件中，然后就可以在目标主机上运行和提取数据。

　　在默认情况下，最常用和最实用的诊断已经预先选中，但是由于所检查的问题各不相同，您可以缩小编译范围。建议使用跟踪过滤等文件缩小数据捕捉范围，但是要注意，在特定CPU开销情况下，它的实现方式可能会减少I/O和磁盘空间使用——实际上，这里存在一定的折衷。它们会给出一些可以避免问题发生的具体推荐配置；例如，过滤整形字段，保留文本字段，不捕捉高频事件，因为这些数据在开始时用处并不大。

　　关于P&SM，最重要的一点是支持创建自定义数据采集方法。如果采集的数据并非来自P&SM界面所展示的数据源，那么这是非常实用的功能。您可以使用自定义采集器运行T-SQL命令、批处理脚本、PowerShell命令或第三方命令行工具。PS&M产生的文件可以进行手工分析，或者加载到同一个公司开发的另一个工具（SQL Nexus）。

　　对于P&SM创建的程序包，还有其他一些问题需要注意。首先，在运行跟踪程序包时，它必须与SQL Server实例位于同一个主机上，并且必须进行监控。这是因为，您需要SQL Server实例本身进行一些必要的数据捕捉工作。捕捉这些统计信息的工具不可能转移到其他主机或实例上。只有在无法捕捉SQL Server分析跟踪数据时，才需要在另一台主机上跟踪程序包，但是开发商指出，这样做的好处并不大，所以最好在目标系统上运行跟踪，这样可以避免很多麻烦。

　　同样，您可能会尝试使用网络设备的跟踪包，以简化跟踪工作。例如，可以将多个跟踪包保存在同一个共享磁盘的子文件夹下，然后在各个SQL Server实例上运行。同样，不推荐采用这种方法 。我认为，如果使用这种方法，在目标磁盘上进出的网络流量可能会对性能产生重大的负面影响，而且会影响跟踪的准确性。