一、概述

在数据库应用中，速度是一个永恒的话题。有许多因素会影响数据库的性能表现，例如：操作系统，硬件方面的因素,如内存和磁盘空间，访问数据库的应用软件。除此之外，数据库本身的设计也是一个影响性能的重要因素。

本文要讨论的是我们可以采取哪些措施提高SQL Server数据库的性能。讨论的焦点主要集中在SQL Server 2000为视图创建索引的能力，以及如何使用Index Tuning Wizard（ITW，索引调整向导）优化索引。另外，我们还要讨论如何确保查询充分地利用了索引以及数据库统计信息。

性能问题应该在数据库设计的初始阶段就开始考虑。不过，即使在数据库正式开始运行之后，我们仍旧可以进行一些修改，这些修改将显著地影响数据库的性能表现。索引是一种优化数据查询和排序操作的数据库实体，正确配置的索引能够使数据库查询或更新数据所需要的时间发生巨大的变化，ITW能够帮助我们确定如何在数据库中配置索引以获得最佳的性能。

我们可以让ITW根据指定的Workload（工作负荷）推荐最佳的数据库索引配置。Workload是保存到外部文件的SQL脚本或跟踪结果。ITW的建议是根据给定Workload而提出的最优化建议，因此事先准备合适的基础数据非常重要。

为ITW创建工作负荷文件最简单、最全面的方法或许应该是保存由SQL Profiler创建的跟踪。SQL Profiler是自SQL Server 7.0开始提供的新工具。它能够用指定的过滤器和条件，记录服务器的活动情况。使用SQL Profiler为ITW创建跟踪时，应当确保跟踪已经记录了典型的数据库活动。换句话说，应当选择一个数据库负载不是特别繁重、也不是特别轻松的时段进行跟踪。至于跟踪要运行多少长时间，这由系统本身的特点决定。有些时候，我们可能只需跟踪数小时就可以得到系统典型活动情况的记录；有些时候，我们可能要让跟踪持续几天，才能记录下数据库中所有典型的活动情况。

二、索引调整向导

准备好工作负荷文件之后，我们就可以在Enterprise Manager的树形视图中选择服务器启动ITW。从Tools菜单选择Wizards，在树形视图中找到Management节点，选择Index Tuning Wizard，此时我们就可以看到ITW的欢迎屏幕。ITW的第二个屏幕让我们指定要分析的是哪一个服务器和数据库。在这个屏幕上，我们还有另外两个选项：Keep All Existing Indexes（保留现有索引），Perform Thorough Analyses（进行完全分析）。清除Keep All Existing Indexes选项使得ITW能够提出最优索引建议，但此时ITW可能建议删除或者修改现有的某些索引。如果你不想修改现有的索引，请保留这个选项的选中状态。选中Perform Thorough Analyses选项使得ITW进行最广泛、深入的分析。虽然进行完全分析可能提高分析结果的质量，但它一般需要较长的时间才能完成；而且完全分析运行时，它很可能导致服务器负载过重。由于这些原因，如果你需要执行完全分析，那么最好在测试服务器上进行，或者在正式提供服务的机器上，选择一个比较空闲的时段进行。

ITW的第三个屏幕让我们指定对哪一个workload进行分析。如果你使用的是SQL Profiler创建的文件，请选择My Workload File选项按钮，然后在文件对话框中找到以前保存的跟踪文件。在这个屏幕中，点击Advanced Options命令按钮可以设置一些高级选项。这些选项包括：被推荐的索引可以使用的最大磁盘空间总量，工作负荷文件中查询取样的最大数量。

在第四个屏幕中，我们可以指定ITW应该对哪个或者哪些表的索引提出建议。只选择那些相关的表有利于节省时间，而且它有助于我们把注意力集中到特定的问题之上。不过，如果要让ITW对整个数据库的优化提出建议，我们应该选中数据库里面所有的表。ITW的下一个屏幕根据我们设定的条件，显示出它对索引配置的建议（参见图1）。我们可以选择立即执行它提出的建议，或者计划在以后执行，或者把执行脚本保存到外部文件。

