SQLServer性能优化工具-2023修改整理

千里之行，始于足下让知识带有温度。第第2页/共2页精品文档推荐SQLServer性能优化工具SQLServer性能优化工具

数据和工作负荷示例

使用下例说明SQLServer性能工具的使用。首先创建下表。

createtabletesttable(nkey1intidentity,col2char(300)default'abc',ckey1char(1))

接下来，在这个表中填充10,000行测试数据。可以为列nkey1中所填充的数据创建非聚拢索引。可以为列ckey1中的数据创建聚拢索引，col2中的数据仅仅是填充内容，将每一行增强300字节。

declare@counterint

set@counter=1

while(@counter0)rollbacktransaction

CREATECLUSTEREDINDEX[testtable2]ON[dbo].[testtable]([ckey1])

if(@@error0)rollbacktransaction

COMMITTRANSACTION

IndexTuningWizard为示例表和数据所建议的索引就是我们预期

的索引。ckey1惟独5个唯一值，且每一个值都有2,000行。假定其中的一个示例查询(selectckey1,col2fromtesttablewhereckey1='a')要求按照ckey1中的某个值对表举行检索，那么在ckey1列中创建聚拢索引是故意义的。其次个查询(selectnkey1,col2fromtesttablewherenkey1=5000)按照列nkey1的值提取一行。Nkey1唯一，且有10,000行，因此在该列创建非聚拢的索引是故意义的。

Profiler/IndexTuningWizard组合在涉及许多表和许多查询的实际数据库服务器环境中功能十分强大。当数据库正在举行典型查询时，请使用Profiler记录.trc文件。然后将.trc文件装载到IndexTuningWizard，以确定是否创建了正确的索引。按照IndexTuningWizard中的提醒自动生成并调度索引创建作业以便在非尖峰时刻运行。定期运行Profiler/IndexTuningWizard（比如每周）以查看数据库服务器中所执行的查询是否有较大改动，假如是，则可能需要不同的索引。定期使用Profiler/IndexTuningWizard有助于数据库管理员在查询工作负荷转变以及数据库大小随着时光而增强的同时，保持SQLServer以最佳状态运行。

有关具体信息，请在SQLServerBooksOnline中搜寻“IndexTuningWizard”和“IndexTuningRecommendations”。

将Profiler信息加载到SQLServer表以举行分析

Profiler提供的另一个选项是将信息记录在SQLServer表中。完成后，就可以查询囫囵表以确定是否有某些查询消耗了过多资源。

将Profiler信息记录在SQLServer表中

从SQLServerEnterpriseManager菜单中挑选Tools/SQLServerProfiler启动Profiler。

按CTRL+N组合键新建Profiler跟踪。

键入跟踪的名称。

单击CapturetoTable:复选框，然后挑选要将Profiler信息输出到其中的SQLServer表。

单击OK。

结束后，单击红色的正方形停止Profiler跟踪。

用QueryAnalyzer分析Profiler中记录的信息

在将这些信息记录到SQLServer表中后，可以用QueryAnalyzer计算出系统中的哪些查询消耗资源最多。这样，数据库管理员就可以集中时光改进最需要协助的查询。例如，通常用以下查询分析从Profiler记录到SQLServer表中的数据。此查询检索数据库服务器中消耗CPU资源最多的头3项。返回读和写I/O信息以及查询的持续时光（用毫秒计）。假如用Profiler记录了大量的信息，那么在这个表中创建索引以加快分析查询是故意义的。例如，假如CPU即将成为分析这个表

的一个重要标准，那么在CPU列创建非聚拢索引应当是一个不错的想法。

selecttop3TextData,CPU,Reads,Writes,Durationfromprofiler_out_tableorderbycpudesc

有关具体信息，请在SQLServerBooksOnline中搜寻字符串“ViewingandAnalyzingTraces”、“TroubleshootingSQLServerProfiler”、“TipsforUsingSQLServer”、“CommonSQLServerProfilerScenarios”、“StartingSQLServerProfiler”和“MonitoringwithSQLServerProfiler”。

QueryAnalyzer

I/O统计信息

QueryAnalyzer的ConnectionsOptions对话框General选项卡中提供了一个ShowstatsI/O选项。挑选此复选框可以猎取有关QueryAnalyzer中正在执行的查询所消耗I/O量的信息。

