Performance Dashboard

如果你到现在为止使用过一段时间的SQLServer2005，那么当我提到SQLServer2005性能工具Performance Dashboard时，你也许不知道我说的什么。不，你是否过度疲劳使你丧失了信心而忘记了列入SQLServer2005的那些新的特点。SQLServer2005的性能工具Performance Dashboard是新添加到SQLServer2005的并在SP2发布之后不久就可用的一款扩展工具。

由于SQLServer2005的性能工具Performance Dashboard是一款扩展工具，你必须从微软的网站上去花时间下载这个免费工具并安装它。幸好这是一个很容易的事情，我强烈建议所有的DBA在每个已安装SP2的SQLServer2005实例上下载并安装性能工具Dashboard。

使用Performance Dashboard对性能有何影响？

Performance Dashboard的一个好处是仅当报表实际运行时才找到性能信息。当报表第一次运行时或重新刷新时，它们找到很多DMV和DMF去收集数据且占用很少得资源。当报表没有运行时，不会占用资源。这意味着你在你所有得服务器上使用Performance Dashboard而不必担心任何对性能得消极影响。

 

综述

SQL Server 2005 Performance Dashboard Reports是一组Reporting Services的报表，和SQL Server 2005 SP2的Management Studio中所介绍的报表一起使用。这些报表允许数据库管理员快速地确定他们的系统中是否存在瓶颈，瓶颈是否正在发生，捕获这些附加的诊断数据可能会对解决问题更有帮助。例如，系统正在等待disk IO，这是Dashboard就允许用户可以快速地查看哪一个session，session中的哪一个查询计划，查询计划中哪一条语句最消耗IO。

Performance dashboard可以帮助解决一些普遍的性能问题，包括：

-CPU瓶颈问题（什么查询最消耗CPU）
-IO瓶颈问题（什么查询最消耗IO）
-由查询优化器产生的索引推荐方案（未使用索引）
-阻塞问题
-Latch竞争问题

这些捕获到报表中的信息源于SQL Server的动态管理视图，它不需要额外的跟踪或数据捕获，信息一致可用，所以它是一个不怎么消耗资源的一种管理服务器的方法。

Reporting Services对于使用Performance Dashboard报表并不是必须要安装的。

系统要求

 

•操作系统:Windows Server 2003; Windows Vista; Windows XP
•SQL Server 2005 Service Pack 2 或更新的版本

从哪里下载

为了安装SQL Server 2005 Dashboard，你必须从Microsoft下载至少两个文件。第一，如果你的SQL Server 2005不是SP2，你必须先下载SQL Server 2005 Service Pack 2，这是由于SP2包含了一些新的机制来支持the Performance Dashboard。

下载SQL Server 2005 Service Pack 2:
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/servicepacks/sp2.mspx

下载SQL Server 2005 Performance Dashboard:
http://www.microsoft.com/downloads/details.aspx?familyid=1d3a4a0d-7e0c-4730-8204-e419218c1efc&displaylang=en

如何安装

 

在你安装SQL Server 2005 Dashboard之前，你必须先安装SP2，因为SP2中包含了对于Management Studio的报表添加以及附加服务器端的功能机制，还修复了一些bug。

Performance Dashboard的报表不需要你先安装Reporting Services，它是在客户端的report viewer（Management Studio自带）控制下运行的。这种控制可以允许你不用创建它就可以直接运行这些报表。如果你想创建新报表，你需要利用SQL Server Business Intelligence Development Studio来创建。

安装了SP2后，你就可以下载Performance Dashboard的附加安装包了（SQLServer2005_PerformanceDashboard.msi），然后根据下图完成安装。

注意:SQL Server2005，若是32位版本，只要按照上面的提示进行安装就OK，若是64位版本，需在运行setup.sql脚本前，必须变更下setup.sql里面的内容。

需替换的内容：

sum(convert(bigint, datediff(ms, login_time, getdate()))) - sum(convert(bigint, s.total_elapsed_time)) as idle_connection_time,

替换的内容：

sum(convert(bigint, CAST ( DATEDIFF ( minute, login_time, getdate()) AS BIGINT)*60000 + DATEDIFF ( millisecond, DATEADD ( minute, DATEDIFF ( minute, login_time, getdate() ), login_time ),getdate() ))) - sum(convert(bigint, s.total_elapsed_time)) as idle_connection_time,

 

1．  双击SQLServer2005_PerformanceDashboard.msi开始安装，你会看到下图，单击Next继续。

 

2．  同意以下许可，并单击Next

3．  输入相关信息，单击Next