图1

ITW不会对主键或者其他唯一性索引提出建议，也不会对系统表的索引提出建议。ITW的其他局限还包括：在给定的工作负荷中，它分析的索引不能超过32767个；不能对SQL Server 6.5或者更早版本创建的数据库提出索引建议。

注意，ITW是以用户所提供数据的样本为基础提出索引配置建议。由于这个原因，你可能会发现：如果让ITW对同一个工作负荷分析多次，它可能会提出多种不同的索引配置建议。如果ITW不能提出任何建议，它可能是由于下面两种原因之一造成：第一，与数据库中现有的索引配置方案相比，ITW无法提出任何能够进一步提高性能的索引建议；第二；取样的表里面没有足够的数据，无法确定一个合适的索引配置方案。

三、视图索引

SQL Server 2000企业版除了能够创建表的索引，它还能够创建视图的索引。假设我们对Pubs数据库中每一份订单的销售总量感兴趣。下面的代码在Pubs数据库中创建一个名为Quantity_Totals的视图，该视图除了提供上述信息之外，还提供了订单所包含项目的总数：

Use Pubs GO CREATE VIEW Quantity_Totals with SCHEMABINDING AS SELECT ord_num, Total_Quantity = Sum(qty), Total_Items = Count_Big(*) FROM dbo.sales GROUP BY ord_num

COUNT_BIG是SQL Server 2000提供的一个新函数，它的功能与COUNT函数相同。COUNT_BIG和COUNT的不同之处在于，COUNT_BIG返回值是bigint类型，而COUNT返回值是int类型。任何包含GROUP BY子句的视图，如果要使用索引就必须包含COUNT_BIG函数。我们可以用SCHEMABINDING选项创建包含索引的视图。SCHEMABINDING选项是SQL Server 2000的新功能，如果我们指定了SCHEMABINDING选项，视图将被绑定到其基表的模式。

如果视图不包含索引，则数据库中不保存视图返回的结果集。有的时候，我们可能要创建涉及大量记录或必须进行复杂计算的视图，比如要进行聚合分组处理或多重连接操作。如果每次引用这些视图的时候让SQL Server重新生成结果集，数据库开销将非常大。

视图的索引与表的索引在作用方式上非常相似。与表一样，视图可以有一个集簇索引（Clustered Index）和多个非集簇索引。然而，在创建任何非集簇索引之前，我们必须先为视图创建一个唯一性的集簇索引。如果我们创建了视图的集簇索引，数据库将永久保存视图的结果集。虽然创建索引时所保存的结果集只反映当时的数据状态，但任何对基表数据的修改都将自动反应到这个结果集之中。

就象为表创建索引一样，我们可以用CREATE INDEX命令为视图创建索引：

CREATE UNIQUE CLUSTERED INDEX PRIMARY_IDX on Quantity_Totals(ord_num)

上面的代码为我们前面例子中创建的Quantity_Totals视图创建了一个唯一性的集簇索引。创建视图索引不仅能够提高视图的性能，而且有些时候性能的提高达到出乎意料的程度。一旦我们为视图创建并保存了索引，即使对于那些没有直接在FROM子句中引用该视图的查询，Query Optimizer（查询优化器）也可能选择使用该视图索引来提高查询速度。例如，下面这个SQL命令选择出按照订单编号分组的销售数量累计：

SELECT ord_num, Sum(qty) FROM sales GROUP BY ord_num

执行这个查询时，Query Optimizer知道：在SQL Server为Quantity_Totals视图创建的索引中，这个销售数量的累计值已经存在。在这种情况下，Query Optimizer会作出这样的判断：如果使用为视图创建的索引，查询的效率将有很大的提高。

在为视图创建索引之前，你必须检查视图是否满足创建视图索引的各种条件。下表列出了这些条件中的一部分：

四、影响查询性能的因素