例如，当挑选ShowstatsI/O选项时，查询“selectckey1,col2fromtesttablewhereckey1='a'”除返回结果集以外，还返回以下I/O信息：

Table'testtable'.Scancount1,logicalreads400,physical

reads382,read-aheadreads400.

同样，当挑选ShowstatsI/O选项时，查询“selectnkey1,col2fromtesttablewherenkey1=5000”除了返回结果集以外，还返回以下I/O信息：

Table'testtable'.Scancount1,logicalreads400,physicalreads282,read-aheadreads400.

使用I/O统计信息是一种监视查询调节效果的有效办法。例如，在此示例表中创建IndexTuningWizard在上面所推举的两个索引，然后再次运行查询。

在“selectckey1,col2fromtesttablewhereckey1='a'”的查询中，聚拢索引改进性能的状况如下所示。假定查询需要提取该表的20%，则性能改进应当是比较合理的：

Table'testtable'.Scancount1,logicalreads91,physicalreads5,read-aheadreads32.

在“selectnkey1,col2fromtesttablewherenkey1=5000”的查询中，创建非聚拢索引对于查询的性能有着很显著的影响。假定此查询只需要从10,000行的表中提取一行，那么用非聚拢索引改善性能应当是比较合理的：

Table'testtable'.Scancount1,logicalreads5,physicalreads0,read-aheadreads0.

ShowPlan

通过显示Queryoptimizer正在执行的任务的具体信息，使用ShowPlan可将注重力集中在有问题的SQL查询上。SQLServer7.0提供ShowPlan的文本版和图形版。通过用CTRL+L执行SQL查询，可以将GraphicalShowPlan的输出显示在QueryAnalyzer的Results窗格中。图标表示假如查询已执行，那么Queryoptimizer应当已执行的操作。箭头表示查询的数据流的方向。将鼠标放置在操作图标上，可以显示出各个操作的具体信息。执行setshowplan_allon命令可以在基于文本的ShowPlan中显示出等价的信息。假如要跳过操作的具体信息的显示，以削减显示Queryoptimizer操作的基于文本的ShowPlan的输出，可执行命令setshowplan_texton。

有关具体信息，请在SQLServerBooksOnline中搜寻字符串“GraphicalShowPlan”、“UsingShowPlantoMonitoraDatabaseQuery”、“worktables”和“UnderstandingNestedLoopsJoins”。

ShowPlan输出的示例

使用前面所定义的查询示例并在QueryAnalyzer中执行setshowplan_texton。

查询：

selectckey1,col2fromtesttablewhereckey1='a'

基于文本的ShowPlan输出：

|--ClusteredIndexSeek(OBJECT:([test].[dbo].[testtable].[testtable2]),

SEEK:([testtable].[ckey1]='a')ORDERED)

上面的查询利用“ClusteredIndexSeek”所示ckey1列上的聚拢索引。

等量的GraphicalShowPlan输出：

图3使用聚拢索引的查询的GraphicalShowPlan输出

假如将聚拢索引从表中删除，那么查询需要使用表扫描。以下ShowPlan输出显示了行为上的改动。

基于文本的ShowPlan输出：

|--TableScan(OBJECT:([test].[dbo].[testtable]),WHERE:([testtable].[ckey1]='a'))

等量的GraphicalShowPlan输出：

图4执行表扫描的查询的GraphicalShowPlan输出

注重：在小型表中举行表扫描无须不安。对于小型表，表扫描是最有效的检索信息的办法。但是对于大型表，假如ShowPlan提出表扫描则是一个警告，说明该表可能需要更好的索引，或者需要对已有索引的统计信息举行更新（这可以使用UPDATESTATISTICS命令来完成）。SQLServer7.0可自动更新索引。使SQLServer自动维护索引统计

信息是一个不错的想法，由于它有助于确保查询始终可以使用良好的索引统计信息。

查询：

selectnkey1,col2fromtesttablewherenkey1=5000

基于文本的ShowPlan输出：

|--BookmarkLookup(BOOKMARK:([Bmk1000]),OBJECT:([test].[dbo].[testtable]))

|--IndexSeek(OBJECT:([test].[dbo].[testtable].[testtable1]),

SEEK:([testtable].[nkey1]=5000)ORDERED)

等量的GraphicalShowPlan输出：

图5利用非聚拢索引的查询的GraphicalShowPlan输出（第1部分）

