1 0 .2 用于监视的工具和技术

第 3 章从功能的角度介绍了不少可用的工具，而本章将从实现的角度介绍这些工具，
并讨论如何使用它们来实际执行一些关键的数据库监视任务。本章还涉及了一些第3 章中
没有介绍的工具，由于它们杂乱地结合到了 SQL Server Management Studio中。

1 0 .2 .1 日志文件查看器
日志文件査看器(Log Hie Viewer)是一个很出色的工具，能够用它在一个一次性关联的 视图中査看SQL Server和操做系统日志。例如，来自于系统日志的内存子系统错误能够和 SQL Server错误关联在一块儿，指示内存不足的状况，并容许将问题与SQL Server隔离开来。 要打开日志文件査看器，可 在 SQL Server Management Studio中 展 开 “管理”文件夹，然 后 展 开 “SQL Server日志”文件夹，右击想査看的日志，然 后 选 择 “查 看 SQL Server日志” 命令。在日志文件查看器打开以后，能够选择打开其余SQL Server 0 志和/或操做系统曰志, 方法是展幵并选择想查看的日志(如图10-2所示)。可注意到，还能够打开SQL Server代理 和数据库邮件的日志文件。

每 次 重 启 SQL Server和 SQL Server代理服务时，会关闭各自的日志文件并打开一个新 的日志。在一个生产系统中，这种状况可能不会常常发生，因而就会造成一个较大的日志
文件。要想避免出现过于庞大的日志文件，必须导出日志文件的内容，而后再循环使用该
文件。要想循环使用SQL Server日志，可 以 执 行 spjyclejrrodog存储过程。要想循环使 用代理日志，可 以 使 用 sp_CyCk_agen t_errOrk>g存储过程。这些过程能够清除日志的内容而 不要求重启服务。
可 以 右 击 “SQLServer日志”文件夹，然 后 选 择 “配置”命令来配置SQL Server保留 的日志数量，如 图 10-3所示。最小的(也是默认的)数量是6 , 但能够增长到99。日志数量
不能小于6。

10.2.2活动监视器
Microsoft在 SQL Server 2008的最后一个候选发布版中包含了一个彻底革新的活动监 视器(Activity Monitor)。这 令 SQL Server社区感到意外，由于活动监视器已经再也不位于其 原来的位置上，许多感到担优的DBA在支持论坛上发布了大量的相关帖子。显然，这也
让 Microsoft联机丛书团队感到意外，由于在编写本书时，他们仍在引用原来的活动监视器 的文档。
SQL Server 2008中的活动监视器如今是一个功能丰富的、接近实时的图形化性能面
板。新的活动监视器的外观与Windows Vista和 Windows Server 2008系统中的可靠性和性
能监视器相似。有经验的DBA将注意到的第一件事是活动监视器再也不位于SQL Server Management的 “管理”节点下，而是在SQL Server实例的上下文菜单中。 活动监视器是一个能够帮助对服务器的总体运行情况和性能有更深刻理解的优秀工
具。与前面的版本相比，它再也不只显示简单的进程和锁定信息。它如今显示直观的图形、
详细的进程和锁定信息、文件I/O统计信息和长时间运行的査询的信息。另外，如今能够
对全部的网格视图进行排序和筛选。活动监视器不能取代有经验的DBA所掌握的一组优
秀的数据管理视图，但它能够很好地回答“为何服务器运行如此缓慢”这个基本问题。
要运行活动监视器，需 要 具 有 view server state权限。要终止任何进程，还须要是
sysadmin或 processadmin服务器角色的成员。新的活动监视器能够在SQL Server 2005上工
做，但在以前的版本上不能运行。

活动监视器由5 个主要部分构成，分别是：概述、进程、资源等待、数据文件I/O和
磁近耗费大量资源的査询。
• 概述—— “概述”部分显示了 4 个表示关键性能度量指标的接近实时的图形。右
击图形将能够调整刷新率或暂停数据收集。
• 进程一 “进程”部分为每一个与SQL Server的链接列出了一行，并有一些列来描 述该进程(如与该链接关联的用户、数据库t 下文、当前运行的命令以及全部的等 待状态和阻塞信息)。右击一个进程并选择“详细信息”命令将显示在该链接上最
后一个执行的命令，并提供了在必要时终止该进程的功能。右击一个进程所显示
的上下文菜单中有一个“SQL Server Profiler中的跟踪进程”的选项。图 10-4演示 了这一行为。另外在图10-4中可看到，进 程 59是挂起的，由于它在等待被进程
57锁定的资源，然后者又在等待被进程60锁定的资源。