除了数据库的物理设计之外，我们用来保存和提取数据的查询命令的结构也会对性能产生重大影响。内存或者磁盘空间不足之类的硬件问题会降低查询的效率；然而，Query Optimizer不能有效地利用索引或者统计信息也是导致查询性能低劣的主要原因之一。统计信息由关于列里面数据分布情况的信息构成。查询优化器运用统计信息帮助确定执行查询的最优方法。当我们为一个或者多个列创建索引时，SQL Server将自动生成这些索引列的统计数据。默认情况下，SQL Server的Auto Create Statistics数据库选项设置成True。Auto Create Statistics设置成True的结果是，SQL Server同时为表里面的其他列自动生成统计数据。

SQL Server除了生成初始的统计信息之外，它还会定期地更新这些信息。更新这些信息的频繁程度，由列和索引数据的变化频繁程度以及列和索引的数据规模决定。大多数时候，无论是生成初始的统计信息还是更新这些统计信息，SQL Server都能够高效地完成，我们无需进行任何手工干预。但是，有些时候我们可能会发现，系统不能顺利地为表生成必需的初始统计信息，或者这些统计信息更新不够及时。

我们可以用DBCC SHOW_STATISTICS这个T-SQL命令查看索引列的当前统计信息。这个命令有两个参数，第一个参数指出要查看的是哪一个表的统计信息，第二个参数是索引的名字。例如，如果我们在Query Analyzer（查询分析器）中执行下面这个SQL命令，它将显示出有关Pubs数据库中authors表aunmind索引的统计信息：

DBCC SHOW_STATISTICS命令返回的结果中包含了SQL Server最后一次更新统计信息的日期和时间，以及SQL Server用来计算统计信息的采样记录数。

图2

我们可以在Query Analyzer中通过图形用户界面管理非索引列的统计信息，具体操作方法是：启动Query Analyzer，从Tools菜单选择Manage Statistics；在Manage Statistics对话框（图2）中选择要管理哪个数据库以及表或视图的统计信息。

Query Analyzer把所有现有的统计信息放入屏幕底部的列表框。选中一个统计项目，点击Delete或Upate按钮就可以删除或者更新统计信息。如果点击New命令按钮，我们将看到Create Statistic对话框。创建新的统计项目时，我们可以选择的参数包括：要包含哪个或者哪些列，SQL Server生成统计信息时从这些列读入取样数据的百分比，是否要求SQL Server在必要时自动更新统计数据。允许SQL Server自动更新统计信息是一种比较好的选择，因为SQL Server通常都能够高效地完成这一任务，而手工完成却非常麻烦。

除了用Query Analyzer提供的图形用户界面生成、更新统计数据之外，我们还可以用CREATE STATISTICS和UPDATE STATISTICS这些T-SQL命令来完成同样的任务。

五、查询执行计划

要了解查询是否充分利用了索引和统计信息，一种方法是使用Query Analyzer查看查询的执行计划。启动Query Analyzer并装入查询，从Query菜单选择Show Execution Plan、执行查询。在查询结果的下面，我们可以看到一个名为Execution Plan的卡式子窗口。点击Execution Plan即可查看查询的执行计划。另外，在不实际运行查询的情况下，我们也可以查看执行计划，这时的执行计划是“期望中的执行计划”。从Query菜单选择Display Expected Execution Plan，我们就可以看到一个图，它描述了一个估计的查询执行计划。这个图显示了Query Optimizer为执行查询已经（或者准备）采取的措施。从各个步骤的详细说明中，我们可以了解哪一个步骤最耗时、哪一个步骤占用资源最多，以及Query Optimizer是否使用了索引。

图3

如果Query Optimizer发现某个表的统计信息已经丢失或者过期，它会把表的标题显示成红色。把鼠标停留到表示表的图标上面，我们就可以从一个弹出式窗口中看到关于该步骤的更多说明，如图3所示。SQL Profiler是一个帮助我们判断哪一个查询导致性能问题并需要进一步分析优化的优秀工具；SQL Profiler能够通过记录服务器的具体活动指出哪些查询和SQL命令效率低下。总而言之，数据库性能优化涉及到相当广泛的问题。单纯地保证系统有正确的索引和统计信息，对于数据库全面优化来说是不够的。然而，它们是能够显著改善数据库响应时间的重要措施。我们只要稍微花上一点时间，就可以利用SQL Server的工具精心调整查询，使得查询能够充分利用索引和统计信息。

