数据数优化1

怎样查出SQLServer的性能瓶颈


如果你曾经做了很长时间的 DBA ，那么你会了解到 SQLServe 的性能调优不是一个精密的科学。即使是，对于为最佳的性能找到最佳的配置也是很困难的。这是因为对于调优来说很少东西是绝对的。例如，一个性能调优可能对某一方面有用，可是却会影响其他的性能。

我 曾经做过 DBA ，在最后 7 年的日子里，我总结了一套 SQLServer 调优的清单。当第一次进行 SQLServer 性能调优的时候，可以用它来作为一个向 导。我经常被邀请去检查 SQLServer 并提供一些性能方面的建议。直到现在，我还没有真正写下一个贯穿整个性能调优过程的方案。但是当我做了越来越多 的性能调优的咨询工作后，我现在决定花点时间整理出来。你将会发现它是很有用的，就象我发现对我的用处一样 .

SQLServer性能监控

这 套性能优化的清单将至少准科学的帮助你找出你的SQLServer任何明显的性能问题。说是这样说，SQLServer的性能调优仍然是很困难的。我试图用这套清单去找出“容易”的sqlserver性能问题，困难的留待稍后。我这样做是因为很容易将容易和困难的的性能调优问题搞混。通过列出一个“容易” 的性能调优范围，就很容易的将这些问题解决，一旦解决了这些容易的问题，那么你就能集中去解决更困难的问题。

使 用这个SQLServer性能调优清单的一个好处是，它将不仅仅告诉你目前最容易解决的性能问题是什么，而且还帮助你正确的去解决。在某种程度上，你可以选择不同的顺序进行。换句话说，你可以故意做出特殊的决定而不是按照清单通常的顺序进行。某种意义上说你是对的，不是所有的性能调优建议都适合所有的情形。另外，你的决定是基于你的资源限制，例如没有足够的钱去买满足负荷的硬件。如果真是那样的话，你就别无选择了。还有，你的决定可能基于一些政治原因，那是你不得不作出的改变。不管怎样，你需要知道你能做什么，使用这个性能调优清单找出你能改变的范围并做出相应的改变提升你的SQLServer的性能。

一般来说，你将在你的每一个SQL服务器上执行这个清单。如果遇到清单中的一些问题，这会花掉你一些时间。我建议你从目前性能问题最多的的服务器开始，然后当你有时间的时候按照自己的思路去解决其他服务器。

一旦你完成了，可仍然有很多事情要去做。记住，这些只是一些容易的。一旦你完成了这些容易的，接下来你需要花时间去解决更困难问题。这个是另一篇文章要解决的问题了。

怎样进行你的SQLServer性能调优呢?

为了使其变得容易，我把它们分成了以下几个部分：

• 使用性能监视器找出硬件瓶颈
• SQLServer硬件性能监控列表
• 操作系统性能监控列表
• SQLServer2000配置性能监控列表
• 数据库配置设置性能监控列表
• 索引性能监控列表
• 应用程序和T-SQL性能监控列表
• SQLServer数据库作业性能监控列表
• 使用Profiler找出低效的查询
• 怎样最好的实现SQLServer性能监控

管理你的SQLServe性能的最好方法是首先回顾上面每一部分的内容，把它们打印出来。然后完成每一部分的内容，写下你收集到的结果。你也可以按照你喜欢的顺序进行。上面的步骤仅仅列出了我执行的顺序，因为那样通常能达到一个比较好的效果。

一旦你完成其中一部分，你可以按照在清单中发现的不同的建议进行你的性能优化工作。然后你将在后面的部分学到更多。

使用性能监视器找出硬件瓶颈


性能监控列表

计数器名称	均值	最小值	最大值
Memory: Pages/sec
Memory: Available Bytes
Physical Disk: % Disk time
Physical Disk: Avg. Disk Queue Length
Processor: % Processor Time
System: Processor Queue Length
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server General: User Connections

在上表输入你的结果.

使用性能监视器找出SQLServer硬件瓶颈

开始SQLServer性能调优的最佳地方就是从性能监视器（系统监视器）开始。通过一个24小时的周期对一些关键的计数器进行监控，你将对你SQLServer服务器的硬件瓶颈了如指掌。

一般来说，使用性能监视器去创建一个一些关键的计数器的24小时周期的监控日志。当你决定创建这个日志的时候，你需要选择一个典型的24小时的周期，例如，选择一个典型的比较忙的日期，而不是周日或节假日。

一旦你将这些捕获的数据形成日志后，在性能监视器的图形界面下会显示计数器的推荐值。你在上表中记下均值、最小值、峰值。做完这些后，用你的结果跟下面的分析比较。通过你的结果和下面的建议值进行比较，你将能快速的找到你的SQLServe正在经历的潜在的硬件瓶颈。

关键性能计数器说明

下面是不同关键性能计数器的一个讨论，它们的建议值和为了帮助解决硬件瓶颈问题的一些选项。注意我已经限制了性能监视器需要监视的一些关键计数器。我这么做是因为在本文我们的目的是为了容易的找到显而易见的性能问题，许多其他的性能监视器计数器你能在本网站其他地方找到。


Memory: Pages/sec

这个计数器记录的是每秒钟内存和磁盘之间交换的页面数。交换更多的页面、超过你服务器承受的更多的I/O，将轮流降低你SQLserver的性能。你的目的就是尽量将页面减少到最小，而不是消除它。

如果你的服务器上SQLServer是最主要的应用程序，那么这个值的理想范围是0～20之间。可能很多时候你看到的值都会超过20。这个值一般要保持在每秒的平均页数在20以下。

如果这个值平均总是超过20，其中最大的一个可能是内存瓶颈问题，需要增加内存。通常来说，更多的内存意味着需要执行的页面更少。
在 大多数情况下，服务器决定SQLServer使用的适当内存的大小，页面将平均小于20。给SQLServer适当的内存意味着服务器的缓存命中率 （Buffer Hit Cache Ratio 这个稍后会讲到）达到99％或者更高。如果在一个24小时的周期里你的sqlserver的缓存命中率达到99％或者更高，但是在这个期间你的页面数总是 超过20，这意味着你或许运行了其他的程序。如果是这样的情况，建议你移除这些程序，使SQLServer是你的服务器的最主要的程序。

如 果你的sqlserver服务器没有运行其他程序，并且在一个24小时的周期里页面数总是超过20，这说明你应该修改你对SQLServer的内存设置 了。将其设置为“动态配置SQLServer的内存”，并且最大内存设置得高一些。为了达到最优，SQLServer将尽可能的获得多的内存以完成自己的 工作，而不是去和其他的程序争夺内存。

Memory: Available Bytes

另 一个检查SQLServer是否有足够的物理内存的方法是检查Memory Object: Available Bytes计数器。 这个值至少大于 5M ，否则需要添加更多的物理内存。在一个专门的SQLServer服务器上，SQLServer试图维持4 -10M 的自由物理内存，其余 的物理内存被操作系统和SQLServer使用。当可用的物理内存接近 5M 或者更低时，SQLServer最可能因为缺少内存而遇到性能瓶颈。遇此情况， 你需要增加物理内存以减少服务器的负荷，或者给SQLServer配置一个合适的内存。

Physical Disk: % Disk Time

这 个计数器度量磁盘阵列繁忙程度（不是逻辑分区或磁盘阵列上独立的磁盘）。它提供一个对磁盘阵列繁忙程度相对较好的度量。原则上计数器% Disk Time的值应该小于55%。如果持续超过55%（在你24小时的监控周期里大约超过10分钟），说明你的SQLServer有I/O瓶颈。如果你只是偶 尔看到，也不必太担心。但是，如果经常发生的话（也就是说，一个小时出现好几次），就应该着手寻找增加服务器I/O性能或者减少服务器负荷的解决之道了。 一般是为磁盘阵列增加磁盘，或者更好更快的磁盘，或者给控制器卡增加缓存，或者使用不同版本的RAID，或者更换更快的控制器。

在NT4.0上使用该计数器之前，确认在NT命令提示符下输入diskperf -y，重启服务器，以便手动打开。在NT4.0下第一次必须将该计数器打开，Windows2000默认是打开的。

Physical Disk: Avg. Disk Queue Length

除 了观察物理磁盘的% Disk Time计数器外，还可以用Avg. Disk Queue Length计数器。磁盘阵列中的各个磁盘的该值如果超过2（在你24小时的监控周期里大约超过10分钟），那么你的磁盘阵列存在I/O瓶颈问题。象计数 器% Disk Time一样，如果只是偶尔看到，也不必太担心。但是，如果经常发生的话，就应该着手寻找增加服务器I/O性能的解决之道了。如前所述。

你需要计算这个值，因为性能监视器不知道你的磁盘阵列中有多少物理磁盘。例如，如果你有一个6个物理磁盘组成的磁盘阵列，它的Avg.
Disk Queue Length值为10，那么实际每个磁盘的值为1.66（10/6＝1.66），它们都在建议值2以内。

在NT4.0上使用该计数器之前，确认在NT命令提示符下输入diskperf -y，重启服务器，以便手动打开。在NT4.0下第一次必须将该计数器打开，Windows2000默认是打开的。

一起使用这两个计数器将帮助你找出I/O瓶颈。例如，如果% Disk Time的值超过55%，Avg. Disk Queue Length计数器值超过2，服务器则存在I/O瓶颈。

Processor: % Processor Time

处 理器对象： % Processor Time计数器对每一个CPU可用，并针对每一个CPU进行检测。同样对于所有的CPU也可用。这是一个观察CPU利用率的关键计数器。如果% Total Processor Time计数器的值持续超过80%（在你24小时的监控周期里大约超过10分钟），说明CPU存在瓶颈问题。如果只是偶尔发生，并且你认为对你的服务器影 响不大，那没问题。如果经常发生，你应该减少服务器的负载，更换更高频率的CPU，或者增加CPU的数量或者增加CPU的2级缓存（L2 cache）。

System: Processor Queue Length