图6利用非聚拢索引的查询的GraphicalShowPlan输出（第2部分）

上面的查询使用nkey1列上的非聚拢索引。这由nkey1列上的“IndexSeek”操作指定。“BookmarkLookup”操作表示SQLServer需要将指针从索引页跳到表的数据页以检索所哀求的数据。由于查询要求col2列，而该列不是非聚拢索引的一部分，所以需要指针跳跃。

查询：

selectnkey1fromtesttablewherenkey1=5000

基于文本的ShowPlan输出：

|--IndexSeek(OBJECT:([test].[dbo].[testtable].[testtable1]),

SEEK:([testtable].[nkey1]=[@1])ORDERED)

等量的GraphicalShowPlan输出：

图7隐蔽查询的GraphicalShowPlan输出

上面的查询将nkey1上的非聚拢索引作为笼罩索引作用。请注重此查询不需要“BookmarkLookup”（书签查找）操作。这是由于非聚拢索引可提供查询（包括SELECT和WHERE子句）所需要的所有信息。这意味着指针不需要从非聚拢索引页跳跃到数据页。比需要书签查找操作的状况削减了I/O。

PerformanceMonitor

PerformanceMonitor为数据库服务器中所发生的Windows和SQLServer操作提供珍贵的信息。有关SQLServer的特别计数器，请在SQLServerBooksOnline中搜寻字符串组合“SQLServer:”和“object”。

在PerformanceMonitor的图形模式中，请注重Max和Min值。不要太强调平均，由于数据点的严峻两极分化已使其没有太大的实际意义。讨论图形外形，然后将它与Min/Max举行比较，以获得对此行为的精确     了解。使用键以便用白线突出显示计数器。

可以在用PerformanceMonitor将全部可用的WindowsNT和SQLServerPerformanceMonitor对象/计数器记录在日志文件中的同时，交互性地查看PerformanceMonitor（图表模式）。采样间隔的设置确定日志文件大小的增长速度。日志文件可以很快就变得十分大（例

如，假如打开全部的计数器，且采样间隔为15秒，则可以在1小时之内增强100MB）。但测试服务器有望提供几十亿字节的可用空间来存储这些类型的文件。但是，假如节约空间很重要，那么试着在运行时使用较大的日志记录间隔，以便PerformanceMonitor不会如此频繁地对系统举行采样。试试使用30或60秒的时光间隔。这样就可以既做到以合理的频率对全部的计数器举行采样，又能保持较小的日志文件。

PerformanceMonitor还消耗少量的CPU和磁盘I/O资源。假如系统没有大量富余的磁盘I/O和/或CPU，那么可以考虑从另一台计算机中运行PerformanceMonitor以监视网络上的SQLServer（仅图形模式-将性能信息记录在本机的SQLServer上比在局域网或LAN中发送信息效率高），或者仅记录最关键的计数器。

将性能测试运行过程中全部可用的计数器记录在一个文件中以便以后分析是一个不错的想法。这样就可以在以后进一步检查任何计数器。配置PerformanceMonitor以便将全部计数器记录在日志文件中，同时以其它模式（如图形模式）监视最感爱好的计数器。这样可记录全部的信息，但是惟独最感爱好的计数器可以在性能运行的同时展现在整齐的PerformanceMonitor图形中。

启动记录功能

打开PerformanceMonitor。

从今菜单中挑选View/Log。

单击有+符号的按钮。

记录全部计数器的一个容易办法是左键单击AddtoLog对话框中的第一个对象。

按住SHIFT键，使用PAGEDOWN键突出显示全部计数器。

单击Add。

单击Done。

从今菜单中挑选Options/Log。

在FileName:中为要记录的性能信息挑选或创建文件名。

单击StartLog。

停止记录功能

从今菜单中挑选Options/Log。

单击StopLog。

将记录的信息加载到PerformanceMonitor中举行分析

从今菜单中挑选View/Log。

从今菜单中挑选Options/DataFromU。

单击LogFile:选项按钮。

单击有“U”标记的按钮，然后使用OpenInputLogFile文件扫瞄器窗口找到并打开日志文件。双击此文件名。

单击OK。

单击有+符号的按钮。

使用AddtoChart对话框将需要的计数器添加到图形显示中。挑选要添加的object/counter（对象/计数器）组合，然后单击Add。

如何将PerformanceMonitor所记录的大事与时光点关联