本页内容

	概述
	Profiler trace文件性能分析的传统方法以及局限
	Read80trace工具介绍以及它的Normalization 功能
	使用存储过程分析Normalize后的数据
	使用usp_GetAccessPattern的一些技巧
	蛇足：哪个是HOT 数据库？

概述

当你的SQL Server数据库系统运行缓慢的时候，你或许多多少少知道可以使用SQL Server Profiler（中文叫SQL事件探查器）工具来进行跟踪和分析。是的，Profiler可以用来捕获发送到SQL Server的所有语句以及语句的执行性能相关数据（如语句的read/writes页面数目，CPU的使用量，以及语句的duration等）以供以后分析。但本文并不介绍如何使用Profiler 工具，而是将介绍如何使用read80trace（有关该工具见后面介绍）工具结合自定义的存储过程来提纲挈领地分析Profiler捕获的Trace文件，最终得出令人兴奋的数据分析报表，从而使你可以高屋建瓴地优化SQL Server数据库系统。

本文对那些需要分析SQL Server大型数据库系统性能的读者如DBA等特别有用。在规模较大、应用逻辑复杂的数据库系统中Profiler产生的文件往往非常巨大，比如说在Profiler中仅仅配置捕获基本的语句事件，运行二小时后捕获的Trace文件就可能有GB级的大小。应用本文介绍的方法不但可以大大节省分析Trace的时间和金钱，把你从Trace文件的海量数据中解放出来，更是让你对数据库系统的访问模式了如指掌，从而知道哪一类语句对性能影响最大，哪类语句需要优化等等。

返回页首

Profiler trace文件性能分析的传统方法以及局限

先说一下什么是数据库系统的访问模式。除了可以使用Trace文件解决如死锁，阻塞，超时等问题外，最常用也是最主要的功能是可以从Trace文件中得到如下三个非常重要的信息：

本文提到的访问模式就是上面三个信息。我们知道，数据库系统的模块是基本固定的，每个模块访问SQL Server的方式也是差不多固定的，具体到某个菜单，某个按钮，都是基本不变的，所以，在足够长的时间内，访问SQL Server的各类语句及其占用的比例也基本上是固定的。换句话说，只要Profiler采样的时间足够长（我一般运行2小时以上），那么从Trace文件中就肯定可以统计出数据库系统的访问模式。每一个数据库系统都有它自己独一无二的访问模式。分析Profiler Trace文件的一个重要目标就是找出数据库系统的访问模式。一旦得到访问模式，你就可以在优化系统的时候做到胸有成竹，心中了然。可惜直到目前为止还没有任何工具可以方便地得到这些信息。

传统的Trace分析方法有两种。一种是使用Profiler工具本身。比如说可以使用Profiler的Filter功能过滤出那些运行时间超过10秒以上的语句，或按照CPU排序找出最耗费CPU的语句等。另一种是把Trace文件导入到数据库中，然后使用T-SQL语句来进行统计分析。这两种方法对较小的Trace文件是有效的。但是，如果Trace文件数目比较多比较大（如4个500MB以上的trace文件），那么这两种方法就有很大的局限性。其局限性之一是因为文件巨大的原因，分析和统计都非常不易，常常使你无法从全局的高度提纲挈领地掌握所有语句的执行性能。你很容易被一些语句迷惑而把精力耗费在上面，而实际上它却不是真正需要关注的关键语句。局限性之二是你发现尽管很多语句模式都非常类似（仅仅是执行时参数不同），却没有一个简单的方法把他们归类到一起进行统计。简而言之，你无法轻而易举地得到数据库系统的访问模式，无法在优化的时候做到高屋建瓴，纲举目张。这就是传统分析方法的局限性。使用下面介绍的Read80trace工具以及自定义的存储过程可以克服这样的局限性。

返回页首

Read80trace工具介绍以及它的Normalization 功能