资源等待—— “资源等待”部分妞示一个全部资源等待(CPU、Latch、Memory、
Buffer I/O等)的完整列表。这个列表并不提供任何钻取功能，但能够筛选和排序结果。 • 数据文件I/O—— “数据文件I/O” 部分显示了数据库文件的活动总计信息。能够
对这个列表进行筛选和排序。
• 最近耗费大量资源的查询—— 这是活动监视器中新添加的-个很是优秀的选项。
“最近耗费大量资源的査询”部分显示了全部最近、最耗费资源的査询，容许在
一个新的查询窗U中打开某个完整的査询语句或详细的执行计划。图 10-5显示了
这个部分以及一个耗费大量资源的査询的文菜单选项。

默认状况下，活动监视器将每10秒刷新一次显示结果。要将活动监视器配置为另外
一个刷新率，可右击任意图形，选择所需的刷新间隔或选择“暂停”命令禁用刷新。记住，
频繁刷新进程信息会致使SQL Server性能降低。
1 0 .2 .3 系 统 存 储 过 程
虽然就査看进程以及它们使用的资源而言，活动监视器是一个很好的图形工具，但通
常来讲，系统存储过程的输出更简单，更适合用来识别当前进程以及任意资源竞争。
1. sp_who 和 sp_who2
sp_who2存储过程是一个未归档的系统过程，和已归档的同类存储过程sp_who相比， 它有显著的优点。它们都返回当前SQL Server进程的信息，可是sp_who2过程返回的信息更 加全面。
这些存储过程本质上等同于活动监视器的“进程”页。sp_who或 sp_who2的输出能够通 过指定一个进程ID做为输入参数加以限制。sp_who和 sp_who2过程的语法以下所示：
s p _ w h o [p ro c e s s _ _ I D ] , l o g i n n am e | (A CTIV E]
s p _ w h o 2 [ p r o c e s s _ I D ] I [ACTIV E]
sp who相储过程返回表10-3中描述的9 列。

sp_who2存储过程返回了 13列，但它返冋了 spid列两次，一次在结果集的左边， 次在结果集的右边，以使结果集的读取更加容易。这些列如表10-4所示。

当 把 Active选 项 添 加 到 sp_who或 sp_who2时 ，SQL Server不会返回任何状态为
Awaiting Command的会话，该状态指明会话正在等待一个用户进程的输入。
2. sp_lock
spJock存储过程返回活动数据库进程所持有的锁的数目和类型。已锁定的或将要被锁 定的对象会和锁定状态以及任何标识信息(例如对象的整型标识符)一块儿返冋，另外还会返
回 索 引 ID(若是有的话)。
3. SQL Server 锁定
要 解 读 spjock返回的信息，了解可锁定的资源类型和这些锁能够采用的模式是很重 要的。可能的资源类型如表10-5所示。

资源类型上的锁经过模式请求和授予。spjock存储过程返回标识锁模式的信息(例如锁 是一个共享锁仍是排他锁)。表 10-6列出了最多见的模式。

4. KILL命令
虽然KILL命令不是一个存储过程，但它使数据库管理员能够终止一个违反规则的进程,
就像图10-4所示的“进程属性”对话框中的“终止进程”按钮同样。KILL命令的语法如

下所示:
KILL s p id
KJLL命令颇有用，但使用时须要至关当心。虽然有时候有必要终止一个中断的进程,
可是在终止它以前搜集与它有关的尽量多的信息仍是很重要的。例如，终止一个已更新
了 1000行的事务会致使这1000行冋滚，这会产生一些不但愿看到的结果，例如事务日志
填满或数据丢失。