此功能对于观看数据库服务器在给定的时光段内所发生的大事非常便利：

使用前面的说明在PerformanceMonitor图表模式中挑选并显示所需要的对象/计数器。

从今菜单中挑选Edit/TimeWindow。

InputLogFileTimeframe对话框将浮现。单击所提供的时光窗口滚动条并按住鼠标左按钮，可以调节将显示在PerformanceMonitor图表中所记录数据的开头和停止时光窗口。

单击OK将图表重新设置为仅显示为所选的时光窗口记录的数据。

要查看的关键PerformanceMonitor计数器

（Physical或Logical）DiskQueue>2

这部分要求观看几个PerformanceMonitor磁盘计数器。要启用这些计数器，从WindowsNT命令窗口运行命令“diskperf-y”，然后重新启动WindowsNT。

当正在举行磁盘排队的物理硬盘获得I/O处理时，将阻挡磁盘I/O哀求。这些驱动器的SQLServer响应时光延伸，从而需要更多的

查询执行时光。

假如使用RAID，必须知道有多少个物理硬盘与WindowsNT视为一个物理驱动器的各个磁盘阵列相连，才干计算出每个物理驱动器的磁盘队列。请教硬件专家关于SCSI通道和物理驱动器分布的概念，以了解SQLServer数据如何放置在每个物理驱动器中以及每个SCSI通道中分布多少SQLServer数据。

可以有几种办法通过PerformanceMonitor查看磁盘队列。规律磁盘计数器对应通过磁盘管理器分配的规律驱动器号，而物理磁盘计数器则对应磁盘管理器视为单个物理磁盘设备的内容。请注重磁盘管理器视为单个物理设备的既可以是单个硬盘，也可以是包含几个硬盘的RAID阵列。CurrentDiskQueue（当前磁盘队列）是磁盘队列的即时测量所得，而AverageDiskQueue（平均磁盘队列）则计算PerformanceMonitor采样期间的平均磁盘队列。请注重以下情形中的全部计数器：LogicalDisk:AverageDiskQueue>2，PhysicalDisk:AverageDiskQueue>2，LogicalDisk:CurrentDiskQueue>2，或PhysicalDisk:AverageDiskQueue>2。

这里所推举的测量数据是为每个物理硬盘所指定的。假如用这种办法测量RAID阵列的磁盘队列，那么这些测量数据应除以RAID阵列中的物理硬盘数，才干确定每个物理硬盘中的磁盘队列。

注重在保存SQLServer日志文件的物理硬盘或RAID阵列中，磁盘队列不是一个很实用的测量数据，由于SQLServerLogManager的队列不会将SQLServer日志文件的多个I/O哀求排队。

有关具体信息，请在SQLServerBooksOnline中搜寻字符串“monitoringdiskactivity”。

System:ProcessorQueueLength>2(perCPU)

这意味着服务器的处理器正在接受超过它们作为组能够举行处理的工作哀求。因此，Windows需要将这些哀求排成队列。

某些处理器队列实际是良好的总体SQLServerI/O性能的指示器。假如没有处理器队列，且CPU利用率很低，那么可能意味着系统的其它地方浮现了性能瓶颈，而最有可能的就是磁盘子系统。处理器队列中有合理的工作量意味着CPU没有闲置，且系统的其它部分与CPU保持同步。

按照阅历法则，好的处理器队列数量是数据库服务器中的CPU数乘以2。

应对显然超过此计算值的处理器队列举行调查。过多的处理器队列

会消耗查询时光。可在处理器队列中分配几个不同的活动。消退强制存储分页和软内存分页有助于节约CPU资源。其它有助于削减处理器队列的办法包括SQL查询调节，提取更好的SQL索引以削减磁盘I/O（并因此而削减CPU的工作负荷）或者在系统中添加更多的CPU（处理器）。

HardPaging-Memory:Pages/sec>0或Memory:PageReads/sec>5

Memory:Pages/sec>0或Memory:PageReads/sec>5表示Windows将通过磁盘解决内存引用（强制分页错误）。这需要消耗磁盘I/O和CPU资源。Memory:Pages/sec是一个指示Windows正在执行的分页数量和数据库服务器当前的RAM配置是否充沛的有效指示器。PerformanceMonitor中的强制分页信息的子集是Windows每秒钟必需读取分页文件以解决内存引用的次数，它用“Memory:PagesReads/sec”表示。假如“Memory:PagesReads/sec>5，那么这对于性能是不利的。