Read80Trace工具是一个命令行工具。使用Read80Trace工具可以大大节省分析Trace文件的时间，有事半功倍的效果。Read80Trace的主要工作原理是读取Trace文件，然后对语句进行Normalize (标准化)，导入到数据库，生成性能统计分析的HTML页面。另外，Read80trace可以生成RML文件，然后OSTRESS工具使用RML文件多线程地重放Trace文件中的所有事件。这对于那些想把Profiler捕获的语句在另外一台服务器上重放成为可能。本文不详细介绍Read80trace或OStress工具，有兴趣的读者请自行参阅相关资料，相关软件可以从微软网站下载（注：软件名称为RML，http://www.microsoft.com/downloads/）。

我要利用的是Read80Trace的标准化功能。什么是标准化？就是把那些语句模式类似，但参数不一样的语句全部归类到一起。举例说Trace中有几条语句如下：

select * from authors where au_lname = 'white'
select * from authors where au_lname = 'green'
select * from authors where au_lname = 'carson'

经过标准化后，上面的语句就变成如下的样子：

select * from authors where au_lname = {str}
select * from authors where au_lname = {str}
select * from authors where au_lname = {str}

有了标准化后的语句，统计出数据库系统的访问模式就不再是难事。运行Read80trace 的时候我一般使用如下的命令行：

Read80trace –f –dmydb –Imytrace.trc

其中－f开关是不生成RML文件，因为我不需要重放的功能。生成的RML文件比较大，建议读者如果不需要重放的话，也使用－f开关。

－d开关告诉read80trace把trace文件的处理结果存到mydb数据库中。我们后面创建的存储过程正是访问read80trace在mydb中生成的表来进行统计的。－I开关是指定要分析的的trace文件名。Read80trace工具很聪明，如果该目录下有Profiler产生的一系列Trace文件，如mytrace.trc,mytrace1.trc,mytrace2.trc等，那么它会一一顺序读取进行处理。

除了上面介绍的外，Read80trace还有很多其它有趣的开关。比如说使用－i开关使得Read80trace可以从zip或CAB文件中读取trace文件，不用自己解压。所有开关在Read80trace.chm中有详细介绍。我最欣赏的地方是read80trace的性能。分析几个GB大小的trace文件不足一小时就搞定了。我的计算机是一台内存仅为512MB的老机器，有这样的性能我很满意。

你也许会使用read80trace分析压力测试产生的trace文件。我建议还是分析从生产环境中捕获的Trace文件为好。因为很多压力测试工具都不能够真正模拟现实的环境，其得到的trace文件也就不能真实反映实际的情况。甚至有些压力测试工具是循环执行自己写的语句，更不能反映准确的访问模式。建议仅仅把压力测试产生的trace作为参考使用。

返回页首

使用存储过程分析Normalize后的数据

有了标准化后的语句就可以使用存储过程进行统计分析了。分析的基本思想是把所有模式一样的语句的Reads，CPU和Duration做group by统计，得出访问模式信息：

存储过程的定义以及说明如下：