试一 试系统存储过程
如今看系统存储过程返回了什么信息，以及如何使用它们隔离有问题的进程。
(1)打开一个查询窗口。输入并执行下列代码：
USE AdventureWorks2008; GO
BEGIN TRAN
UPDATE Person.Person SET LastName =*Gates'
WHERE BusinessEntitylD =1;
(2) 打开另外一个査询窗口。输入并执行下列代码：
USE AdventureWorks2008; GO
SELECT * FROM Person.Person WHERE BusinessEntitylD =1;
在执行此语句时不会看到任何返冋的结果。由于在第一个查询释放其锁定以前，此语
句不会完成执行。
(3) 如今打开第三个査询窗口，执行下列命令运行sp_who系统存储过程：
EXEC spwho;
注意，其中一个进程显示它被另外一个会话阻塞。如图10-6所示，SPID 59被 SPID 60阻塞。

 

(4) 执 行 sp_who2存储过程，但将结果集限制为阻塞会话的服务器进程ID(Server
Process ID, SPID)。在这里，spid 是 60。
EXEC sp_who2 60;
执 行 sp_who2存储过程所获得的更加全面的结果会返回很是有用的信息(例如形成阻 塞的程序和用户，以及会话执行负责锁争用的命令的时间)。
(5) 肯定哪一个对象在被两个进程竞争。执 行 sp lock存储过程。和 sp_who及 sp_who2 存储过程同样，能够经过传递合适的进程ID限制过程的结果。 _ _
(6) 输入并执行下列命令以显示有关被阻塞的SPID的信息。该 SPID在 sp_who2结果 的 BlkBy列中返回了一个值。在本例中这个值是5 9 ,可是您的SHD颇有可能不同：
EXEC sp_lock 59;
结果如图10-7所示。

在 图 10-7中能够注意到，已经请求和授予了一些锁，但汇集索引键010086470766(表
示 Person.Person表 中 BusinessEntitylD为 1 的联系人)上的共享锁处于WAIT状态。这是因
为 spid 60当前正在修改该行，并在该键上持有一个排他锁。
要终止阻塞进程，须要执行KJLL命令并指定合适的SPID,在这里是60:
KILL 60;
注意：
在终止进程时要当心。SPID 60是个人机器上的进程。您的结果可能和个人不同!
10.2.4 使用 Profiler
第 3 章介绍了 Profiler的基本功能。本节将介绍如何搜集性能信息来隔离和纠正数据 库应用程序的问题。对所提供跟踪的指导原则能够结合到一个综合性跟踪中或者单独实施。
使用Profiler时另外一个重要的考虑事项是开销。交互式运行Profiler会致使大量服务器 开销，以及较大的不肯定因素。Profiler只是一个查看SQL跟踪的图形化界面。它是一个 很好的工具，但对于有着繁重事务负荷的大型数据库来讲，可能须要使用sp_trace_setevent,
sp_trace_setfilter、sp_trace_setstatus和 sp」race_create存储过程，经过文件中搜集的跟踪数
据建立、配置和运行跟踪。而后可使用Profiler直接经过搜集的文件查看这些数据，或 者能够将它们导入到一个数据库中以供分析。

 

试一试 使 用 Profiler分 析 死 锁
如前所述，使用性能监视器检测死锁很容易。但要找出死锁发生的缘由则较为困难，
须要经过Profiler运行跟踪和检査收集的数据。
(1 )打开 SQL Server Management Studio,链接到驻留 AdventureWorks2008 数据库的服
务器。在链接后经过“工具”菜单启动SQL Server Profiler,建立一个基于“空白”模板的 新跟踪，如 图 10-8所示。.

 

 

(2 )在 “事件选择”选项卡上，选择Deadlock graph和 Lock:Deadlock Chain事件，如
图 10-9所示。注意，若是选择了 Deadlock graph事件，则会出现“事件提取设置”选项卡。

(3 )要限制返回给Profiler的数据，单击“列筛选器”按钮，而后选择DatabaseName。在 “不相似于”文本框中，输入MSDB以免跟踪SQL代理和计划的监视活动。单击“肯定”

按钮。
图 10-10显示了想要使用的配置。筛选数据库时要当心。您可能认为最佳筛选器应该
是经过数据库ID或数据库名称指定特定数据库的筛选器。可是，有不少Profiler事件没有 一个特定的数据库上下文，因此若是这样设置筛选器的话，它们将不会显示。所以，必须
告诉Profiler不要监视哪些数据库。deadlock graph就是这样一个事件。