根 据% Processor Time计数器，你可以监控Processor Queue Length计数器。每个CPU的该值如果持续超过2（在你24小时的监控周期里大约超过10分钟），那么你的CPU存在瓶颈问题。例如，如果你的服务器 有4个CPU，Processor Queue Length计数器的值总共不应超过8。

如 果Processor Queue Length计数器的值有规律的超过建议的最大值，但是CPU利用率相对不是很高，那么考虑减少SQLServer的"max worker threads"的配置值。Processor Queue Length计数器的值高的可能原因是有太多的工作线程等待处理。通过减少"maximum worker threads"的值，强迫线程池踢掉某些线程，从而使线程池得到最大的利用。

一起使用计数器Processor Queue Length和计数器% Total Process Time，你可以找到CPU瓶颈，如果都显示超过它们的建议值，可以确信存在CPU瓶颈问题。

SQL Server Buffer: Buffer Cache Hit Ratio

SQL Server Buffer中的计数器Buffer Cache Hit Ratio用来指出SQLServer从缓存中而不是磁盘中获得数据的频率。在一个OLTP程序中，该比率应该超过90%，理想值是超过99%。如果你的 buffer cache hit ratio低于90%，你需要立即增加内存。如果该比率在90%和99%之间，你应该认真考虑购买更多的内存了。如果接近99%，你的SQLServer 性能是比较快的了。某些情况下，如果你的数据库非常大，你不可能达到99%，即使你在服务器上配置了最大的内存。你所能做的就是尽可能的添加内存。

在OLAP程序中，由于其本身的工作原理，该比率大大减少。不管怎样，更多的内存总是能提高SQLServer的性能。

SQL Server General: User Connections

既然sqlserver的使用人数会影响它的性能，你就需要专注于sqlserver的General Statistics Object: User Connections计数器。它显示sqlserver目前连接的数量，而不是用户数。
如 果该计数器超过255，那么你需要将sqlserver的"Maximum Worker Threads" 的配置值设置得比缺省值255高。如果连接的数量超过可用的线程数，那么sqlserver将共享线程，这样会影响性能。"Maximum Worker Threads"需要设置得比你服务器曾经达到的最大连接数更高。

 

SQLServer硬件性能监控列表


性能监控列表

SQLServer硬件特征	相应的描述
Number of CPUs
CPU MHz
CPU L2 Cache Size
Physical RAM Amount
Total Amount of Available Drive Space on Server
Total Number of Physical Drives in Each Array
RAID Level of Array Used for SQL Server Databases
Hardware vs. Software RAID
Disk Fragmentation Level
Location of Operating System
Location of SQL Server Executables
Location of Swap File
Location of tempdb Database
Location of System Databases
Location of User Databases
Location of Log Files
Number of Disk Controllers in Server
Type of Disk Controllers in Server
Size of Cache in Disk Controllers in Server
Is Write Back Cache in Disk Controller On or Off?
Speed of Disk Drives
How Many Network Cards Are in Server?
What is the Speed of the Network Cards in Server?
Are the Network Cards Hard-Coded for Speed/Duplex?
Are the Network Cards Attached to a Switch?
Are All the Hardware Drivers Up-to-Date?
Is this Physical Server Dedicated to SQL Server?

在上表里输入你的值.
 
监控硬件是早期的重要步骤

从以前的章节里（使用性能监视器），你可以找出一些潜在的硬件性能瓶颈。这一节里，我们将查看SQLServer硬件的每一个主要组件，以帮助最优化你硬件的性能。 将分以下几个部分进行：

• CPU
• Memory
• Disk Storage
• Network Connectivity
• Misc.

作为监控的一部分，你需要完成上面的列表，这样，你就会对你的服务器无所不知了。 

CPU

CPU的数量

这第一个是显而易见的，越多的CPU性能越快。SQLServer2000的标准版支持4个CPU。企业版支持最多32个CPU，具体根据操作系统而定。更多的CPU对于全面提升SQLServer的性能是很有效的。

对 任何一个基于SQLServer的应用程序需要的CPU数量进行估算是很困难的。这是因为每个应用程序的工作都是不同的，并且它们的使用也不同。有经验的 DBA总是对应用程序需要什么样的CPU有个大概的了解，却很难真正知道需要什么样的CPU，直到在真实条件下测试了服务器的配置。
由于选择合适的CPU的数量是困难的，所以你可以考虑下面的原则：

• 尽可能的购买更多CPU数量的服务器。
• 如果你做不到，那么至少要购买一个能扩展CPU数量的服务器。几乎所以的SQLServer在工作量增加时都需要更多的动力。

这是一些潜在的假设：

• SQLServer将仅仅用来运行一个同时不超过5个用户的财务应用程序，并且你预期未来两年不会改变。如果是这样，单CPU的服务器就足够用了。如果预期用户数量在不久会增加的话，那么你需要考虑购买一个单CPU的，并且拥有可扩展一个CPU数量的服务器以备不时之需。
• SQLServer 用来运行一个内部的写程序，这个程序不仅仅包括OLTP，而且需要支持繁重的报表需求。预期用户同时不会超过25个。如果是这样，你需要考虑一个双CPU 的服务器，但是它应该可以扩展到4个CPU。“繁重的报表需求”的真正含义是很难预计的。我曾经看到一些相当简单，但是不好的写报表，占用了服务器全部的 CPU。
• SQLServer运行一个目前用户为100到150之间的ERP包。对于象这样的“重型”程序，询问推荐的硬件配置。因为他们已经对他们的产品需要的CPU配置有了一个很好的建议。

我 能提供一些其他的例子，但是通过这些我发现：正确预计基于SQLServer的一个特殊的应用程序的CPU的数量是很困难的。你通常应该购买一个比你认为 要大的系统，因为在许多情况下，一个应用程序的使用需求经常是被低估了的。现在购买一个有多个CPU的大服务器来长期使用也不是很昂贵了，总比你在6到 12个月后由于当初的低估不得不重新替换你整个服务器要划算得多。 

CPU速度

象CPU的数量一样，需要的CPU的速度 也是很难估计的。一般说来，尽量购买最快的CPU。购买速度快的总是好于速度慢的。 

CPU 2级缓存

我曾经遇到一个比较普遍的问题：购买2级缓存较小的便宜的CPU好呢，还是购买2级缓存较大的昂贵的至强CPU好？事实上，在购买2级缓存较小的更快的芯片和购买较大2级缓存的芯片上做出决定是很困难的。这里有一些规则：

• 如果你仅有1、2个CPU，那么尽量买最快的，其次才考虑2级缓存。如果你一定要选择2级缓存大小的话，尽量选择较大的。
• 但是，如果你有4个或更多的CPU，那么你需要较大2级缓存的CPU，即使它们的速度不太高。这是因为对于一个有4个或更多CPU的服务器来说，要想尽量让SQLServer运行良好的话，2级缓存一定要大，否则将浪费额外的CPU。

CPU监控列表

既然本文是关于你SQLServer目前CPU性能的一个监控，那么你现在应该关注你目前的服务器是否存在CPU瓶颈。正如在《使用性能监视器找出硬件瓶颈》一文所讨论的那样，你可以使用性能监视器帮助你找到硬件瓶颈。

如果你CPU目前没有瓶颈问题，那么你可以忽略下一部分关于memory的讨论。但如果你的服务器目前存在CPU瓶颈，并且是主要的性能问题，那么你可以选择以下的方法去解决瓶颈：

• 减少服务器的负荷。可以通过减少用户数量、调优查询、调优索引、除去在服务器上运行的不必要的程序来达到目的。另外如果你的产品服务器上还运行有关于报表的程序，将其移到一个专门为报表做的服务器上。
• 如果CPU瓶颈是由于缺少服务器内存引起的，请添加更多的内存。这是一个普遍的问题。
• 如果你目前的服务器有更多的CPU插槽，那么请添加更多的CPU。
• 如果可以的话，用更快的CPU升级你的服务器。
• 购买一个新的有更多更快CPU的服务器。

不幸的是，这些方法在处理CPU瓶颈时也不是轻而易举的，当然除非你们公司有足够的钱。作为一个DBA来说，你可能唯一能做的就是“减少服务器的负荷”这一项了。 

内存

在讨论完CPU后，现在开始讨论内存，不要认为它不象CPU那么重要。事实上，内存可能是任何SQLServer服务器最重要的硬件部分，它比其他硬件更能影响SQLServer的性能。
当我们讨论内存的时候，一般指的是物理内存，而不是虚拟内存。SQLServer不是设计来用虚拟内存的，尽管它也能用。 并非联合使用操作系统的物理内存和虚拟内存，SQLServer总是尽可能的使用物理内存。这主要是为了提高速度。访问内存中的数据总是比访问磁盘上的快得多。

SQLServer不能总是把数据放在内存（SQLServer缓存）中，它也访问磁盘，就像操作系统管理虚拟内存一样。但SQLServer的“缓存”机制比操作系统的虚拟内存更快更诡异。

快 速的知道SQLServer是否有足够内存的方法是检查SQLServer的缓存命中率（在《使用performance Monitor找出硬件瓶颈》一文有过讨论）。如果这个计数器为99%或者更高，说明有足够的内存。如果这个计数器在90%与99%之间并且你对性能比较 乐观的话，那么你的SQLServer可能有足够的内存，但是如果你不满意服务器性能的话，则需要添加内存了。
如果这个计数器少于90%，关键在于性能无法被接受（如果运行的是OLAP，少于90%通常也没问题），所以需要添加更多的内存。 SQLServer的物理内存的理想值应该超过服务器上最大数据库的大小。这总是不可能的，因为许多数据库是非常大的。如果你正在计算
SQLServer 的大小，并且有足够的预算，那么尽量去购买能容纳整个数据库大小的物理内存。假定你的数据库是 4G 或者更小，那么这通常不会成太大的问题。但是如果你的数 据库更大（或者预期会超过 4G ），那么你可能容易地提供超过 4G 的内存。SQLServer2000企业版支持高达 64G 的内存，没有太多的服务器支持这 么大的内存。