/*************************************************************/
Create procedure usp_GetAccessPattern 8000
@duration_filter int=-1 --传入的参数，可以按照语句执行的时间过滤统计
as begin
/*首先得到全部语句的性能数据的总和*/
declare @sum_total float,@sum_cpu float,@sum_reads float,@sum_duration float,@sum_writes float
select @sum_total=count(*)*0.01,--这是所有语句的总数。
@sum_cpu=sum(cpu)*0.01, --这是所有语句耗费的CPU时间
@sum_reads=sum(reads)*0.01, --这是所有语句耗费的Reads数目，8K为单位。
@sum_writes=sum(writes)*0.01,--这是所有语句耗费的Writes数目，8K为单位。
@sum_duration=sum(duration)*0.01--这是所有语句的执行时间总和。
from tblBatches --这是Read80Trace产生的表，包括了Trace文件中所有的语句。
where duration>=@duration_filter --是否按照执行时间过滤
/*然后进行Group by，得到某类语句占用的比例*/
Select ltrim(str(count(*))) exec_stats,''+ str(count(*)/@sum_total,4,1)+'%' ExecRatio,
ltrim(str(sum(cpu)))+' : '++ltrim(str(avg(cpu))) cpu_stats,''+str(sum(cpu)/@sum_cpu,4,1)+'%' CpuRatio,
ltrim(str(sum(reads) ))+' : '+ltrim(str(avg(reads) )) reads_stats,''+str(sum(reads)/@sum_reads,4,1)  +'%' ReadsRatio ,
--ltrim(str(sum(writes) ))+' : '+ltrim(str(avg(writes) )) --writes_stats,''+str(sum(writes)/@sum_writes,4,1) +'%)',
ltrim(str(sum(duration) ))+' : '+ltrim(str(avg(duration))) duration_stats,''+str(sum(duration)/@sum_duration,4,1)+'%' DurRatio ,
textdata,count(*)/@sum_total tp,sum(cpu)/@sum_cpu cp,sum(reads)/@sum_reads rp,sum(duration)/@sum_duration dp
into #queries_staticstics from
/* tblUniqueBatches表中存放了所有标准化的语句。*/
(select reads,cpu,duration,writes,convert(varchar(2000),NormText)textdata from tblBatches
inner join tblUniqueBatches on tblBatches.HashId=tblUniqueBatches.hashid where duration>@duration_filter
) B group by textdata --这个group by很重要，它对语句进行归类统计。
print 'Top 10 order by cpu+reads+duration'
select top 10 * from #queries_staticstics order by cp+rp+dp desc
print 'Top 10 order by cpu'
select top 10 * from #queries_staticstics order by cp desc
print 'Top 10 order by reads'
select top 10 * from #queries_staticstics order by rp desc
print 'Top 10 order by duration'
select top 10 * from #queries_staticstics order by dp desc
print 'Top 10 order by batches'
select top 10 * from #queries_staticstics order by tp desc
End
/*************************************************************/

考虑到输出结果横向较长，存储过程中把writes去掉了。这是因为大部分的数据库系统都是Reads为主的。你可以轻易的修改存储过程把write也包括进去。

存储过程并不复杂，很容易理解。可以看到统计的结果放在queries_staticstics表中，然后按照不同的条件排序后输出。举例说：

select top 10 *  from #queries_staticstics order by cp desc

上面的语句将把queries_staticstics表中的记录按照某类语句占用总CPU量的比例cp（即sum(cpu)/@sum_cpu）进行排序输出。这让你在分析服务器CPU性能问题的时候快速定位哪一类语句最耗CPU资源，从而对症下药。

现在让我们看一个实例的输出：

/********************/
Use mydb
Exec usp_GetAccessPattern
/*你可以输入一个执行时间作为过滤参数，毫秒为单位。如usp_GetAccessPattern 1000*/
/********************/

输出结果如图 1所示（是部分结果，另外，因为原输出结果横向很长，为方便阅读，把结果从中截断为两部分）：

图 1：输出结果采样一

上面的例子采样于一家大型公司的业务系统。该系统的问题是应用程序运行缓慢，SQL Server 服务器的CPU高居不下（8个CPU都在90%～100%间波动）。我使用PSSDIAG工具采样2小时左右的数据，然后运行read80trace和usp_GetAccessPattern得出上面的结果。报表一目了然。存储过程DBO.x_DEDUP_PROC在两小时内共运行75次，却占用了90.8％的CPU资源，94.6%的Reads，从访问模式的角度，该存储过程正是导致CPU高和系统性能慢的关键语句。一旦优化了该存储过程，系统的性能问题将迎刃而解。你也许有疑问，两小时内共运行75次,不是很频繁啊。其实你看看这条存储过程的平均CPU时间是681961毫秒，大概11分钟左右。也就是说一个CPU两小时内最多可以执行（60*2）/11＝10条左右，该系统总共有8个CPU，即使全部CPU都用来运行该语句，那么最多也就是10*8＝80条左右。上面执行总数是75，说明该存储过程一直在连续不断地运行。

那么该系统运行最频繁的语句是什么呢？我从结果中摘取另外一部分如下（图 2）：