4．  你可以选择自动的默认安装路径来存储这些报表，也可以考虑其他的选项，把这些报表存到一个服务器的共享文件夹而非本地。为什么要这样做呢？虽然这不是必须的，但是你的所有SQL Server实例可以共享这些文件夹来访问报表，这样就不用再每一个SQL Server实例上安装Performance Report了。如果你创建了自定义报表，也可以很方便地共享。虽然并不是非要把文件夹路径设置在SQL Server实例的文件夹下，但是把这些报表定义文件放在同一个文件夹是很重要的。本例中，我们选择默认路径，并单击Next。

5．  现在一切就绪，单击install，安装成功后会弹出最后的对话框。

6．  单击Finish，

如何使用

1. 打开Management Studio

2. 右击一个数据库，选择Reports，然后选择Custom Reports

选择performance_dashboard_main.rdl，单击Open。你就会看到一个Performance Dashboard。当你第一次打开这个报表之后，Management Studio会自动记住它，你以后就不用再在对话框里重新找了。

 

Performance Dashboard 主屏幕

Performance Dashboard不收集也不存储任何信息，而是从SQL Server内部取出当前存在的数据。正因如此，大量的数据都是从某一特定时间开始的，但是有时，你会看到一些历史数据，作为副产品来查看SQL Server如何工作。历史数据很有限，但是很有用，我们之后会提到。

我之所以指出这个原因，是因为你必须手动的刷新Performance Dashboard来获取你SQL Server最新的活动快照。这也很容易做，只要单击Performance Dashboard顶端的refresh按钮就可以了，就像下面这张图这样。

现在，我们看看一些Performance Dashboard的主要区域，看看他们能够告诉我们些什么。

System CPU Utilization

对于大多数DBA，System CPU Utilization（系统CPU使用率）图表非常有用。你能看到至少15分钟的SQL Server的CPU活动情况，从SQL Server启动开始，每分钟一次更新。但是，请注意，如果你刚启动SQL Server的服务，将没有CPU的活动图表，因为还未满15分钟，15分钟后，你会第一次看到这些数据。而在这里还想强调的是，CPU的使用率并不是一个精确的数值，而是一个大约值，但是一个大约的值也已经足够了。在下面的例子中，你会看到一个15分钟CPU数据，并且每次更新之后，这个图表依旧显示的是一段15分钟长的CPU活动的数据。

在上述的例子中，我们可以看到，我们的SQL Server可能非常忙。实际上，Performance Dashboard如果认为当前的CPU活动会引起一个硬件的瓶颈的时候，它会自动弹出一个警告，就像你在上图中看到的这样，这样的警告仅仅繁盛在高负载的情况下。

另外，根据上表你还可以看到SQL Server占用了百分之几的CPU，其他任务占用百分之几的CPU，这些数据都是很难获得的，有时性能问题并不与SQL Server相关，这张图就能快速地告诉你这台服务器的CPU资源主要用在了哪里。

上图中另一个非常有用的特性不是非常明显，它是默认隐藏的。如果你点击了柱状图的蓝柱的区域，会有一个下拉报表显示最消耗CPU资源的查询计划。

下拉报表显示了很多细节，这些信息是弹出的，不能复制粘贴，下图是这个下拉报表的详细信息，很多信息都是非常有用的。

首先，我们看看这个报表的第一条查询语句。

与其他一起运行的查询相比，这条语句最消耗CPU，你可以看到实际的查询语句，它在之前的15分钟内执行了多少时间，创建了多少查询计划，查询计划何时存入cache，最后一次执行是在什么时候。我们还注意到查询语句都是蓝色高亮的，所有蓝色高亮的部分都可以被点击和下拉，这样还能看到它的执行计划。

你还能看到如下信息：

 

在这部分中，你能看到在之前的15分钟内CPU执行的总时间，而且，你看到的不是查询语句执行一次的总时间，而是55次的。你还能看到持续时间，物理读次数，逻辑读次数，逻辑写次数，以及CLR的操作时间。这些信息都是非常有用的，它可以用来鉴别和排查执行状况不好的查询语句。这个报表中有很多方框中的小加号，你点击它们时，报表会展开显示更相信的信息。

Performance Dashboard不仅提供了CPU使用状况的信息，还提供了许多其他的宝贵信息，我们来继续看一看。

Current Wait States

SQL Server每秒执行成百上千的操作，但它们并不是同时完成的。也就是说，许多活动通常都需要短期的“等待”。实际上，SQL Server利用数百种不同的等待状态来解决它们的复杂性。作为一个DBA，我们的目标是将这种等待状态最小化。等待状态越多，或者等待时间越长，性能就会越慢。当等待状态达到正常值的时候，扩展的等待状态就不在需要，需要将这些状态鉴别和更正。