自动SQLServer内存优化尽力动态地调节SQLServer内存使用以避开浮现分页。每秒钟浮现少量的分页是正常的，但是过多的分页则需要订正。

假如SQLServer自动调节内存，那么添加更多的RAM或从数据

库服务器中删除其它应用程序可能会有助于将Memory:Pages/sec降到合理的级别。

假如正在数据库服务器上手动配置SQLServer内存，那么可能有须要削减为SQLServer分配的内存，从数据库服务器中删除其它应用程序或者向数据库服务器中添加更多的RAM。

将Memory:Pages/sec保持在零或临近于零有助于改善数据库服务器的性能。这意味着Windows及其全部的应用程序（包括SQLServer）不通过分页文件来满足内存哀求中的任何数据，所以服务器中的RAM量足够。假如Pages/sec稍大于零也没有关系，但是请记住每次从分页文件而不是RAM中检索数据时，需要付出较高的性能代价（磁盘

I/O）。

有须要花一点时光来了解“Memory:PagesInput/sec”和“Memory:PagesReads/sec”之间的区分。“Memory:PagesInput/sec”表示从磁盘引入的用以解决页错误的Windows4KB页的实际数目。“Memory:PagesReads/sec”表示每秒钟需要多少个磁盘I/O哀求才干解决页错误，它从一个略微不同的角度看待所发生的错误。因此，一个页读取可以包含几个Windows4KB页。当数据包的大小增强（64KB或更大）时，磁盘I/O就运行得更好，因此可能有须要从这两方面来考虑。还需记住的重要一点是对于硬盘，完成一个4KB的读或写所花

的时光可能与完成一个64KB读或写所花的时光相同。考察以下情形；可以想象，200个页读取（每次读取8个4KB页）比300个页读取（每次仅读取一个4KB页）的速度要快。并且请注重我们比较出1,600个4KB页读取比300个4KB页读取速度要快。这里的关键事实适用于全部的磁盘I/O分析：不要仅仅注重DiskBytes/sec（磁盘字节/秒）数，还要注重DiskTransfers/sec（磁盘传输/秒）数，由于两者是相关的。这将在后面的磁盘I/O部分举行深化研究。

将“Memory:PagesInput/sec”和与WindowsNT分页文件相关的全部驱动器中的“LogicalDisk:DiskReads/sec”举行比较，并且将“Memory:PageOutput/sec”和与Windows分页文件相关的全部驱动器中的“LogicalDisk:DiskWrites/sec”举行比较，由于它们提供一种关于磁盘I/O与分页而不是其它应用程序（即SQLServer）的严格相关程度的测量办法。隔离分页文件I/O活动的另一种容易办法是确保分页文件位于与其它全部SQLServer文件不同的驱动器组中。将分页文件与SQLServer文件隔开还可以协助改善磁盘I/O性能，由于它允许与分页相关的磁盘I/O和与SQLServer相关的磁盘I/O并行执行。

SoftPaging-Memory:PagesFaults/sec>0

Memory:PagesFaults/sec>0表示WindowsNT正在分页，但是在计数器中包括强制存储分页和软内存分页。在前面的部分，我们研究

了强制存储分页。软内存分页表示数据库服务器中的某些应用程序所哀求的内存分页在RAM内部但却在Windows工作集外部。Memory:PageFaults/sec有助于得出正在发生的软内存分页的数目。没有称为SoftFaults/sec的计数器。而应通过公式

“Memory:PagesFaults/sec”-“Memory:PagesInput/sec”=SoftPageFault/sec计算每秒钟所发生的软错误的数目。

要确定是否是SQLServer而不是另一过程引发过多分页，请监视SQLServer过程的Process:PageFaults/sec计数器，并注重sqlserver.exe每秒页错误的数目是否与Memory:Pages/sec的数目临近。

对于性能来说，软错误不如硬错误那么糟糕，由于软错误消耗的是CPU资源，而硬错误消耗磁盘I/O资源。性能最好的环境是既没有软错误，也没有硬错误。

请注重在SQLServer实际首次存取它的数据高速缓存页之前，第一次存取每一页都会引起软错误。因此，不必不安SQLServer首次启动且首次执行数据高速缓存时所产生的初始软错误。

有关内存优化的具体信息，请在SQLServerBooksOnline中搜