即 使SQLServer的缓存不能容纳整个数据库，SQLServer仍然能快速的获取数据。99%的缓存命中率意味着SQLServer需要的数据99% 的时间都是在缓存中的，性能非常快。例如，我管理一个 30G 的数据库，但是服务器仅有 4G 的内存，而缓存命中率总是高于99.6%。这意味着大多数情况下 用户没有同时访问数据库里所有的数据，仅仅一小部分而已，SQLServer也能将经常访问的数据始终放在缓存中，所以99%的请求在这种情况下能迅速完 成，即使服务器的内存少于数据库的大小。

那么，要点是什么呢？如果你的缓存命中率少于90%，那么认真的考虑添加更多的内存了。
 
磁盘存储器

在内存之后，磁盘存储器也是经常影响SQLServer性能的的最重要的因素。 它也是一个复杂的话题。在这部分，我将专注于磁盘存储器影响性能最容易的地方。 服务器上可用磁盘空间的总量 所有的磁盘阵列至少要20%的可用空间，这样对性能影响才不是很大。这是因为NTFS（假定你使用的是该磁盘格式）需要额外的空间才能工作得更好。如果没有可用空间，那么NTFS不能运行并且性能会降低。它也会导致更多的磁盘碎片，因为服务器读写数据更加可能。
查看你SQLServer的每一块物理磁盘，检查一下是否有至少20%或者更多的可用空间。如果没有，考虑以下方法：

• 删除磁盘上任何不需要的数据（清空回收站、临时文件、setup文件等等）
• 删除一些数据以留出更多的空间
• 添加更多的磁盘空间

每一个磁盘阵列的物理磁盘数量 一个磁盘阵列通常由2个或者更多的物理磁盘作为一个单一的单元一起工作。例如RAID5阵列也许有4个物理磁盘。那么为什么了解你SQLServer的一个或多个磁盘阵列有多少个物理磁盘是很重要的呢？
除镜像磁盘（两个物理磁盘一起工作）外，磁盘阵列有越多的物理磁盘，对于磁盘阵列的读写就越快。 例如，假如想买一个新的做RAID5的至少有 100M 可用空间的SQLServer服务器，并要求提供以下两种不同的磁盘阵列配置：

• 4个 36G 的磁盘（可用空间为 108G ）
• 7个 18G 的磁盘（可用空间为 108G ）

按照要求这两者都符合标准。但是哪一种磁盘阵列能提供更快的读写性能呢？答案是第二种，即7个 18G 的磁盘。为什么呢？
一 般说来，磁盘阵列中磁盘越多，可用来读写的磁盘头就越多。例如，SCSI磁盘可以同时读和写数据。所以一个磁盘阵列有越多的物理磁盘，该磁盘阵列的读写速 度就越快。阵列中的每个磁盘分担一部分工作量，磁盘越多越好。这儿有一个限制，依赖于磁盘控制器，但通常说来，越多越好。 那么这对你来说意味着什么呢？在你查看了你的服务器有多少磁盘阵列、每个磁盘阵列有多少磁盘后，重新配置目前的磁盘阵列以更好的利用
是不是可行呢？
例如，假定你目前的服务器有2个磁盘阵列用来存储用户数据库。每一个是3个 18G 的磁盘组成的RAID5阵列。这种情况下，将两个阵列重新配置成一个由6个 18G 的磁盘组成的阵列会更好。这不仅仅提供了更快的I/O，而且也能获得 18G 的的磁盘空间。
仔细检查你目前的配置，你可以改变很多，也许不可以。但是如果你可以改变的话，你将在你改变之后立即从中得到好处。  SQLServer数据库通常使用的磁盘阵列的RAID级 或许你已经知道，磁盘阵列有不同类型的配置，称作RAID级别。每一级别都有各自的拥护者和反对者。下面是一些经常使用的RAID级别的简单总结，了解后你就知道在你的SQLServer怎样更好的使用它们：
RAID 1

• 操作系统（包括虚拟内存）和SQLServer最理想的是运行在RAID1磁盘阵列上。也有人将虚拟内存运行在一个独立的RAID1磁盘阵列上，但是我对这样做是否能提供虚拟内存性能表示怀疑，在一个好的配置的服务器上，那不是问题。
• 如果你的SQLServer数据库非常小，所有的数据都能在一个磁盘下存储，那么请为你的数据库文件存储考虑RAID1级别。
• 理想地，每一个独立的事务日志应该运行在一个独立的RAID1磁盘阵列上。这是因为事务日志在不断的读写，通过放在独立的磁盘阵列上，由于连续的磁盘I/O不和更慢的随机的磁盘I/O混合使用，从而使性能得到提升。

RAID 5

• 尽 管这是比较流行的RAID级别，对于最优化SQLServer的I/O性能还不是最好的选择。如果数据库的写操作比例超过10%，大多数OLAP数据库都 是这样，写性能会降低，从而伤害整个SQLServer的I/O性能。RAID5最好用于只读或者大部分时候是读的数据库。在微软的测试发现RAID5比 RAID10几乎要慢50%。

RAID 10

• RAID10为SQLServer数据库提供了最好的性能，尽管它是最贵的。数据库的写操作越多，使用RAID10更重要。
• RAID10阵列对于事务日志也是不错的选择，假定它只用来存储单个事务日志。

更可能的是，你目前的SQLServer配置不符合上面的建议。某些情况下，你需要更改你目前的配置以尽量符合上面的建议，但是大多数情况下，你可能不得不忍受直到有新的预算去买新的服务器和磁盘阵列。
如果你只能选择上面的一个 建议的话，我建议你使用RAID10。这将最大化你SQLServer的I/O性能。 

硬件RAID vs. 软件RAID

可以通过硬件或者软件（通过操作系统）实现RAID。不要使用软件RAID，会很慢，总是使用硬件RAID，这是不争的事实。

磁盘碎片

如果你在一个崭新的磁盘阵列上创建了一个新的数据库，数据库文件和事务日志文件会是一个连续的文件。但如果数据库文件或事务日志文件
在创建时指定的最大容量里增长（通常都会超过该容量），随着时间的推移文件可能会产生碎片。文件碎片（磁盘阵列上分散的许多块文件）
引起你的磁盘阵列在读写数据时变慢，从而影响磁盘I/O的性能。
作 为性能监控的一部分，你需要了解你的SQLServer数据库和事务日志是怎样产生碎片的。如果你使用的是Windows2000或者2003，你可以使 用内建的碎片整理工具去分析文件变成碎片的严重程度。如果你运行的是NT4.0，那么你可以借助第三方工具如DisKeeper来进行分析。 如 果分析结果需要进行碎片整理，则进行。不幸的是，整理SQLServer数据库和事务日志的碎片不总是一件容易的事。运行着的文件，象在 SQLServer上运行的数据库和事务日志文件，不总是能进行碎片整理。例如，内建的碎片整理工具不能整理SQLServer的MDF和LDF文件，但 是DisKeeper8.0在大多数情况下可以，而不是全部情况都可以。这意味着在某些情况下，为了整理SQLServer的MDF和LDF文件的碎片， 你不得不使SQLServer离线。依赖文件整理的方式、文件的大小、这可能需要花费很多小时。
你真有必要对数据库文件进行碎片整理吗？如果你的I/O性能目前比较适中，那么你不需要进行碎片整理。但是如果你的I/O性能是个瓶颈的话 ，碎片整理是一个提升性能的便捷之道，尽管大多数情况下会花费一些时间。
理想地，你应该周期性的整理你的SQLServer数据库和事务日志碎片。这样，你能确信没有I/O性能问题。 

操作系统

为了最佳性能，操作系统文件和SQLServer数据库文件（MDF、LDF文件）不要放在一个磁盘阵列上。另外，操作系统文件应该放在一个支持 RAID1、5或10的磁盘阵列上。
和大多数人一样，通常我也是在服务器的C盘上安装操作系统。并且为了容错和最好的性能将C盘配置为RAID1的镜像磁盘。 在大多数情况下， 只要你不把操作系统和SQLServer数据文件放在同一个磁盘阵列上，你在服务器上处理操作系统文件就会获得很大的性能。

SQLServer程序

象 操作系统文件一样，SQLServer程序也不是很挑剔，只要不和SQLServer数据文件放在同一个磁盘阵列上就行。和操作系统文件一起，我通常将 SQLServer程序放在被配置为RAID1镜像的C盘。 如果你在配置SQLServer7.0的群集，那么SQLServer程序不能安装在C盘，必须安装在共享磁盘阵列上。不幸的是这经常和 SQLServer的数据文件是同一个磁盘阵列，除非你有足够的钱仅仅为提升SQLServer程序性能而购买一个独立的独立磁盘阵列。当性能被与数据库文件在同一磁盘阵列上的SQLServer程序轻微影响时，获得容错能力也是一个不太坏的折中方案。另一方面，升级到SQLServer2000群集是一 个不错的选择。如果你在配置SQLServer2000群集，那么SQLServer程序必须放在本地磁盘上，而不是共享磁盘阵列上，所以性能不成问题。

虚拟内存

如 果你有一台SQLServer的专用服务器，并且SQLServer的内存设置为动态（缺省），那么虚拟内存将很少用到。这是因为SQLServer通常 不会太多的使用它。因此，虚拟内存放在任何一个特定的位置不是关键，除了不要放在SQLServer数据文件的同一磁盘阵列上。 通常，我把虚拟内存放在操作系统和SQLServer程序的同一磁盘阵列上，正如我前面所述，它是一个支持RAID1、RAID5、RAID10的磁盘阵列，通常是C盘，这使管理员更容易管理。 如果不是SQLServer专用服务器，除了SQLServer外还运行了其他程序，由于其他程序的原因，虚拟内存可能会有问题，为了获得更好的性能，你 需要考虑将虚拟内存配置到一个专用的列上。然而，更好的方法是使用一台SQLServer的专用服务器。

tempdb数据库