SQL Server利用各种DMV来跟踪这些等待状态，有趣的是，SQL Server还能收集一些自上次SQL Server服务重启开始的一些等待状态的历史数据，这些历史数据和当前的等待状态信息都是对DBA非常有用的。

在初始的Performance Dashboard屏幕中，你可能会看到下面的图标。注意，只是“可能”看到。这是因为这个图表显示的是Performance Dashboard上次刷新时的当前等待状态的信息。很可能当时没有等待状态，如果如此，那就不会再屏幕中出现这类图表。

在上图中，你可以看到有一个状态在某段时间内花费了60秒的时间，而且它是“其他”类型。因为有太多种的等待状态，Microsoft把它分为几个大的类型，使之容易理解。注意上图中的警告，和CPU使用的图标一样，如果the Performance Dashboard认为当前的等待状态是一种性能问题的征兆，那它就会弹出这样一个警告。在这个例子中，Performance Dashboard认为一个60秒的这种类型的等待可能会引起一个性能问题。

为了找到更多当前的等待信息，并且查出它是如何引起的，你可以点击蓝色区域查看下拉的详细报表。下面我们看一个新的例子，见下图。

我们在这个例子中看到，有一个网络IO的等待状态（图中显示为3），这表明有三个查询正在等待执行。在这个图中，只显示出了三个查询中的一个，而其他两个就跟在这个查询之后。这些信息对于DBA也是非常有用的，它可以帮你找出什么原因导致了这种等待。

Current Activity

下图的数据都是自动显示的，你可以看到下图中的User Requests和User Sessions，这些数据都是Performance Dashboard在上次更新时获取的。另外，elapsed time（消逝时间）和cache hit ratio（缓存触发率）的值指的是之前的全部完成的请求的消逝时间总和。

点击蓝色的User Requests 或 User Sessions你可以看到下拉的信息。当点击User Requests，你可以看到下图的信息，显示出上次更新时的当前用户请求。

（与之前的部分图一样，为了省略显示，这张图被截断，真实的图标有更多的信息。）

当你点击User Sessions时，你可以看到下列的报表:

这个报表与Management Studio的Current Activity显示的信息比较相似，但它能提供更多的信息。（同样，这个报表也是被截断的，真实的报表比这更长。）

Historical Information

虽然Performance Dashboard并不收集历史数据，但是一些SQL Server的DMV是收集的，我们可以看下图，这些是利用DMV的数据显示出的历史数据：Waits, IO Statistics, 和 Expensive Queries。

Waits

这个报表显示了一个自SQL Server实例重新启动开始发生的所有等待状态的一个历史数据的快照。

在上述的例子中，我们能看到sleep wait state和this SQL Server实例记录的Network IO类别的最大等待状态。如果想查看更多的详细信息，可以展开这些状态类别。这些信息都非常强大，它可以帮助我们去确定这种等待状态是不是对SQL Server的性能有消极的影响。

IO Statistics

这些历史报表告诉你哪个数据库最消耗IO，以及一些其他的附加信息。下面的截图是报表的顶端部分，总结的数据库的IO情况。

下图是这个报表的另一个部分，能看查看哪一个对象最消耗IO。另外，如果发现了有出现missing index的情况，你可以下拉报表来查看具体是哪个missing index，这样就可以把它重新加上。

Expensive Queries

这部分提供了我们在其他查询报表所看到的相似的信息，但它显示的是SQL Server中当前被加入缓存的那些查询语句。这样我们就能给我们更好的展示，来看我们的服务器究竟发生了什么。

有六种不同方式的结果排序选项（每一种都将形成一个单独的报表）

上图中（被截断）显示了前20个最消耗资源的查询，以及一些有用的统计信息。你也可以下拉查看详细信息。

Miscellaneous Information

这是the Performance Dashboard显示的最后一个区域，它提供了三个方面的信息，如下图。

Active Traces

Active Traces鉴别了当前SQL Server实例中所执行的所有trace。即使你不能运行Profiler Trace，你依然可以看到这个active trace信息。为什么呢？这是因为SQL Server一直在自动地为你跟踪这些事件，当你在这个实力上执行一个Profiler Trace是，你会看到如下的信息。

Databases

Databases的报表提供了一个当前实例中数据库的快速浏览，可以快速查看这些主要数据库的配置选项。

Missing Indexes

最后一个报表列出了SQL Server所确定的所有missing index。这个分析没有Database Engine Tuning Advisor所做的那么全面，但它显示出了明显的missing index。其实我们只是希望在这个列表中不出现任何的missing index，这代表我们的数据库设计的更好。

正如你所见，SQL Server 2005 Performance Dashboard提供了大量的信息来显示SQL Server是如何工作的。对于SQL Server 的DBA来说，它是非常新颖，且功能非常强的一个工具。