索字符串“monitoringmemoryusage”。

监视处理器

使全部的服务器处理器保持繁忙以获得最佳性能，但不要繁忙到发生处理器瓶颈的程度。性能优化的难题在于假如CPU不是瓶颈，那么其它部分便是瓶颈（最有可能的就是磁盘子系统），因此铺张了CPU；CPU通常是最难扩充的资源（超过某些特定配置级别，如当前许多系统中是4或8），因此假如CPU利用率超过95%，应视为好的现象。同时，应监视事务的响应时光以确保它们在合理的范围之内；假如不是，>95%的CPU使用率仅仅意味着对于可用的CPU资源来说，工作负荷过高，要么增强CPU，要么削减或调节工作负荷。

查看PerformanceMonitor计数器“Processor:ProcessorTime%”以确保每个CPU上的全部处理器的利用率均低于95%。“System:ProcessorQueue”是WindowsNT系统上的全部CPU的处理器队列。假如每个CPU的“System:ProcessorQueue”大于2，则表明浮现CPU瓶颈。当检测到CPU瓶颈时，有须要在服务器上添加处理器或削减系统中的工作负荷。要削减工作负荷，可以调节查询或者改进索引以削减I/O，从而削减CPU使用率。

当疑惑浮现CPU瓶颈时要查看的另一个PerformanceMonitor计数器可能是“System:ContextSwitches/sec”，由于它表示Windows

NT和SQLServer每秒钟必需从执行一个线程改变为执行另一个线程的次数。这需要消耗CPU资源。环境切换是多线程、多处理器环境的正常组成部分，但是过多的环境切换将使系统停顿。解决的方法是假如有处理器队列，则仅关注环境切换。假如观看处处理器队列，那么请将环境切换级别作为调节SQLServer性能时的一个标准。考虑使用轻量级的池选项以便SQLServer切换到基于光纤的调度模式，而不是默认的基于线程的调度模式。将光纤当作轻量级线程。使用命令sp_configure'lightweightpooling',1启用基于光纤的调度。查看处理器队列和环境切换以监视此效果。

DBCCSQLPERF(THREADS)提供映射回spid的有关I/O、内存和CPU使用状况。执行以下SQL查询以调查当前消耗CPU时光最多的项："select*frommaster.sysprocessesorderbycpudesc."

磁盘I/O计数器

“DiskWriteBytes/sec”和“DiskReadBytes/sec”计数器用每个规律驱动器的每秒字节数表示数据吞吐量。将这些数字与“DiskReads/sec”和“DiskWrites/sec”一起认真考虑。不要由于每秒的字节数较低就以为磁盘I/O子系统不忙！请记住一个硬盘每秒钟可以支持75个非延续和150个延续的磁盘读和磁盘写。

监视与SQLServer文件相关的全部驱动器的“DiskQueue

Length”，并确定哪些文件与过长的磁盘队列相关。

假如PerformanceMonitor显示某些驱动器没有另一些驱动器繁忙，便有机会将SQLServer文件从浮现瓶颈的驱动器中移到不忙的驱动器中。这有助于将磁盘I/O活动更匀称地分布在硬盘中。假如某个大型的驱动器池正在为SQLServer文件使用，那么磁盘队列的解决计划是通过在这个驱动器池中添加更多的物理驱动器来加大池的I/O容量。

磁盘队列可能是某个SCSI通道已被I/O哀求饱和的征兆。PerformanceMonitor不能直接检测是否是这种状况。硬件厂商可能可以提供某些工具来协助检测某个RAID控制器所服务的I/O数以及该控制器是否对I/O哀求举行排队。假如许多磁盘驱动器（10个或更多）连到了此SCSI通道，且它们均以全速执行I/O，那么这种状况更有可能发生。这种状况的解决计划是取出一半磁盘驱动器，然后将它们连到另一个SCSI通道或RAID控制器以平衡这些I/O。通常，在SCSI通道中重新平衡驱动器要求重建RAID阵列并彻低备份/恢复SQLServer数据库文件。

PerformanceMonitor图形输出示例

图8表示可用PerformanceMonitor举行观看的典型计数器。请注重当前所观看的计数器是ProcessorQueueLength。按用亮白色突

出显示当前的计数器。这有助于将当前计数器与其它正在观看的计数器区别开来，当用PerformanceMonitor同时观看许多计数器时，这种办法尤其实用。