图 2：输出结果采样二

从上表可以看出，最频繁运行的语句是

USE xb SET QUOTED_IDENTIFIER,ANSI_NULL_DFLT_ON…

显然这是一条执行环境配置语句，没有参考价值。倒是另外两条占用语句总数8.2%的语句值得关注：

SELECT COUNT(*) FROM x_PROCESS_STATS WHERE PROCESS……
SELECT COUNT(*) FROM x_PROCESS_STATS WHERE PROCESS……

在这个例子中，因为关键语句DBO.x_DEDUP_PROC非常突出，甚至上面的两条语句都可以忽略了。

让我们再多看一个例子（图 3）：

图 3：输出结果采样三

从上面的例子中, 可以得出关键的语句是:

SELECT COUNT(*) FROM GTBL7MS
SELECT CaseNO FROM PATIENTDATA_sum WHERE MRN = @P1

后续的检查发现相关的表没有有效的索引，加上索引后性能立即整体地提高了不少.。解决了这两个语句，需要使用同样的手段继续分析和优化，直到系统的性能能够接受为止.。注意性能调优是一个长期的过程，你不太可能一两天就可以把所有的问题都解决。也许一开始可以解决80%的问题，但是后面20%的问题却需要另外80%的时间。

返回页首

使用usp_GetAccessPattern的一些技巧

usp_GetAccessPattern的输出报表包含了非常丰富的信息。分析报表的时候需要有大局观。你也可以有目的性地选择你需要的信息。如果是CPU性能瓶颈的系统，那么你需要关注CPU占用比例高的那类语句。如果是磁盘IO出现性能瓶颈那么你需要找到那些Reads占用比例大而且平均reads也很高的语句。需要注意的是有时候运行频繁的语句未必就是你需要关注的关键语句。一个最理想的情况是关键语句正好就是最频繁的语句。有时候即使最频繁语句占用的资源比例不高，但如果还可以优化，那么因为放大效应，微小的优化也会给系统带来可观的好处。

在使用usp_GetAccessPattern的时候多结合@duration_filter参数使用。因为参数以毫秒为单位，建议参数不要小于1000，而应该是1000的倍数 如3000，5000等。该参数常常会给出非常有意思的输出。该输出和不带参数运行的结果会有某些重叠。重叠出现的语句通常正是需要关注的语句。要注意运行最多最密的语句未必有超过1000毫秒的执行时间，所有带参数运行的结果有可能不包括最频繁语句。我常常同时交叉分析四个结果，一个是不带参数运行得到的，另三个分别是使用1000，3000和5000毫秒为参数运行的结果。比较分析这四个结果往往使我对数据库系统的访问模式有非常清晰透彻的理解。

运行存储过程时你也许会碰到int整数溢出的错误。这是因为表tblBatches 中的reads,cpu 和writes字段是int而不是bigint。可以运行如下语句进行修正：

alter table tblBatches  alter column  reads bigint
alter table tblBatches  alter column  cpu bigint
alter table tblBatches  alter column  writes bigint

修正后溢出问题就会解决。

返回页首

蛇足：哪个是HOT 数据库？

本文到这里就基本上结束了。你已经知道如何使用Read80Trace和usp_GetAccessPattern得到数据库系统的访问模式，以及如何从全局的高度去分析访问模式报表，从而在优化系统的时候做到提纲挈领，胸有成竹。

除此之外，你还可以应用类似的分析思想得到每个数据库的占用资源比例。这对于SQL Server有多个数据库的情况非常有用。从报表中你可以立即知道哪个数据库是最HOT最消耗系统资源的数据库。语句如下：