如 果tempdb数据库的使用比较繁重，为了提高磁盘I/O性能，考虑将它移到一个RAID1或者RAID10的独立磁盘阵列上。不要使用RAID5，因为 对于写操作是慢的，如使用，会对tempdb产生副作用。如果不能提供独立的磁盘阵列，你有不想将它与数据库文件放在同一个磁盘阵列上，可以考虑放在操作系统的那个磁盘上，这将帮助减少I/O的争夺以提高性能。 如果应用程序非 常多的使用tempdb数据库，从而引起文件增长超过它的缺省大小，那么你需要将tempdb的缺省大小增加到最近你的应用程序实际使用的tempdb的 大小。这是因为每次SQLServer服务重新启动后，tempdb文件都会按照缺省值重建。当tempdb增长时会花费一些性能资源。通过在 SQLServer重新启动时给tempdb分配一个合适的大小，你不必担心在使用时超过这个大小了。 另外，在tempdb数据库里繁重的操作会降低应用程序的性能。尤其是在创建一个或多个大的临时表去查询或者做联接时。为了加速这些查询，确信 tempdb数据库的AUTOSTATS（自动更新统计信息）选项已打开，并且在这些临时表上创建一个或多个索引。大多数情况下，你将发现这能充分加速你的应用程序。但象许多性能建议一样，测试看看是否有实际的帮助。 

系统数据库

系 统数据库（master、msdb、model）没有大量的读写操作，所以把它们和你的SQLServer数据文件放在同一磁盘阵列上通常也没有性能问 题。仅仅一种情况除外，就是有成百上千用户的大数据库。这种情况下，把系统数据库放在一个独立的磁盘阵列上以稍微提高I/O性能。 

用户数据库 

为了最佳性能，用户数据库文件放在它们自己的磁盘阵列上（RAID1、5或10），和所以的其他数据库文件，包括日志文件分开。如果再同一个SQLServer上有多个大数据库的话，考虑为每一个数据库文件分配一个独立的磁盘阵列以减少I/O争夺。 

日志文件

理 想地，每一个日志文件都应该有它自己独立的磁盘阵列（RAID1或10，注意RAID5会降低事务日志写操作的性能，低于你的预期）。原因是大多数时候，事务日志在连续的写操作，如果磁盘阵列能连续的写数据的话（不必中断去进行其他的读写操作），那么连续写会很快。但是如果你的磁盘阵列不能连续的写的话， 由于它不得不随机的执行其他读写操作，连续写就得不到执行，性能就降低了。当然，为每一个日志文件提供一个独立的磁盘阵列是很昂贵的。那么至少将所有的日志文件放在一个磁盘阵列上（RAID1或RAID10），而不要与数据库文 件放在一个磁盘阵列上。连续的写性能尽管没有为每个日志文件提供一个独立的磁盘阵列那样好，它仍然比试图与数据库文件一起竞争磁盘I/O的性能好的多。 

服务器上磁盘控制器的数量

单 个的磁盘控制器，不论它是SCSI还是fibre，都有一个最大的吞吐量的限制。因此，你需要让磁盘控制器的数量与你期望的数据吞吐量相匹配。每个控制器都是不同的，我无法推荐一个明确的解决方案，但最少应该有2个磁盘控制器。一个用于非硬盘设备如CD-ROM、备份设备等等。另一个用于硬盘。目的是不要 将快的和慢的设备放在同一个控制器上。 经常使用的一个较好的方案是：一个控制器为非硬盘设备，一个为RAID1的本地硬盘，第三个（有时更多）用于存放数据库文件和日志文件的磁盘阵列。确保不 要为控制器捆绑超过它能处理的更多的磁盘，那样当它工作的时候，会降低性能。 

服务器上磁盘控制器的类型

总 是尽可能的购买最快的磁盘控制器，如果你想要最好的SQLServer性能的话。也许你知道，不同的磁盘控制器有不同的性能特征。例如，对于SCSI类型 来说，就有Wide SCSI, Narrow SCSI, Ultra SCSI等不同的类型。光纤连接在更小的层次上，也和上述一样，不同的磁盘控制器有不同的性能特点。 由于控制器的种类很多，我不能做任何明确的建议。通常硬件厂商会提供不同的模型供选择。逐一咨询各自的利弊，选择最适合你的那一款。 

服务器上磁盘控制器的缓存大小

当你购买磁盘控制器的时候，也要考虑它缓存的大小。一些磁盘控制器允许添加额外的磁盘缓存。通常你要购买的磁盘缓存应和控制器能容纳 的缓存一样多。SQLServer对I/O是非常强烈的，所以去做任何可以提高I/O性能的事，象购买一个大的磁盘缓存，将帮助很大的改善性能。
 
磁盘控制器上的写回缓存是开还是关?

磁 盘控制器上的磁盘缓存提供两个方法去加速访问。一个是为了读，一个是为了写。这其中最重要的是读，这是大多数SQLServer数据库花费磁盘I/O时间的地方。另一方面，一个写回缓存是用来加速写操作的，而写相对于读来说通常不是很多。不幸的是，大多数情况下，SQLServer采取写回缓存不打开，因 此，写回缓存在大多数磁盘控制器上是被关掉的。如果你不那样，在一定环境下，在SQLServer写数据后（一旦它写完数据，它就会认为是正确地写的），可能会取得一些脏数据，但是由于某些原因（例如电力不够），写回缓存不会把数据写到磁盘上。 一些控制器提供了备份电池以防止这样的问题，但它们不总是能如预期的那样工作。个人认为，宁愿要正确的数据虽然写慢一点，也不要错误 的数据，尽管那样写更快。 换句话说，我建议你关掉磁盘控制器上的写回缓存，虽然那样会对写性能有一些非常小的影响。 

磁盘转速

磁盘阵列里的磁盘有不同的转速。 正如你所想，为了最佳的性能，总是购买最快的磁盘。通常是15000转或更快。另外，不要将不同转速的磁盘放在同一个磁盘阵列里，那样会影响性能。 

服务器上的网卡数量是多少?

幸运的是， 网络流量通常不会称为SQLServer的瓶颈。单个网卡总是足够用。但是如果你发现网络流量成问题了（你已经有成百上千个用户），那么添加多个网卡总是正确的，这能提高性能。另外，两个或者更多的网卡能增加冗余，减少宕机时间。

网卡速度是多少?

至 少应使用100M的网卡，10M的不能满足你需要的带宽。如果一个或者更多的100M的网卡不能满足，考虑用G级的网卡。事实上，你可能需要完全地跳过 100M的网卡而仅仅用G级的网卡代替。使用更快的网卡不会增加网络流量，它仅仅允许更多的流量通过，轮流的允许你的服务器在适宜的性能下运行。 

网卡硬编码是Speed/Duplex的吗?

如 果你的SQLServer有两个10/100或者10/100/1000的网卡，假定是自动识别网卡速度并设置为适合的，别相信那个能正常的工作。网卡通常不能正确的自识别，总是设置一个小于最佳速度的值或者duplex设置，这样会影响网络性能。你需要做的是手工设置卡的速度和duplex设置，以便你 能确认它已经正确的设置了。 

网卡是连在交换机上的吗?

在一个大的数据中心这是显而易见的，但是对于小的机构来说，使用一个Hub来连接服务器。要是那样，请认真考虑用适当的交换机替换掉Hub，用可能最高的性能去配置交换机，例如100M并且全双工通信。将Hub替换为交换机后在网络性能上会有一个戏剧性的不同。 

所有硬件的驱动都是最新的吗?

诚 然，这是一个烦人的话题，但它比你认为的更重要。最大的性能消耗之一是有Bug的驱动（会引起一些奇怪的不常见的问题），无论它们是在磁盘控制器中还是网卡中，或者别的地方。通过使用最新的驱动，你有可能得到更好更快的性能的驱动，从而提高SQLServer的性能。你应该定期的检查你的硬件是否有新的驱动可用，当你有时间的时候去安装它们。我本人曾经将一个老的有很多bug的驱动更新后是性能得到了彻底的根本提升。  

SQLServer服务器是专用的吗?

前 面我间接提到过，SQLServer应该运行在一个专用的服务器上，而不是和其他应用程序、软件共享一个服务器。当你将SQLServer和其他软件共享 时，你迫使SQLServer去争取物理资源，这样调优SQLServer性能就更加困难。有很多次我在查找SQLServer性能低下的原因时都发现是 另一个和SQLServer运行在同一台服务器上的应用程序的缘故。

 

SQLServer配置项监控列表


性能监控列表

SQL Server配置设置	是否高级设置?	是否需要重启?	缺省值	当前值
affinity mask	Yes	Yes	0
awe enabled	Yes	Yes	0
cost threshold for parallelism	Yes	No	5
cursor threshold	Yes	No	-1
fill factor (%)	Yes	Yes	0
index create memory (KB)	Yes	No	0
lightweight pooling	Yes	Yes	0
locks	Yes	Yes	0
max degree of parallelism	Yes	No	0
max server memory (MB)	Yes	No	2147483647
max text repl size (B)	No	No	65536
max worker threads	Yes	Yes	255
min memory per query (KB)	Yes	No	1024
min server memory (MB)	Yes	No	0
nested triggers	No	No	1
network packet size (B)	Yes	No	4096
open objects	Yes	Yes	0
priority boost	Yes	Yes	0
query governor cost limit	Yes	No	0
query wait (s)	Yes	No	-1
recovery interval (m)	Yes	No	0
scan for startup procs	Yes	No	0
set working set size	Yes	Yes	0
user connections	Yes	Yes	0

在上表里输入你的结果. 

大多数SQLServer配置设置不必更改

这一节，我们将讨论与性能相关的SQLServer配置设置。可以使用企业管理器或者系统过程SP_CONFIGURE对这些配置进行设置。

正如标题所说，大多数情况下，你不应该修改SQLServer的这些缺省配置。这是因为大部分缺省值能为大多数SQLServer提供最优的性能。糟糕的是，如果你不知道改变这些值是什么意思的话，反而可能会影响SQLServer的性能。

如 果你是第一次处理SQLServer，首先应该了解各个配置的含义。然后一个一个的更改，跟缺省值比较看有什么变化。一旦你确定改变一个配置的值了，接下 来你就应该知道为什么要改变它。如果你找不到原因，或者找到了但原因不可信，那么你需要修改回缺省值。接下来象前面那样去配置每一个值，以使其达到最合 适。