请注重ProcessorQueueLength的Max（最大）值是22.000。PerformanceMonitor图形的Max、Min和Average值仅涵盖GraphTime（图形时光）所示图形的当前时光窗口。默认状况下，GraphTime可涵盖100秒。要监视更长时光，并确保获得这些时光段中有代表性的Max、Min和Average值，可使用PerformanceMonitor的记录功能。

ProcessorQueue（处理器队列）图形线条的外形表示Max值22仅持续了一段很短的时光。但是在值22的前面有一段时光ProcessorQueueLength大于5（这可从图上看出，图中100%表示22，在值22的前面有一段时光图形的值超过25%，即大约为5。）在本例中，数据库服务器\\HENRYLNT2惟独一个处理器，不能承受ProcessorQueueLength大于2。因此，PerformanceMonitor指出这台机器上的处理器负荷有时过重，需进一步调查以削减处理器上的负荷，或者在\\HENRYLNT2上添加更多的处理器以处理这些时光段中的较高的处理器工作负荷。

图8PerformanceMonitor图形输出

其它性能主题

削减网络流量和数据库服务器的资源消耗

通过易于使用的接口（如ADO/RDO/DAO数据库API）完成SQL作业的数据库程序员，依旧有责任密切关注所生成的结果集。ADO/RDO/DAO为程序员提供优秀的数据库开发接口，这些接口具有丰盛的SQL行集功能，且不要求程序员具有丰盛的SQL编程阅历。但这同时也意味着需要付出一定的代价。假如因为程序员没有认真考虑其应用程序返回到

客户端的数据量，不注重SQLServer索引放置的位置以及SQLServer数据的罗列办法，就会引起性能问题。SQLProfiler、IndexTuningWizard和ShowPlan对于找到和修复这些有问题的查询非常有协助。

通过消退挑选列表中不需要返回的列或者仅返回所需要的行来减小返回的结果集。这有助于削减I/O和CPU的消耗。

有关具体信息，请在SQLServerBooksOnline中搜寻字符串“OptimizingApplicationPerformanceUsingEfficientDataRetrieval”、“UnderstandingandAvoidingBlocking”和“ApplicationDesign”。

死锁

假如在构造拜访SQLServer的应用程序时，使事务按相同的时光挨次拜访全部用户事务中的表，则可以避开死锁。在应用程序设计过程中，有须要尽早向SQL应用程序开发人员明确阐明按时序拜访表的概念。这有助于避开死锁问题，以免未来需要付出更高的代价解决这个问题。

削减SQL查询I/O并缩短事务时光：虽说这是一种防止死锁的迂回方法，但对全部的查询都应使用。它可能会有一些协助，由于它可以加快查询的速度，从而削减将资源锁定的时光以及全部锁定的竞争（包

括死锁）。使用SQLQueryAnalyzer的SHOWSTATSI/O来确定与大型查询有关的规律页提取的数目。考虑挑选SQLQueryAnalyzer的“Showqueryplan”选项时所使用的索引。考虑索引的放置或者重新设计SQL查询以使它更有效，从而使用更少的I/O。

有关具体信息，请在SQLServerBooksOnline中搜寻字符串“AvoidingDeadlocks”、“TroubleshootingDeadlocking”、“DetectingandEndingDeadlocks”和“AnalogytoNonserializableTransactions”。

只要有任何可能就应避开的SQL

在SQL查询中使用不等号可以迫使数据库使用表扫描来求取不等式的值。假如在超大型表中定期运行这些查询，会产生较高的I/O。

示例：

WHERE!=some_value

WHEREsome_value

其中带有NOT的任何WHERE表达式

假如需要运行这些查询，试着重新构建查询以删除NOT关键字。

示例：

不用：

select*fromtableAwherecol1!="value"

试着使用；

select*fromtableAwherecol1"value"

假如索引创建在col1，这使SQLServer得以使用这种索引（在这种状况下用聚拢索引更好），而不需要求助于表扫描。

灵巧化标准

在极热（存取频繁）的表中，假如有几列是SQL应用程序不常常需要的，则将它们移到另一个表是比较故意义的。删除的列越多，就越有利于削减I/O并提高性能。有关具体信息，请在SQLServerBooksOnline中搜寻字符串“LogicalDatabaseDesign”和“Normalization”。

分区视图