print 'group by dbid'
declare @sum_total float,@sum_cpu float,@sum_reads float,@sum_duration float,@sum_writes float
select @sum_total=count(*)*0.01,@sum_cpu=sum(cpu)*0.01,@sum_reads=sum(reads)*0.01,@sum_writes=sum(writes)*0.01,
@sum_duration=sum(duration)*0.01 from tblBatches
select dbid,
ltrim(str(count(*))) exec_stats,''+ str(count(*)/@sum_total,4,1)+'%' ExecRatio,
ltrim(str(sum(cpu)))+' : '++ltrim(str(avg(cpu))) cpu_stats,''+str(sum(cpu)/@sum_cpu,4,1)+'%' CpuRatio ,
ltrim(str(sum(reads) ))+' : '+ltrim(str(avg(reads) )) reads_stats,''+str(sum(reads)/@sum_reads,4,1)  +'%' ReadsRatio ,
ltrim(str(sum(duration) ))+' : '+ltrim(str(avg(duration))) duration_stats,''+str(sum(duration)/@sum_duration,4,1)+'%' DurRatio ,
count(*)/@sum_total tp,sum(cpu)/@sum_cpu cp,sum(reads)/@sum_reads rp,sum(duration)/@sum_duration dp
into #queries_staticstics_groupbydb from
(select reads,cpu,duration,writes,convert(varchar(2000),NormText)textdata,dbid from tblBatches
inner join tblUniqueBatches on tblBatches.HashId=tblUniqueBatches.hashid
) b group by dbid order by sum(reads) desc
select dbid,ExecRatio batches,CPURatio CPU,ReadsRatio Reads,DurRatio Duration
from #queries_staticstics_groupbydb

下面是一个上面语句结果的一个例子：

dbid    batches   CPU        Reads       Duration
------  -------   -----   -------       --------
37      21.1%     18.7%      29.1%       27.1%
33      12.7%     32.4%      19.5%       24.8%
36       5.6%     28.3%      15.6%       26.1%
20      53.9%      2.9%      14.2%        2.1%
22       0.8%      7.2%      13.2%        6.6%
25       1.0%      3.6%       5.4%        3.5%
16       0.0%      1.5%       1.9%        0.7%
35       2.0%      2.7%       1.8%        5.7%
7        0.1%      0.1%       1.1%        0.3%

上面的结果明确地告诉我们ID为37，33和36的数据库是最活跃的数据库。一个有趣的事实是数据库20发出的语句总数比例是53.9%，但是其占用的系统资源比例却不高。

SELECT CASE ("欄位名")
  WHEN "條件1" THEN "結果1"
  WHEN "條件2" THEN "結果2"
  ...
  [ELSE "結果N"]
  END
FROM "表格名"

"條件" 可以是一個數值或是公式。 ELSE 子句則並不是必須的。

在我們的 Store_Information 中

Store_Information 表格

store_name	Sales	Date
Los Angeles	$1500	Jan-05-1999
San Diego	$250	Jan-07-1999
San Francisco	$300	Jan-08-1999
Boston	$700	Jan-08-1999

若我們要將 'Los Angeles' 的 Sales 數值乘以2，以及將 'San Diego' 的 Sales 數值乘以1.5，我們就鍵入以下的 SQL：

SELECT store_name, CASE store_name
  WHEN 'Los Angeles' THEN Sales * 2
  WHEN 'San Diego' THEN Sales * 1.5
  ELSE Sales
  END
"New Sales",
Date
FROM Store_Information

"New Sales" 是用到 CASE 那個欄位的欄位名。

結果:

EXISTS 的語法是：

SELECT "欄位1"
FROM "表格1"
WHERE EXISTS
(SELECT *
FROM "表格2"
WHERE [條件])

在內查詢中，我們並不一定要用 * 來選出所有的欄位。我們也可以選擇表格2中的任何欄位。這兩種做法最後的結果是一樣的。

來看一個例子。假設我們有以下的兩個表格：

Store_Information 表格

store_name	Sales	Date
Los Angeles	$1500	Jan-05-1999
San Diego	$250	Jan-07-1999
Los Angeles	$300	Jan-08-1999
Boston	$700	Jan-08-1999

Geography 表格

region_name	store_name
East	Boston
East	New York
West	Los Angeles
West	San Diego

而我們打入的 SQL 是:

SELECT SUM(Sales) FROM Store_Information
WHERE EXISTS
(SELECT * FROM Geography
WHERE region_name = 'West')

我們會得到以下的答案：

SUM(Sales)

2750