本文着重于SQLServer2000，不过大多数建议也适合SQLServer7.0。在SQLServer7.0下试图采用这些建议前，你需要从SQLServer7.0的帮助文档中确认。

SQLServer2000中共有36个不同的配置 ，这里仅仅着重于23个与性能有关的关键配置。 

现在开始

开始查看SQLServer的配置的最简单的方法是对你的每个服务器，在查询分析器里运行命令SP_CONFIGURE。

你会看到类似下面的一个表：

name                                minimum    maximum    config_value run_value
----------------------------------- ----------- ----------- ------------ ----------
affinity mask                      -2147483648 2147483647  0            0
allow updates                      0          1          0            0
awe enabled                        0          1          0            0
c2 audit mode                      0          1          0            0
cost threshold for parallelism      0          32767      5            5
cursor threshold                    -1          2147483647  -1          -1
default full-text language          0          2147483647  1033        1033
default language                    0          9999        0            0
fill factor (%)                    0          100        0            0
index create memory (KB)            704        2147483647  0            0
lightweight pooling                0          1          0            0
locks                              5000        2147483647  0            0
max degree of parallelism          0          32          1            1
max server memory (MB)              4          2147483647  2147483647  2147483647
max text repl size (B)              0          2147483647  65536        65536
max worker threads                  32          32767      255          255
media retention                    0          365        0            0
min memory per query (KB)          512        2147483647  1024        1024
min server memory (MB)              0          2147483647  0            0
nested triggers                    0          1          1            1
network packet size (B)            512        65536      4096        4096
open objects                        0          2147483647  0            0
priority boost                      0          1          0            0
query governor cost limit          0          2147483647  0            0
query wait (s)                      -1          2147483647  -1          -1
recovery interval (min)            0          32767      0            0
remote access                      0          1          1            1
remote login timeout (s)            0          2147483647  5            5
remote proc trans                  0          1          0            0
remote query timeout (s)            0          2147483647  600          600
scan for startup procs              0          1          0            0
set working set size                0          1          0            0
show advanced options              0          1          1            1
two digit year cutoff              1753        9999        2049        2049
user connections                    0          32767      0            0
user options                        0          32767      0            0

第一列“Name”是SQLServer配置设置的名称，第二列“minimum”可用的最小配置，第三列“maximum”是可用的最大配置，第四列“config_value”是该项的设置值（但可能是也可能不是SQLServer目前的实际运行值，有些设置需要重启SQLServer才有效，有些需要RECONFIGURE WITH OVERRIDE选项运行后才有效），最后一列“run_value”是目前有效的设置值。如果你在最后一次重启SQLServer后没有更改任何值的话，最后两列的值将是相同的。

不幸的是，这些配置的缺省值在运行SP_CONFIGURE没有列出来。为了方便，本文已列出它们的缺省值。（见最开始的那个表） 

怎样更改SQLServer配置设置

SQLServer的这些配置大多数而不是全部可以在企业管理器中进行修改。但是更简单的一个途径是运行SP_CONFIGURE命令去更改这些值，象这样：

SP_CONFIGURE ['configuration name'], [configuration setting value]
GO
RECONFIGURE WITH OVERRIDE
GO

注：

configuration name指的是配置设置的名称（见上表）。注意名称必须用单引号括起来（或者是双引号，这依赖于查询分析器的配置）。configuration setting value指的是该配置的具体的数值（不用单引号）。

一 旦运行完SP_CONFIGURE命令，你必须做下面的工作，要么运行RECONFIGURE选项（用于常规设置），要么运行RECONFIGURE WITH OVERRIDE选项（用于那些如果你犯错了就会给你带来麻烦的设置），否则你的更改不会生效。与其试图记住什么时候需要用RECONFIGURE，还不 如记住任何时候RECONFIGRE WITH OVERRIDE都适用来得容易，RECONFIGRE WITH OVERRIDE适合于所以的配置。如果你用企业管理器更改了设置，RECONFIGURE WITH OVERRIDE会自动的执行，所以你不必再去执行。

一旦你更改完毕，大多数的设置而不是全部会立即生效，有一些值在运行RECONFIGURE后也不会生效，除非重启SQLServer的服务。

在完成本文之前，你应该知道：许多配置属于“advanced”设置。在使用SP_CONFIGURE命令更改这些值之前，你必须首先更改SQLServer配置中的一项，然后才能去更改那些配置。命令如下：

SP_CONFIGURE 'show advanced options', 1
GO
RECONFIGURE
GO

仅在你运行上面的代码后你才能运行SP_CONFIGURE来更改那些高级的SQLServer配置。

现在你知道怎样更改这些SQLServer配置选项了，下面看看它们和性能的关系。 

Affinity Mask

当SQLServer 在Windows服务器下运行时，一个SQLServer线程可以在CPU之间迁移。这个特征允许SQLServer同时运行多个线程，这样服务器可以在 多个CPU之间进行更好的负载均衡。每当一个线程从一个CPU移到另一个CPU，处理器缓存都要重载，大多数情况下会影响性能。

在多于4个CPU的负荷繁重的服务器里，通过特定处理器运行特定的线程来提升性能。这会减少处理器缓存重载次数，提升了服务器的性能。例如你可以指定SQLServer只运行在一些CPU上，而不是所有可用的CPU上。

"affinity mask"选项的缺省值是0，这意味着SQLServer允许Windows调度算法设置线程的亲和力。换句话说，是操作系统而不是SQLServer决 定哪个线程运行在哪个CPU上，什么时候将线程从一个CPU迁移到另一个CPU。在一个有4个或更少CPU的服务器上，缺省值时最好的设置。对于多于4个 CPU的不是过度繁忙的服务器来说，对于最优性能来说缺省值也是最好的设置。

但 是对于多于4个CPU有繁重负荷的服务器来说，由于一个或者更多的非SQLServer程序和SQLServer同时运行，你需要考虑将 "affinity mask"选项的缺省值更改为一个更加合适的值。请注意如果服务器上只有SQLServer一个程序运行，使用"affinity mask"限制CPU的使用会伤害性能而不是提升性能。

例 如，假定服务器运行了SQLServer，多个COM+对象和IIS，服务器有8个CPU并且是很忙的。通过将SQLServer运行的CPU数量从8个 减少到4个，SQLServer线程现在仅仅运行在4个CPU上，而不是8个CPU上。这将减少SQLServer线程在CPU间迁移的次数，减少处理器 缓存重载的频率，减少CPU使用率，从而潜在的提升一些性能。剩余的4个CPU将用来运行操作系统和其他非SQLServer程序，减少线程迁移，提升性 能。

例如，一个8CPU的系统，使用SP_CONFIGURE命令设置SQLServer可以运行的CPU的值如下：

十进制值	允许SQLServer线程运行的处理器
1	0
3	0和1
7	0, 1和2
15	0, 1, 2和3
31	0, 1, 2, 3和4
63	0, 1, 2, 3, 4和5
127	0, 1, 2, 3, 4, 5和6

配置一个合适的affinity mask值是不容易的，你应该参考帮助文档以获得更多的信息。在你更改该选项的值后测试看看设置的值对性能是好还是坏。除了试错的方法，没有更好的方法为你的服务器设置一个合适的affinity mask值。

作为监控的一部分，如果你发现affinity mask使用的不是缺省值，请找出原因。如果没有好的答案，将该值修改为缺省值。 

启用Awe

如 果实在Win2000或2003的任何版本下运行SQLServer2000的标准版，或者是在Win2000或2003Server版下运行 SQLServer2000的企业版，或者你服务器的内存少于 4G ，"awe enabled"选项将缺省为0，意思是AWE内存不被使用。

AWE （地址窗口扩展）API允许在Win2000或20003 Advandced Server下，或在Win2000或Win2003 DataCenter Server下运行的程序访问超过 4G 的内存。SQLServer2000企业版（不是标准版）是AWE可用的，这样能利用服务器超过 4G 的内存。如果操 作系统是Win2000或20003 Advandced Server，SQLServer2000企业版能使用高达 8G 的内存。如果操作系统是Win2000或Win2003 DataCenter Server，SQLServer企业版能使用高达 64G 的内存。

缺 省地，在Windows 2000 and 2003 (Advanced and Datacenter)下运行SQLServer2000企业版，如果物理内存超过 4G ，SQLServer也不能访问超过 4G 的内存。为了使操作系统和 SQLServer2000企业版利用更多的内存，需要完成2个步骤。 正确的配置AWE内存支持依赖于你服务器有多少内存。本质上配置Win2000或Win2003（Advanced或DataCenter）必须在boot.ini文件的启动行添加下面的语句以打开AWE开关，然后重启服务器：

• 4GB RAM:  /3GB (AWE支持不被使用)
• 8GB RAM:  /3GB /PAE
• 16GB RAM:  /3GB /PAE
• 16GB + RAM:  /PAE

/3GB开关用来告诉系统允许SQLServer从Win2000和20003本身支持的4GB的内存中使用3GB。如果你不指定这个选项，SQLServer将仅仅值使用服务器第一个4GB内存中的2GB，这样就浪费了1GB的内存。

AWE 内存技术仅仅用于超过4GB的内存，这就是为什么/3GB开关在你的服务器上被用来使用尽可能多的内存。如果你的服务器有16GB或者小于16GB的内 存，那么使用/3GB开关是重要的。但是如果你的服务器有大于16GB的内存，那么你不必使用/3GB开关。原因是因为为了使用所有额外的AWE内存， 1GB的额外内存需要服务器通过/3GB开关来提供。换句话说，如果你的服务器有大于16GB的内存的话，操作系统自身需要2GB的内存来管理AWE内 存，如果你的服务器有16GB或者小于16GB的内存，那么操作系统置需要1GB的内存，允许SQLServer去使用另外1GB的内存。

一旦完成该步骤，接下来就是设置"awe enabled"的值为1，然后重启SQLServer服务。只有这样SQLServerf才能使用服务器里额外的内存。