SQLServer7.0可以通过视图对表举行水平分区。当数据库用户希翼维持引用某个表名称的SQL查询，但数据检索的本性总是查询数据的固定分段时，使用分区可以改善I/O性能。例如，假定有一个记录全部销售部门一年销售状况的超大型表，并假定这个表中的全部检索都基于一个销售部门。在这种状况下，可以使用分区视图。可以为每个销售部门定义一个销售表，在每个表的销售部门列中定义一个约束，然

后在全部的表中创建一个视图，以形成分区视图。销售部门列中的约束由Queryoptimizer使用。当查询视图时，与查询中所提供销售部门值不匹配的全部销售部门表都将被Queryoptimizer忽视，而不对这些基表执行I/O。通过削减I/O改善了查询性能。

有关具体信息，请在SQLServerBooksOnline中搜寻字符串“ScenariosforUsingViews”、“CreateView”、“UsingViewswithPartitionedData”、“ModifyingDataThroughaView”、“CopyingToorFromaView”和“Partitioning”。

复制和备份性能

确保磁盘I/O子系统和CPU运行很好，可以改善全部SQLServer操作的性能。其中固然包括复制和备份。事务复制和事务日志备份涉及到读取事务日志文件。快照复制和备份执行数据库文件的延续扫描。SQLServer7.0的新型存储结构已经过改进，使这些操作既迅速又有效（只要数据库服务器的CPU或磁盘子系统中没有发生排队现象）。

有关性能优化复制和备份/恢复的具体信息，请在SQLServerBooksOnline中搜寻字符串“ReplicationPerformance”、“OptimizingBackupandRestorePerformance”、“CreatingandRestoringDifferentialDatabaseBackups”、“CreatingandApplyingTransactionLogBackups”、“UsingMultipleMediaor

Devices”、“MinimizingBackupandRecoveryTimesinMission-CriticalEnvironments”、“Backup/RestoreArchitecture”和“SQLServer7.0onLargeServers”。

特别的磁盘I/O调节计划：EMC对称集成高速缓存磁盘队列

对于在EMCSymmetrixEnterpriseStorageSystems（EMC对称企业存储系统）中执行的SQLServer数据库系统，应记住几种磁盘I/O平衡办法，由于EMC对称存储的独特特性有助于避开磁盘I/O瓶颈问题并获得最佳性能。

对称存储系统包含高达16GB的RAM高速缓存，并在磁盘阵列中包含内部处理器，这有助于加速数据的I/O处理，而无需使用托管服务器的CPU资源。要了解怎样平衡磁盘I/O，请关注Symmetrix（对称）框内的4个主要组件。16GB高速缓存是其中之一。最大可用32个SA通道将32个SCSI卡从WindowsNT托管服务器衔接到Symmetrix，全部这些通道可以同时哀求16GB高速缓存中的数据。而Symmetrix框中最大有32个称为DA控制器的衔接器，它们是内部SCSI控制器，用来将Symmetrix中的全部内部磁盘驱动器连到内部高速缓存中。这样，在Symmetrix中就形成了硬盘。

关于EMC硬盘的备注：它们是SCSI硬盘，与本文中所研究的其它SCSI驱动器具有相同的I/O能力（这里适用75/150规章）。EMC

技术通常使用的一个功能是“超级卷”（hyper-volumes）。超级卷定义为EMC硬盘的规律分区，对于WindowsNT磁盘管理器来说，超级卷就像另一个物理驱动器，因此用WindowsNT磁盘管理器可以像对其它任何磁盘驱动器一样对它们举行操作。可以在每个物理驱动器上定义多个超级卷。当在EMC存储中执行数据库性能优化时，很重要的一点是一定要和EMC域工程师密切合作，以了解超级卷是如何定义的（假如有的话），其缘由在于避开物理驱动器的数据库I/O超载很重要。假如以为两个或多个超级卷是单独的物理驱动器，而实际上它们是同一个物理驱动器上的两个或多个超级卷，那么就极有可能发生超载。

应当在不同的DA控制器中平均分配SQLServerI/O活动。这是由于DA控制器是分配给所定义的硬盘组的。本文前面已研究过，SCSI控制器不行能发生瓶颈。DA控制器不大可能发生I/O瓶颈，但是与DA控制器相关的驱动器组较有可能浮现瓶颈。在DA控制器及其相关磁盘驱动器环境中，SQLServer磁盘I/O平衡的办法与其它任何厂商的