(4)在 “事件提取设置”选项卡上，选中“分别保存死锁XML事件”复选框，而后输
入一个位置来保存文件(如图10-11所示)。选 中 “不一样文件中的每一个死锁XML批”单选按
钮，而后单击“运行”按钮。

(5 )在 SQL Server Management Studio中，打幵两个新的査询窗口。
⑹在第一个査询窗 口 中 (可 能 叫 作 SQLQueryl.sql),输入以下代码并执行:
—— Connection 1 USE AdventureWorks2008; GO
BEGIN TRAN
UPDATE Person.Address SET City = * Redmond * WHERE AddressID =1;

(7)在第二个查询窗口中输入以下代码并执行:
—— Connection 2 USE AdventureWorks2008; GO
BEGIN TRAN
UPDATE Person.Person SET LastName =*Gates'
WHERE BusinessEntitylD =1; UPDATE Person.Address SET AddressLinel = * 1 Microsoft Way* WHERE AddressID =1;
此更新将不会完成，因 为 Connection 1 中的事务在想要更新的Person.Person表的行上 有一个排他锁。此时发生的是一个阻塞锁。Connection2中的事务想要更新被Connection 1 阻塞的行。阻塞锁是容许的，并且除非设置了锁定超时值、阻塞的事务完成或者管理员终
止了阻塞的事务，不然此锁就会一直存在。
(8 )在第一个链接上，编写并执行以下代码以更新Person.Person表：
--Connection 1
UPDATE P erson.P erson
SET FirstName = *Bill'
WHERE BusinessEntitylD =1;
此更新会致使一个死锁发生，由于两个链接在对立事务完成所需的资源上都持有排他锁。
死锁会被检测到，其中一个死锁的进程将被终止。留下的进程将成功运行。
(9 )返回到Profiler,中止跟踪，而后选择Deadlock graph事件类行。死锁图形显示了
被死锁的服务器进程ID和已锁定资源。将鼠标指针悬停在一个进程上面会显示参与死锁的
进程，如 图 10-12所示。

提示：
要将Person.Person表还原至初始状态，须要在没有被死锁终止的事务上执行ROLLBACK 语句。
(10)要捕捉用来运行这个跟踪的脚本，单击SQL Profiler中 的 “文件”菜单，而后选 择 “导出” | “编写跟踪定义的脚本”丨“用于 SQL Server 2005-2008” 选项，如 图 10-13所 示。这时 将 出 现 -个 “另存为”对话框。将该脚本保存为DeadLockTrace.SQL。

(11)打开使用 SQL Server Management Studio 保存的 DeadLockTrace.SQL 文件。SQL
Server运行此脚原本建立刚才执行的跟踪。保存这个脚本以后，能够在任意时间运行它， 而不须要启动和运行Profiler。要知道有关每一个存储过程的更多信息，请 参 阅 SQL Server 联机丛书，里面有至关详细的讨论。
在捕捉到跟踪文件后，可使用SQL Profiler打开它，或者若是跟踪较大，能够把它
插入表，以便使用传统的T-SQL査询分析。要把数据移动至表中，可使用fh_trace_gettable
表值函数。此表值函数须要两个值：须要导入的跟踪文件的名称和须要搜集的滚动更新文
件的最大值。默认的文件数目是为跟踪设置的最人文件数。下面的例子显示了如何将以前
搜集的跟踪添加到AdventureWorks2008数 据 库 中 的 个 叫 作 DeadLockTraceTable的表里：
USE AdventureWorks2008; GO
SELECT * INTO DeadLockTraceTable FROM fn_trace_gettable(C:\ProfilerTraces\DeadLocks.trc1, NULL);
使用Profiler检测和分析长吋间运行的查询 Profiler是一个很好的工具，能够用于分析锁，以及调试存储过程和数据库应用程序。

 