使 用"awe enabled"选项需要小心一点，就是在打开该选项后，SQLServer不再动态管理内存了。相反，它会使用所有可用的内存（除留给操作系统的 128M 的内存外）。如果你要禁止SQLServer使用所有的内存，你必须设置"max server memory"选项（将在后面做详细描述）来限制SQLServer使用内存。

作为监控过程的一部分，你要检查这个设置的值是多少，是否与服务器的硬件和软件匹配。如果不匹配，相应地修改这个值。 

Cost Threshold for Parallelism

使用并行去执行SQLServer查询有一定的成本。这是因为并行比串行占用了额外的开销。但是如果并行的好处高于成本开销的话，那么使用并行还是值得的。

首要原则是，如果串行执行很快，就没有必要考虑用并行来完成，评估可能的并行所必须的额外时间也许会比串行长得多。

缺 省地，如果查询优化器发现一个查询少于5秒就能执行完成，那么SQLServer不会考虑并行。可以使用SQLServer选项"cost threshold for parallelism"来更改5秒这个数字。该值可以在0到32767之间任意配置。所以如果你设置该值为10，这就意味着如果一个查询执行完成少于 10秒的话，查询优化器不会考虑对该查询进行并行处理。

大 多数情况下，你不用改变该值。但如果你发现你的SQLServer并行的运行了很多查询而CPU仍然很高的话，那么增加该值到一个大于5的值（你需要根据 你的情形通过多次试错的方法来寻找一个理想的值），这样会减少使用并行的查询 的数量，也减少了CPU的使用率，这有助于提升你服务器的性能。

另一个考虑的选项是将5减少到一个更小的值，，尽管大多数情况下可能会影响性能而不是提升性能。一个更小的值在SQLServer的数据仓库运行很多复杂查询下可能是有用的，因为一个更小的值会使查询优化器使用更多的并行。

在你的服务器上使用一个修改的值前，你需要彻底地测试该值。

如果SQLServer仅用一个CPU（要么是因为服务器上只有一个CPU，要么因为"affinity mask"设定的值），并行是不会被考虑的。

如果你发现"cost threshold for parallelism"选项被使用，找出原因。如果你找不到答案，将其改回缺省值。 

Cursor Threshold

如果你的SQLServer不使用游标或者很少使用，那么从不要更改该选项的的缺省值-1。

"cursor threshold"选项的值-1告诉SQLServer同步的执行所以的游标，如果游标的结果集不是很大，那么它是一个理想值。如果你的SQLServer有许多游标或者所以游标的结果集都很大，那么同步执行游标不是最有效的方法。

"cursor threshold"选项对于运行大的游标来说除缺省值外还有2个值可设置。一个值是0，它表示所有的游标都异步的执行，如果SQLServer有许多游标或者所以游标的结果集都很大，这会提高效率。

如 果SQLServer有些游标的结果集小而另一些大，那么我们该怎么办呢？这种情况下，我们可以根据这些结果集的大小值来为SQLServer决定一个大 小值。例如，考虑把结果集小于1000行的任何游标作为小结果集的游标，而大于1000行的作为大结果集的游标，这样，我们可以设置"cursor threshold"选项的值为1000。

当"cursor threshold"选项的值被设为1000，这意味着查询优化器对于那些结果集小于1000行的游标采用同步处理的方式。而结果集大于1000行的将采用异步方式处理。

大 多数情况下，这个选项提供了最好的方式。唯一的问题就是需要决定"cursor threshold"值的大小，这需要进行测试。但是正如你所料，缺省值通常是最好的，如果你确定你的应用程序使用非常大的游标并且进行了测试以确定更 改，那么更改该选项的值有助于性能的提升而不是影响性能。

作为监控的一部分，你也需要知道游标执行的频率，结果集的大小。这样就可以为你的服务器配置一个最好的值。当然你尽量在服务器上不要使用游标，这样就可以保留缺省值而不必担心游标了。 

Fill Factor (%)

这个选项允许你创建索引时更改索引的缺省填充因子。缺省地，该值通常为0。0有点使人迷惑，因为它意味着叶索引页100％（不是0％）的被填充，但是中间索引页（非叶子页）有一些空间而不是被100％的填满。该选项的取值范围为0到100之间。

当创建索引时没有指定填充因子的值时系统会使用缺省的填充因子。如果指定了一个值，创建索引时会使用该值而不是缺省值。 大多数情况下，最好不要修改缺省值。如果你需要一个不同的值，在创建索引时指定即可。

作 为监控的一部分，注意该值是不是不同于缺省值0。如果是，找出原因。如果你不能找到为什么要修改缺省值或者没有更好的原因，将其改回缺省值。 如果该值已经被更改，请记住任何索引在创建时都会使用这个更改后的缺省值。这样，你需要重新确定这些索引是否适合这个填充因子的值。

 

Index Create Memory (KB) 

index create memory选项用来控制索引创建排序时所需的内存数量。默认值是0，这意味着SQLServer动态确定该内存数量。在几乎所有的情况下，SQLServer会确定内存的最佳值。

但 在某些情况下，特别是对于非常大的表，可能导致SQLServer错误，因为大索引创建会很慢或根本不创建。如果你遇到这种情况，你需要设置一个 Index Create Memory选项的值，尽管你不得不试错直到找到最佳值为止。该选项的合法范围在704到2147483647之间，它是SQLServer在创建索引时 能提供的值，单位是KB。

记住如果你确实要改变该选项，这个内存值只分配给索引创建而对其他的操作不起作用。如果你的服务器有更多的内存，那么这不是问题。但如果你的服务器没有太多的内存，更改该选项的值可能对SQLServer的其他产生一些消极影响。你可以考虑仅在创建或重建大索 引时更改该选项，其他时间改回缺省值。 

和其他的选项一样，如果你监控发现该选项不同于缺省值，找出原因，如果找不到原因或者没有更好的原因，将其改回缺省值。 

Lightweight Pooling 

缺 省地，SQLServer7.0和2000是以“线程模式”运行的。这就是说SQLServer使用UMS（用户模式调度）线程运行用户程序。 SQLServer将为每个程序创建一个UMS线程，每一个线程在SQLServer忙时轮流处理许多用户程序。为了达到最佳效率，UMS试图平衡每个线 程的用户程序数量，试图在服务器的所有CPU之间有效的均衡所有的用户程序。

SQLServer也有一个优化模式叫纤程模式。这种情 况下，SQLServer对每一个处理器使用一个线程（象线程模式一样），但不同的是每个线程里运行多个纤程，当正在运行的一个线程对于服务器上其他运行的SQLServer线程没有优先级别的时候使用纤程。想想在某些环境下，纤程作为轻量级线程，对它的管理比标准的UMS线程用更少的开销。使用 SQLServer的配置选项"lightweight pooling"来开启和关闭纤程模式，缺省是0，即纤程模式是关闭的。

所有这些意味着什么呢？象所有的事情一样，在一种模式下或者另一种模式下运行总是有其赞成者和反对者。一般说来，当下列所有条件成立时，纤程模式才是有利的：

• 服务器上有2个或更多的CPU（CPU越多，效果越大）
• 所有的CPU大多数时间都运行在接近最大值也就是90-100%之间
• 服务器上有许多context switching事件（性能监视器为系统对象：Context Switches/sec）。一般说来，每秒超过5000个context switches    事件就被认为过高了。
• 服务器正在产生使用很少或者根本没用的分布式查询或者扩展存储过程。

如果以上都满足，那么将"lightweight pooling"选项打开，也许会看到5%或更大的性能改善。

但 是如果不满足任一条件，将"lightweight pooling"选项打开实际上可能降低性能。例如，如果你的服务器大量使用了分布式查询或者扩展存储过程，那么打开该选项会明确地引发问题，因为他们不能使用到纤程，即SQLServer不得不来回在纤程模式和所需的线程模式之间切换，从而影响性能。 

和其他设置一样，如果你发现该设置不是缺省值，试图去找到原因。另外，检查上面四个条件是否存在，如果是，打开该选项，否则使用缺省值0。 

Locks 

每 当SQLServer锁定一条记录时，锁会存储在内存中。缺省地，"locks"选项的值是0，即锁内存是动态管理的。SQLServer内部可以为锁保 留2%到40%的可用内存。另外，如果SQLServer确定为锁分配额外的内存会引起操作系统级的页面调整，那将不会分配内存给锁，相反为了禁止页面调 整会分配给操作系统。 

大部分情况下，允许SQLServer动态管理锁，保留其缺省值。如果你配置锁内存（合法值在5000到2147483647 KB之间），那么SQLServer不能动态管理这部分内存，这可能引起SQLServer的其他区域的性能降低。 

如果得到一个错误消息：超过最大的可用锁数量，那么你可以有以下办法：

• 检查查询看是否使用了过多的锁。如果是，性能可能会因为应用程序并发而受到影响。比改善坏查询更好的方法是为跟踪到的锁分配更多的内存。
• 减少服务器上的应用程序数量
• 为服务器添加更多的内存
• 对锁数量设置一个较高的值（基于试错）。这是一个最少令人满意的选项，和给锁分配内存以阻止SQLServer为了其他目的而占用内存一样。

最大努力地不要使用这个选项。如果你发现这个选项设置的不是缺省值，找出原因，如果你找不到原因或者原因太少，就改回缺省值。 

Max Degree of Parallelism 

该 选项允许你将并行打开、关闭、或者为某些CPU打开，但不是为全部的CPU打开。并行指的是查询优化器使用多于1个CPU去执行查询的能力。缺省地，并行 是打开的并且尽可能多的使用服务器的CPU（除非被affinity mask选项限制）。如果你的服务器只有1个CPU，该选项会被忽略。

这 个选项的缺省值是0，这意味着并行是为所以可用CPU打开的。如果你改变该值为1，并行对所有CPU就关闭了。这个选项允许你设置并行能使用多少个 CPU。例如，如果你的服务器有8个CPU，而你只想让并行运行在其中的4个CPU上，那么将该值设置为4。尽管这个选项是可用的，而想使用它来真正提高性能却是不确定的。 

