充分利用SQLServer2005的性能工具Performance Dashboard（之二）

 --王成辉翻译整理，转贴请注明出自微软BI开拓者www.windbi.com
--原帖地址


怎样启动Performance Dashboard

怎样启动Performance Dashboard不是显而易见的事。但一旦你知道了怎样启动，就很容易了。下面是启动方法。

1. 如果你还没有做过，那么启动管理器。



2. 选择一个服务器和数据库，然后右击数据库，选择报表，然后选择自定义报表，出现下面的屏幕。



从这个屏幕里，选择performance_dashboard_main.rdl，并单击打开。这将启动Performance Dashboard，正如你下面看到的。一旦你第一次打开这个报表，管理器将记住它，你可以从一个列表中找到它而不需要每次重复上面的步骤。




怎样使用Performance Dashboard

对于DBA来说，Performance Dashboard包括了很多有用的信息。我们将从这个最初的Dashboard屏幕开始我们的研究，然后分别进入这个有利的工具提供的很多子报表的内部。我要提醒的是这是版本1.0，因此，它有一点不完美和一些Bug。即使有这些小小的瑕疵，Performance Dashboard仍提供了很多有用的信息。

Performance Dashboard主屏

Performance Dashboard不收集或存储任何信息，而只是从SQLServer内部当前存在的数据里提取数据。因此，你将看到的数据只是特定时刻的即时数据。但大多数情况下，你将看到存储的是SQLServer怎样工作的自然而然产生的历史数据。这个历史数据是有限的，但非常有用，就像我们将在稍后本文里看到的那样。

我指出这点的原因是因为你将不得不手动的刷新Performance Dashboard去获得当前你SQLServer活动的最新的快照。这是很容易做到的，通过单击Performance Dashboard顶部的刷新图标即可，如下所见。



现在，让我们看看Performance Dashboard主屏上的主要部分，还有很多可用的下拉子报表，看看它会告诉我们什么。

系统CPU利用

对绝大多数DBA来说，系统CPU利用图表是很有意义的。你所看到的是自SQLServer启动以后的最后15分钟的SQLServer CPU的活动，每1分钟显示一个图形。仔细记住我刚才所说的。例如，如果你刚刚启动SQLServer服务，那时没有CPU活动，因为自从它首次启动以来还没有超过1分钟。在你看到所有列之前需要运行15分钟才行。微软也应该指出你所看到的CPU利用不是一个精确的数字，而是一个近似数――但这个近似数足够达到我们的目标了。在下面的例子中，你能看到有15分钟的CPU度量值了，每次报表被刷新，这个图都将总是显示最后15分钟的CPU活动。



在上面的例子里，可以看到SQLServer非常忙，或许太忙。事实上，如果Performance Dashboard认为目前的CPU活动会引起硬件瓶颈的话，你会得到象上图里的一个警告。这样的警告仅仅出现在严重负荷时。

上图的另外一个显而易见的和有用的特征是你能快速的看到SQLServer使用了多少CPU，有多少CPU是服务器上其他的任务使用的。这能非常容易的知道，因为有时服务器上的性能问题不是SQLServer引起的，这个图形会快速的告诉你CPU资源大部分用在了服务器的什么地方了。

上图另外一个很有用的特征不那么显而易见了。实际上，它是隐藏的，除非你知道怎样去做。那就是如果你单击任何一个柱状图的蓝色部分，将出现一个下拉报表来列出最耗CPU资源的查询。



这个下拉报表显示了很多细节，不幸的是在本文里它难于复制。所以我要做的就是向你展示这个报表某些部分的细节，让你知道从这个下拉报表里有很多可用的信息。

首先，让我们仔细看看这个报表的第一个查询。



所有最近的查询中，有最耗CPU的。你能看到实际的查询代码，它在最后的15分钟里执行了多少次，它创建了多少个执行计划，执行计划第一次被缓存是什么时候，最后一次执行是什么时候。也要注意蓝色显示的查询。任何一个在报表里用蓝色高亮显示的都能被单击并下拉出更多的信息来。虽然我现在不会向你展示它，但如果你下拉这个查询的话，你将会看到它的执行计划。

这条信息的右边，你可以看到下面的图形：



在报表的这部分里，你能看到在最后15分钟里CPU花费的总时间。换句话说，在这儿你所看到的不是查询一次运行所花费的总时间，而是55次。你也能看到duration、物理读、逻辑读、逻辑写，如果用到的话，还有CLR处理时间。当用来分辨和纠正性能缺乏的查询时这个信息非常重要的。也要注意上面的屏幕快照里的每隔方框里有一个加号。当你单击它们的时候，报表将向你展开显示更多的细节，我们就不在本文里花时间去查看了。

我们刚刚了解了Performance Dashboard的CPU利用部分对我们可用的所有信息。让我们看看Performance Dashboard主屏的另一个关键地方。

目前的等待状态

在任何一个特定时刻，SQLServer每秒能执行成千上万个操作。不幸的是，并不是所有的操作都能在同一瞬间完成。那意味着常常有很多活动不得不等待一个非常短的时间直到轮到它们执行为止。实际上，SQLServer使用几百个不同的等待状态去管理所有这些复杂的事情。作为DBA，我们的目标是最小化等待状态，因为等待越多或越长，性能就越慢。虽然等待状态是正常的，但长时间的等待状态就不正常了，需要找出来并纠正它们。

SQLServer用不同的DMV记录了很多不同类型的等待状态，对这些DMV感兴趣的是那些收集自SQLServer服务最后一次重启以来的等待状态的历史数据。目前的和历史的等待状态信息对DBA来说都非常有用。

在Performance Dashboard最初的那个屏幕里，你也许可以看到下面的图形。注意我说的是也许。这是因为这个特殊的图形显示的是Performance Dashboard最后被刷新时刻的当前的等待状态的信息。非常有可能当时没有等待状态，如果是那样的花，屏幕上就不会出现图形了。但如果当时有一些等待状态的花，那么它们将显示在这个图形里
。


在上面的屏幕快照里，你能看到仅探测到在当时特定时刻花了60毫秒的一个等待状态，并且它在‘other’种类里。由于有很多不同种类的等待状态，微软把它们分门别类到大类中去使它们更容易了解一些。也要注意上图中的那个警告。象CPU利用的那个图形一样，如果Performance Dashboard认为目前的等待状态预示这一个性能问题的话，那么它将提供这样的一个警告。在这种情况下，Performance Dashboard认为为这类等待等待了60毫秒就过多了，就认为它是一个性能问题。

为了找出更多的目前等待状态，是什么导致的，你能单击图形中蓝色的地方去下拉出细节。接下来我向你展示的例子中就是一个下拉出来的细节，但不是上面那个不很有趣的例子中的，这是一个不同的等待状态的例子。



再一次由于网页大小的限制，我不能很容易的用一个屏幕向你展示整个报表。但我们从上面看到的是一个NetWork IO等待状态的情形（实际上有3个）。实质上，这告诉我们由于在NetWork IO等待状态里的一个备份，有3个查询等待去执行。在上面的例子中，我们仅查看了3个查询中的一个；其余两个在实际报表的第一个查询的下面。但是通过进入目前等待状态的内部去查看一个就足够多的向你展示可用的信息了。这个信息对DBA追捕到是什么引起等待状态的是非常有用的。