试一试
它也可用于检测和分析影响SQL Server性能的长时间运行的査 询 。Profiler能够返回査询 执行信息，数据库管理员能够经过这些信息找出致使冗长査询的缘由。是代码写得很差吗？
是否没有索引支持査询？或者这只是一种奇怪的查询？
分析查询
要分析查询，须要遵循下列步骤：
(1) 启 动 Profiler,使 用 “空白”模板建立一个叫作QueryTuning的新跟踪。在 “事件 选择”选项卡上选择下列事件：
• Performance： ShowPlan XML • Stored Procedures： SP: Completed
• TSQL： SQL: BatchCompleted
(2) 单击“列筛选器”按钮建立一个筛选器，其中数据库名称“相似于”AdventureWOrks2008, 而后单击“肯定”按钮应用该筛选器。
(3) 单 击 “组织列”按 钮 。找 到 Duration列 ，将其移至列列表的顶部，使得易于阅读 持久数据。
(4) 在 “事件提取设置”选项卡上，选 中 “分别保存XML显示计划事件”复选框。选
择 一 个 保 存 ShowPlan信息的位置，将文件命名为Query Tuning,然 后 选 择 “不一样文件中的 每 个 XML显示计划批”选 项 。SQLPlan是 给 予 ShowPlan数据的文件扩展。ShowPlan数据 存 储 为 XML格式，而且可使用Management Studio査看(后面将会介紹)。当将査询计划 保存在单独的文件中时，每一个文件都采用在目标位置中定义的名称，而且名称后面附加有
数字标识符。
(5) 单 击 “运行”按钮运行此跟踪。
(6) 接下来，在 SQL Server Management Studio中 打 开 一 个 新查询窗口。输入并执行下
列代码：
USE AdventureWorks2008; GO
SELECT P.ProductID, P.name AS Product, TH.TransactionDate, SUM(TH.Quantity), SUM(TH.ActualCost), SUM(P.StandardCost) FROM Production.Product P INNER JOIN Production.TransactionHistory TH ON P.ProductID = TH.ProductID GROUP BY P.ProductID, P.Name, TH.TransactionDate;
GO
EXEC dbo.uspGetManagerEmployees 109;
GO
EXEC dbo.uspGetEmployeeManagers 1;
GO
SELECT P.name AS Product, SUM(SOD.OrderQty) AS SumQty , SUM(SOD.UnitPrice) AS SumPrice, SUM(SOD.LineTotal) AS SumTotal , CONVERT(char(10), SOH•OrderDate,101) AS orderDate , CONVERT(char(10), SOH.ShipDate,101) AS ShipDate , CONVERT(char(10)r SOH.DueDate,101) AS DueDate

FROM Sales.SalesOrderDetail SOD
INNER JOIN Sales.SalesOrderHeader SOH
ON SOH.SalesOrderlD = SOD.SalesOrderlD INNER JOIN Production.Product P ON P.ProductID = SOD.ProductID
GROUP BY P.Name, SOH.OrderDate, SOH.ShipDate, SOH.DueDate;
査询完成以后，中止跟踪并检查结果。可注意到，运行时间最长的进程是最后一个进
程 ，它引用了 Sales.SalesOrderHeader 表、Sales.SalesOrderdetail 和 Production. Product 表 0
(7) 导 航 至 ShowPlan目标文件夹并检 査 内 容 。应 该 看 到 4 个 文 件 ，分别从
QueryTuning l.SQLPlan 到 QueryTuning_4.SQLPlan 进行命名。 (8) 双击 QueryTuning_4.SQLPlan 文件。这将启动 SQL Server Management Studio，并
把该文件做为一个图形 化 &行计划打开，如图10-14所示。

在评估数据库引擎用来优化査询的实际进程和识别可改进的区域方面，ShowPlan文件 很是有用。对于ShowPlan,应该从右到左阅读。把鼠标指针悬停在一个图标上会显示该图 标描述的进程的附加信息，这有助于决定如何优化该进程。例如，若是一个进程显示了一 个没必要要的隐式转换，则能够对传递的数据类型执行更严格的检査以免隐式转换。提示：图 10-14中显示的信息实际上被保存为XML。这对于那些想在用于分析查询计划和识别 要改进的区域的分析应用程序(例如数据库优化顾问）中使用ShowPlan数据的组织来讲特别有 吸引力。将名称 QueryTuning_4.SQLPlan 改成 QueryTuning_4.XML„ 右击 QueryTuning_4.XML 文件，选择“打开方式… Internet Explorer”命 令 。显 示 的 ShowPlan文件经过Internet Explorer 内置的XML分析器呈现，并很容易被标识为一个XML文件•