如果并行是打开的，正如多CPU的服务器缺省那样，那么查询优化器将评估每个查询使用并行的可能性，会带来一些开销。在许多OLTP服务器上，查询本身通常不会采用并行去运行。这包括标准的SELECT、INSERT、UPDATE、DELETE语句。因此，查询优化器在评估每一个查询是否值得用并行只是在浪费时间。如果你了解到你的查询可能从来不需要并行，你可以通过关闭该选项来获得性能的一点提升，因为不会为 查询评估并行。 

当然，如果查询本身能利用并行，你不需要关闭并行选项。例如，如果OLTP服务器上运行了许多相关联的子查询，或其他复杂的查询，那么你可能需要将并行开着。你需要测试这个选项看是否有所帮助。

大 多数情况下，因为许多服务器既运行OLTP又运行OLAP查询，并行应该保存打开。作为你性能监控的一部分，如果你发现并行关闭或受限，找出原因。另外，确认服务器是不是基于OLTP的。如果是，关掉并行也许更合适，尽管你需要通过测试看关闭是否有助于性能的提升。但如果服务器既运行OLTP，又运行 OLAP，或者大部分OLAP查询，那么为了全面提升性能最好将并行打开。 

Max Server Memory (MB) & Min Server Memory (MB) 

为 了最佳的SQLServer性能，你需要确定你的服务器仅仅运行了SQLServer，而没用其他的应用程序。大多数情况下，"maximum server memory" 和 "minimum server memory" 选项设置为缺省值即可。这是因为缺省值为了最佳性能允许SQLServer动态分配内存。如果你修改了最大或最小内存设置，可能你会冒影响性能的风险。 

另一方面，如果SQLServer不能运行在它自己的物理服务器上（其他程序和SQLServer运行在同一台物理服务器上），你需要考虑更改最小或最大内存值，尽管这通常是不需的。 

让我们仔细研究一下这两个选项。 

"maximum server memory"选项，当设置为缺省值2147483647（单位MB），意味着SQLServer动态管理内存，即SQLServer将尽可能使用可用内存（除留给操作系统一些必要的内存外）。 

如果你想要SQLServer不使用服务器上所有的可用内存，你能手动设置最大内存。SQLServer能使用的指定的内存在4（你能输入的最小值）到你服务器上最大的物理内存（但不要分配服务器上所有的内存，因为操作系统也需要）。

仅当SQLServer必须和同一台服务器上的其他应用程序共享内存，或者你想人工保持SQLServer使用可用的内存，你才需要去改变缺省值。例如，如果你其他的应用程序比SQLServer性能重要，那么你可以限制SQLServer的性能。 

如 果你试图手动设置"maximum server memory" 选项的值，你可能会遇到两种潜在的性能瓶颈问题。第一，如果你分配了太多的内存给SQLServer，而对于其他的应用程序和操作系统没有足够的内存，那 么操作系统别无选择地要做很多的页面调整，这将降低服务器的性能。而且，如果你使用了全文索引服务，你必须为它留出足够的内存。它的内存不是动态的分配， 象剩余的SQLServer内存一样，要运行它必须有足够的适当的内存。 

"min server memory"选项的缺省值0（单位MB），意味着SQLServer动态管理内存，即SQLServer将按照需要分配内存，最小值将随着SQLServer的需要而变化。 

如果更改"min server memory"选项的值而不设置为缺省值0，这并不意味着SQLServer自动开始使用这个最小的内存设置，许多人是那样认为的，但是一旦由于需要超过了设置的最小的内存，那么将永远不再小于这个最小值。 

例 如，如果你设置了最小值为100MB，然后重启SQLServer，SQLServer不会立即使用100MB这个最小的内存。相反，SQLServer 仅仅使用需要的内存。如果你从不需要100MB，那么将从不会使用100MB。但是如果SQLServer使用超过了100MB，而以后不再需要 100MB，那么这100MB将成为SQLServer分配的最低内存。因此，没有理由将"min server memory"选项的值不设置为缺省值而改为其他值。

如果服务器上只有SQLServer，根本没有理由去使用"min server memory"选项。如果还运行了其他程序，改变该值可能会获得一些微小的好处，但决定设置为何值是很困难的，并且这个性能的提升基本上可以忽略。 

如果你发现这些选项的值不是缺省值，找出原因。如果找不到原因，或者原因站不住脚，将它改回缺省值。 

Max Text Repl Size 

"max text repl size"选项可以设定在执行单个INSERT、UPDATE、WRITEEXT或者UPDATEEXT命令时可以增添到复制字段的 text 和 image 数据的大小（单位为字节）。如果你没用到复制或者复制没有用到text、image字段，那么该选项不用修改。

缺省值是65536，最小值是0，最大值是2147483647（单位为字节）。如果对text、image数据有很多的复制，仅当数据超过64K，你应该考虑增加该值。但与这些设置的最大值一样，你将不得不用各种值去实验看哪个值在你的特殊环境下效果最好。 

作为监控的一部分，如果你不使用复制， 正确的值只有缺省值。如果缺省值被更改，你需要调查text、image数据是否被复制。如果没有，或者如果小于64KB，那么改回缺省值。 

Max Worker Threads 

SQLServer 的配置选项"max worker threads"被用来决定操作系统上的sqlservr.exe进程允许有多少个工作线程可用。缺省值是255个工作线程。SQLServer自身使用一些线程，我们不讨论这些线程。这里将焦点放在那些由用户创建线程上。 

如果有多于255个用户连接，那么SQLServer将使用线程池，即多于一个用户连接使用一个工作线程。尽管线程池减少了SQLServer使用的系统资源，它也能在访问SQLServer的用户连接之间增加资源争夺，从而影响性能。 

为 了找出你的SQLServer运行了多少个工作线程，使用企业管理器检查目前你服务器的连接数量。对于每一个SQLServer连接，都有一个工作线程被 创建，最高到"max worker threads"选项设置工作线程总数。例如，如果有100个连接，那么有100个工作线程将被创建。但如果有500个连接，但只有255个工作线程可 用，那么只有255个工作线程被使用，其余打开的连接共享这些有限的工作线程。

如果你的服务器有足够的内存，为了得到最好的性能，你要设置"max worker threads" 选项的值为你服务器曾经达到的最大的用户连接数再加5，但这个常规的建议存在一些局限，正如一会儿我们看到的。 

前面已经说过，"max worker threads"的缺省值是255。如果你的服务器从未超过255个连接，那么不必改变这个缺省值。这是因为工作线程仅在需要的时候创建。如果仅有50个连接到服务器，那么将仅只有50个工作线程，而不是255这个缺省值。 

如 果你的服务器通常超过255个连接，而"max worker threads"的设置仍然是缺省值255，那么SQLServer将使用线程池。现在进入了两难的局面。如果你增加"max worker threads"的值一个线程一个连接，SQLServer将占据额外的资源（更多的内存）。如果你的服务器有很多未被SQLServer或其他程序使用 的内存，那么增加"max worker threads"的值将提升SQLServer的性能。 

但是如果没有另外可用的内存，那 么添加更多的工作线程会影响SQLServer的性能。在这情况下，允许SQLServer使用线程池来提供更好的性能。这是因为线程池使用更少的资源 （比起不使用线程池来）。但是，消极的一面，线程池在连接之间会产生资源争夺的问题。例如，共享一个线程的两个连接同时执行一些任务的时候会产生冲突（因为一个线程同时只能为一个连接服务）。 

那么该怎么办呢？简而言之，如果你的服务器通常少于255个连接，保留缺省值设置。如果你的 服务器超过255个连接，且有更多的内存，那么考虑增加"max worker threads"设置的连接数再加5。但如果没有太多的内存，保留缺省值。对于有成千上万连接的SQLServer来说，你需要通过试验找到在额外的工作 线程使用额外的资源和争夺相同工作线程的连接之间的分界线。 

也许正如你所期望的，在使用这个选项之前，你要在改变该设置的前后测试服务器的性能，看看SQLServer的性能是提升还是下降了，从而确定一个合适的值。 

作为监控的一部分，按照上面给出的建议来设置该选项的值。 

Min Memory Per Query 

当 一个查询运行时，为了运行得更快更有效率，SQLServer尽量分配合适的内存给查询。缺省地，"minimum memory per query"选项分配的是1024KB，这是每个查询运行的最小内存。"minimum memory per query"选项可以在0到2147483647 KB之间设置。

如果查询需要更多的内存运行才有效率，且有可用内存，那么SQLServer自动的分配更多的内存给查询。因此，通常不建议修改该选项的缺省值。 

在 某些情况下，如果SQLServer比有效率的运行有更多的内存，那么增加该选项的值到一个更高的值（如2048KB或更高）可能提升某些查询的性能。一 旦服务器有更多可用的内存（本质上，这些内存没有被SQLServer使用），那么提高该选项的值能全面提升SQLServer的性能。但如果没有，增加 该选项的值可能降低性能而不是提升。 

Nested Triggers 

这个配置选项的确影响性能，但不在常规的 方法里。缺省地，"nested triggers"选项的缺省值为1。意即可以运行嵌套触发器（触发器最多能够嵌套32层）。如果将其设置为0，那么将不运行嵌套触发器。显然，通过不允 许嵌套触发器，能够全面提升性能，但要以应用程序的灵活性作为代价。 

请保留该选项的缺省值，除非你要防止开发人员使用嵌套触发器。一些依靠嵌套触发器的第三方程序如果关闭嵌套触发器也会运行失败。 

Network Packet Size (B) 

"Network packet size"决定SQLServer通过网络与客户端会话时信息包的大小。缺省值是4096字节，该值的最小值最大可设为512字节，最大值依赖于使用的网络协议所支持的值。

理 论上，改变该值以或多或少适应数据包的大小可以提升性能。例如，如果数据很小，平均小于512字节，更改缺省的4096字节到512字节可以提升性能。或 者，如果你在做大量数据的移动，如大批量的导入或在处理大量的TEXT、IMAGE数据，那么增加该值以大于缺省值，这样会发送较少的包，从而提高性能。  

理论上，这听起来很好。实际上，不管哪个，你看到的性能提升很少。这是因为没有考虑平均的数据大小。某些情况下数据很小，另一些情况数据很大。因此改变这个选项的缺省值通常没有太多的帮助。 

作为监控的一部分，小心检查每一个不是缺省值的设置。如果找不到答案，改回缺省值。

Open Objects 

"Open objects"指的是SQLServer能同时打开的对象（包括表、视图、默认值、触发器和存储过程）的数量。该选项的缺省值是0，意味着SQLServer为了获得最好的性能动态的增加或减少该值。 

很少情况下，可能会得到一个信息说打开的对象超过可用的数量，通常这种情况是服务器内存全被使用了。解决它的最好方法是增加服务器的内存或者减少服务器的负载，如减少服务器维护的数据库的数量。

如 果上面两个选项都不满足实际，可以手动配置给该选项一个适当的最大值。这个问题是双方面的。首先，决定适当的值需要太多的试验。其次，给打开对象分配的任何内存将被其他的SQLServer需求使用，潜在的降低服务器的整体性能。当然，当你改变该选项的值你的应用程序也会运行，不过会变慢。避免改变该选项的值。 

当你监控性能时，如果发现该值不是0， 要么是有人犯错误需要纠正，服务器的硬件太小，为它添加更多的内存，要么是服务器工作需要移到另一个不是很忙的服务器上。 

Priority Boost 

缺省地，SQLServer进程和服务器上其他应用程序有相同的优先级别。也就是说，没有个别的应用程序进程在获得CPU时钟时有比其他进程更高的优先权。 

"priority boost"配置选项允许改变。缺省值是0，即SQLServer进程和其他的应用程序进程有相同的优先权。如果改为1，那么SQLServer有比其他应用程序进程更高的优先权。本质上，这意味着SQLServer比同一服务器上的其他应用程序进程有第一优先权使用CPU时钟。但是这真能提升 SQLServer的性能吗？ 

让我们看看一对情形。首先，假定服务器不只运行SQLServer，也有其他的应用程序（为了最好的性能不推荐这样使用，但真实世界有可能存在这种情形），且有很多的CPU可用。如果是这种情形，给SQLServer一个更高的优先权会怎样呢？不怎么 样。如果有很多可用的CPU，提高优先权并不意味着什么，和其他程序相比，SQLServer也许获得一些毫秒级的时间，但我怀疑你能注意到这个区别。 

现在让我们看看上面这个熟悉的场景，但是假定CPU事实上都耗尽了。如果是这种情况，给SQLServer一个更高的优先权当然会运行得 更快，但是只有以其他应用程序运行得慢为代价。如果这是你需要的，那么没问题。但更好的解决方法是提升服务器上CPU的能力或减少服务器的负载。 

但如果SQLServer运行在一个没有其他应用程序的专用服务器上且有很多过剩的CPU可用呢？这种情况下，提升优先权没有用，因为没有CPU竞争（除了部分操作系统进程外），而且有很多CPU还可用。 

最后一种情形，假如SQLServer运行在专用服务器上，且CPU没有空闲，给更高的优先权是一个零和游戏，这样做潜在的给一部分操作系统以消极的影响。而SQLServer获得的性能却很少。 

正如你所见，这个选项不值得修改。事实上，微软有文档说明使用这个选项的几个问题，试图使用这个选项甚至很少令人满意。

如果在你的监控列表里发现该选项打开，找出目的。如果打开它目前没有任何问题，你可能会没有问题的打开它，但是我建议改回缺省值。 

Query Governor Cost Limit 

"query governor cost limit"选项设置查询所能运行的最高时间限制，这是我认可的少数几个SQLServer配置选项之一。例如，假定你服务器的一些用户喜欢运行长时间的查询，这真正会降低你服务器的性能。通过设置该选项，你能禁止运行任何超过300秒（或者任何你确定的数）的查询。缺省值是0，即一个查询运行多长时间都 没有限制。 

你为这个选项设置的值是一个近似值，并且基于查询优化器估计出的查询运行的时间。如果估计值比你提供的值要多得多，查询根本不会运行，反而产生一个错误。这能节约大量的有用的服务器资源。 

另一方面，如果用户不得不为了完成他们的工作而由于你他们不能运行查询，他们将真正感到不快。也许你考虑该做的是帮那些用户写更有效率的查询。这样，大家皆大欢喜。 

不 象我的其他很多建议，如果你的监控列表里该值大于0，很好。只要用户不抱怨，这就是一个好的处理。事实上，如果设置为0，这儿考虑增加一个值，看看发生了 什么。只是不要加得太小。可以考虑一开始加600秒，看看发生了什么。如果没问题，然后试试500秒，依此类推，直到你发现用户开始抱怨位置，然后改回前 一个值。 

Query Wait (s) 

如果SQLServer很忙且在不断使用更多的内存资源，它将大量占用内存的查询（如那些涉及排序和哈希操作的查询）排队等待，直到有足够的内存运行它们。有些情况下，没有足够的内存运行它们，最终会超时，产生一个错误消 息。缺省地，一个查询运行的时间如果超过查询优化器估计它运行要花费的时间的25倍后，该查询将超时。 

这个问题的最好的解决方法是 给服务器添加更多的内存，或者减少它的负载。如果你不能这么做的话，一个可选项就是使用"query wait"配置选项，尽管它本身有很多问题。缺省值是-1，等待的时间如上所述，然后引起超时。如果你要时间很大以便查询不超时，可以设置"query wait"一个足够大的值。正如你也许猜到的那样，你将不得不通过试错决定该值。

使用这个选项的问题在于有这样一个查询的事务可能会保持锁，这会引起死锁或者其他一些锁争夺的问题，最后出现一个比查询超时更大的问题。因此该选项不建议修改。 

如果在你的监控列表里发现该选项没有设置为缺省值，找出原因。如果没有好的原因，请改回缺省值。但是如果有人彻底考虑过它，且你也没有发现锁问题，那么考虑保持现状。 

Recovery Interval (min) 

如 果你有一个有很多INSERT、UPDATE、DELETE的活动频繁的OLTP服务器应用程序，"recovery interval"的缺省值0（意味着SQLServer自动决定适当的恢复时长）也许不合适。如果你正用性能监视器监视你服务器的性能，注意有一个规则的100％的磁盘写活动的周期（发生在检查点运行期间），你要设置该选项一个更高的值如5或10。它表示SQLServer重启后恢复数据库所需的最大分 钟数。缺省值是0，实际上，这表示每个数据库的恢复时间不超过 1 分钟。

使用该选项的另一个潜在的原因是如果服务器是OLAP或数据仓库专用服务器的情形。在这些实例里，有很多只读数据库通常从一个短小的恢复时长里得不到好处。 

如果你的服务器不匹配上面的任一建议，那么保留缺省值通常是最好的选择。 

通 过延长检查点时间，可以减少SQLServer执行检查的次数，如果有效，减少SQLServer的一些开销。在性能和为SQL花费的时间之间找到一个折 中方案需要多次试验。为了减少下次SQLServer重启需要的恢复时间你需要配置一个尽可能小的值。这是因为每次SQLServer服务启动时，它将经 历自动恢复过程，该选项的值设得越大，恢复过程花费得时间就越长。你不得不决定在性能和恢复时长之间找到一个折中的方案以便最适合你的需求。 

作为监控的一部分，你要估计该选项目前的设置和它潜在的使用。对于繁忙的OLTP服务器来说，在你决定增加该选项的值看看是否有帮助之前你要做大量的调查。测试是重要的。但如果你的服务器是OLAP或数据仓库专用服务器，增加该选项的值是一个很容易做出的决定。 

Scan for Startup Procs 

如果得到正确的配置，SQLServer服务启动时有能力去寻找自动运行的存储过程。如果你想在启动时做一些特定的操作这是有利的，如载入一些特定的存储过程到缓存里以便当用户开始访问服务器时它已经是准备好的。 

缺省地，"scan for startup procs"选项设置为0，意味着启动时不扫描存储过程。如果你没有任何在启动时要启动的存储过程，那么这是一个显而易见的设置。不必花费资源去寻找那些不存在的存储过程。 

但如果你有一个或多个存储过程想在服务启动时执行，那么该选项需要设置为1，表示启动时扫描。 

如果你在你的监控列表里发现该选项的值为1，检查看是否有任何服务器启动时要执行的存储过程 。如果没有，将该选项的值改回缺省值。 

Set Working Set Size 

当你要更改SQLServer启动时使用的最大和最小的内存时就要用"set working set size"选项。这个选项也帮助你禁止任何页面交换。

该选项的缺省值为0，即不使用该选项。要打开这个选项，必须将它设置为1，并且，最小的内存和最大的内存要设置为相同的值。该值用来保留等于服务器内存设置的物理内存空间。 

和许多选项一样，这个选项通常也不必使用。仅在服务器是SQLServer专用服务器且工作量很大还有很多可用的内存时才考虑。即使那样，任何性能的提升也是最小的，你还要冒潜在的没有留给操作系统足够内存的风险。测试是该选项成功使用的关键。 

如果该选项设置为不是缺省值的另外的值，检查最小的内存和最大的内存是否相同，否则这个选项将不会正确的工作。如果存在上面提到的条件并且经过彻底的测试，那么考虑保留设置。否则，改回缺省值（不要忘记改回所有相关的3个设置）。 

User Connections 

缺省地，SQLServer仅分配需要的用户连接数。这允许那些需要连接的用户连接，同时最小化内存的使用。当"user connections"选项设置为缺省值0时，用户连接数动态设置。事实上在所有的环境下，这个设置都时理想的设置。 

如 果你改变了该选项的值而不设置为缺省值，你是在告诉SQLServer将分配一个你指定的连接数给它，不多不少。它也将为每个连接分配内存，不论这个连接是否使用。由于这些问题，且SQLServer能动态有效的处理这些任务，没有理由改变该选项的缺省值而设置为其他值。 

如果你的监控里显示该值不为0，将其改回0。甚至都不要问为什么。