色如果火热火热
② SQLServer巡检内容
缓冲区是创建数据页面的缓冲页面池，这一般是SQL server内存池中最大的部分。这个计数器应该尽可能高。
低值表示只有少数的请求是在缓冲区，其他请求是在磁盘获取服务
这种情况发生可能是SQL server还在准备状态下，或缓冲区的增长需求超过最大可用内存，因此如果此值比较低，应该考虑为系统增加内存。
每好一个检查点操作移到磁盘的页面数量，这些值应该相当低，高值意味着缓冲中更多的页面被标记为脏页面。
脏页面是在缓冲区中被修改的页面。一旦被修改，就标记为脏并在下一个检查点被写回磁盘。
如果这个计数器较高说明系统发生大量的写入操作，可能是I/O问题的征兆。
记录了缓冲区管理器的Lazy write进程每秒写入的缓冲区数量。这个进程会把时间较长的脏页面从缓冲区中删除，将内存释放
数值过高说明I/O有问题或是内存问题。
页面平均寿命，表示一个不被引用的页面在缓冲池中停留的时间。数值低意味着页面从缓冲区中被移走
降低了缓冲的效率并指出内存压力的可能。
值高说明内存短缺，需要将进度挂起等待内存空闲
表示SQLServer希望消耗的动态内存总数。
当前分配给SQLerver的总内存。 如果低于Target Server Memory
那么可能是SQLserver内存需求很低，服务器最大内存设置的太低
均使用性能监视器添加指标查看
方法参考：
https://blog.csdn.net/mingzai624/article/details/51348434
%disk time 磁盘时间百分比 平均值<85%
CurrentDiskQueueLength 当前磁盘队列长度 平均值<2
disk Transfers/sec 每秒磁盘传输数量 平均值<100
Disk Bytes/sec 每秒传输字节数 平均值<每秒10MB(该值需通过磁盘性能测试评估，不同磁盘指标不同)
avg.disk sec/read(write) 每次磁盘读写所需平均时间 平均值<10毫秒
%process Time 处理器时间百分比 平均值<80%
%privileged time 特权时间百分比 平均值<10%
windows server 包括用户模式和特权模式两种 %privileged time为20%-25%表明系统正在进行大量的IO操作，一个专用的SQLserver系统%privileged time不能超过10%
sqlserver:SQL Statistics Batch Requests/sec 每秒接收到的sql命令批数 根据机器配置 一般1000为繁忙，超过1000应注意
SQL Compilations/sec sql编译次数 <100
SQL Reompilations/sec sql重编译次数
Network interface bytes Total/sec 每秒总传输字节数 平均值<NIC容量的50%
NetworkSegment %net utilization 网络利用率 平均值<80%
参考：
https://www.cnblogs.com/dahaoran/p/9447131.html
③ C/S结构使用SQLServer数据库,在没有网络的情况下,怎么样正常使用客户端
像带有离线功能的这种设计，你需要有一个本地数据库，同时有一个内建的队列。也就是说，当你执行本地操作的时候，你操作的是本地的数据库，但同时还有一个线程在不停地读取你的本地数据库上传至服务端。如果网络不通的情况下，就只是暂存在本地数据库中，而不启动线程读取队列。当网络连通了，你就需要去执行上传了。
需要注意的是，你执行的本地操作最好别有出现并发操作的可能，比如说某个维护项，A用户执行了离线修改，B用户执行了离线删除，那听谁的？所以如果只是离线操作的情况，应当注意限制某些功能。
④ 如何测试sqlserver性能
对于DBA来讲，我们都会做新服务器的性能测试。我会从TPC的基准测试入手，使用HammerDB做整体性能评估（前身是HammerOra），跟厂商数据对比。再使用DiskSpd针对性的测试磁盘IO性能指标（前身是SQLIO），再到SQLIOSIM测试存储的完整性，再到ostress并发压力测试，对于数据库服务器迁移，我们还会收集和回放Profiler Trace，并收集期间关键性能计数器做对比。
下面我着重谈谈使用HammerDB的TPC-C来做SQL Server基准测试。
自己写负载测试代码很困难
为了模拟数据库的负载，你想要有多个应用程序用户和混合数据读写的语句。你不想总是对单一行更新相同的值，或者只是重复插入假的值。
自己动手使用Powershell、C#等语言写负载测试脚本也不是不可能，只是太消耗时间，你需要创建或者恢复数据库，并做对应的测试。
免费而简单的压测SQL Server：使用HammerDB模拟OLTP数据库负载
HammerDB是一个免费、开源的工具，允许你针对SQL Server、Oracle、MySQL和PostgreSQL等运行TPC-C和TPC-H基准测试。你可以使用HammerDB来针对一个数据库生成脚本并导入测试。HammerDB也允许你配置一个测试运行的长度，定义暖机阶段，对于每个运行的虚拟用户的数量。
首先，HammerDB有一个自动化队列，让你将多个运行在不同级别的虚拟用户整合到一个队列--你可以以此获得在什么级别下虚拟用户性能平稳的结果曲线。你也可以用它来模拟用于示范或研究目的的不同负载。
用于SQL Server上的HammerDB的优缺点
HammerDB是一个免费工具，它也极易访问和快速的启动基准测试和模拟负载的方法。它的自动程序特性也是的运行工作负载相当自动。
主要缺点是它有一个学习曲线。用户界面不是很直观，需要花费时间去习惯。再你使用这个工具一段时间之后，将会更加容易。
HammerDB也不是运行每一个基准测试。它不运行TPC-E基准，例如，SQL Server更热衷于当前更具发展的OLTP基准TPC-E。如果你用HammerDB运行一个TPC-C基准，你应该理解它不能直接与供应商提供的TPC-C基准结果相比较。但是，它是免费的、快速的、易用的。
基准测试使用案例
基准测试负载不能精确模拟你的应用程序的特点。每个负载是唯一的，在不同的系统有不同的瓶颈。对于很多使用案例，使用预定义的基准测试仍然是非常有效的,包括以下性能的比较：
多个环境（例如：旧的物理服务器，新的虚拟环境）
使用各种因素的不同及时点（例如：使用共享存储和共享主机资源的虚拟机的性能）
在配置改变前后的点
当然，对一个数据库服务器运行基准测试可以影响其他SQL Server数据库或者相同主机上其他虚拟机的性能，在生产环境你确保有完善的测试计划。
对于自学和研究来说，有预配置的负载非常棒。
开始使用基准测试
你可以从阅读HammerDB官方文档的“SQL Server OLTP Load Testing Guide”开始。
⑤ sqlserver broker 什么意思
SQL Server Service Broker 你可以理解为一种 数据库队列的 东西.
异步处理的.
例如我要执行一个耗时比较长的存储过程.
普通的执行方法, 是我 执行了, 然后我等着服务器处理完了, 才能继续干别的事情.
SQL Server Service Broker 则是以一种队列异步处理的机制来完成.
我需要执行一个很耗时的处理.
那么可能就是向某个 队列, 发送一个消息, 然后立即就返回了.
这个时候, 我可以做其他的查询处理.
等服务器执行完毕后, 再向我发一个消息, 告诉我 执行的结果.
⑥ 关于Sqlserver数据库 锁机制的小疑问，下种情况是否需要加入锁机制
不需要，就算确实用户同时执行，数据库的操作机制是有队列的，所以不存在并发情况。
锁基本用不到，我反正开发了5年了没用到过。
你要了解死锁发生的情况，一般是用事务的时候可能会碰到死锁，你申请了A资源，锁住了A然后申请B资源，其他人申请了B资源，然后申请A，这样就互不相让，导致A,B资源都不可访问了，不过其他数据我不知道，SQLSERVER发生这种死锁不是一直锁死的，过几分钟就会发现这个死锁，把锁释放掉，2个事务都失败。
⑦ sqlserver关于动态执行sql问题
set @flag3=@flag3+1;
set @temp1=DATEADD(M,1,@temp1);
set @temp3=@temp1;
在你循环中赋值的语句，你是想每次循环赋不同的时间，但是在你用exec调用时，只能传入最后计算好的唯一的值，这样可能就查询不到数据了吧，不然你拼接成字符串吧
⑧ sqlserver 在对象上的权限设置有哪些动作分别是什么意义
以下粘贴自SQL Server 的帮助信息，文字太多不能贴全，你自己可在帮助中查到更多信息。
-----------------------------
每个 SQL Server 安全对象都有可以授予主体的关联权限。本主题提供了下列信息：
权限命名约定
与特定的安全对象相关的权限
SQL Server 权限
权限检查算法
示例
权限命名约定
下面介绍命名权限时遵循的一般约定：
CONTROL
为被授权者授予类似所有权的功能。被授权者实际上对安全对象具有所定义的所有权限。也可以为已被授予 CONTROL
权限的主体授予对安全对象的权限。因为 SQL Server 安全模型是分层的，所以 CONTROL 权限在特定范围内隐含着对该范围内的所有安全对象的
CONTROL 权限。例如，对数据库的 CONTROL
权限隐含着对数据库的所有权限、对数据库中所有组件的所有权限、对数据库中所有架构的所有权限以及对数据库的所有架构中的所有对象的权限。
ALTER
授予更改特定安全对象的属性（所有权除外）的权限。当授予对某个范围的 ALTER
权限时，也授予更改、创建或删除该范围内包含的任何安全对象的权限。例如，对架构的 ALTER 权限包括在该架构中创建、更改和删除对象的权限。
ALTER ANY
<服务器安全对象>，其中的服务器安全对象可以是任何服务器安全对象。
授予创建、更改或删除服务器安全对象的各个实例的权限。例如，ALTER
ANY LOGIN 将授予创建、更改或删除实例中的任何登录名的权限。
ALTER ANY
<数据库安全对象>，其中的数据库安全对象可以是数据库级别的任何安全对象。
授予创建、更改或删除数据库安全对象的各个实例的权限。例如，ALTER
ANY SCHEMA 将授予创建、更改或删除数据库中的任何架构的权限。
TAKE OWNERSHIP
允许被授权者获取所授予的安全对象的所有权。
IMPERSONATE <登录名>
允许被授权者模拟该登录名。
IMPERSONATE <用户>
允许被授权者模拟该用户。
CREATE <服务器安全对象>
授予被授权者创建服务器安全对象的权限。
CREATE <数据库安全对象>
授予被授权者创建数据库安全对象的权限。
CREATE
<包含在架构中的安全对象>
授予创建包含在架构中的安全对象的权限。但是，若要在特定架构中创建安全对象，必须对该架构具有
ALTER 权限。
VIEW DEFINITION
允许被授权者访问元数据。
REFERENCES
表的 REFERENCES 权限是创建引用该表的外键约束时所必需的。
对象的 REFERENCES
权限是使用引用该对象的 WITH SCHEMABINDING 子句创建 FUNCTION 或 VIEW
时所必需的。
适用于特定安全对象的权限
下表列出了主要的权限类别以及可应用这些权限的安全对象的种类。
权限
适用于
SELECT
同义词
表和列
表值函数 [Transact-SQL 和公共语言运行时 (CLR)] 和列
视图和列
VIEW CHANGE TRACKING
表
架构
UPDATE
同义词
表和列
视图和列
REFERENCES
标量函数和聚合函数（Transact-SQL 和 CLR）
Service Broker 队列
表和列
表值函数（Transact-SQL 和 CLR）和列
视图和列
INSERT
同义词
表和列
视图和列
DELETE
同义词
表和列
视图和列
EXECUTE
过程（Transact-SQL 和 CLR）
标量函数和聚合函数（Transact-SQL 和 CLR）
同义词
CLR 类型
RECEIVE
Service Broker 队列
VIEW DEFINITION
过程（Transact-SQL 和 CLR）
Service Broker 队列
标量函数和聚合函数（Transact-SQL 和 CLR）
同义词
表
表值函数（Transact-SQL 和 CLR）
视图
ALTER
过程（Transact-SQL 和 CLR）
标量函数和聚合函数（Transact-SQL 和 CLR）
Service Broker 队列
表
表值函数（Transact-SQL 和 CLR）
视图
TAKE OWNERSHIP
过程（Transact-SQL 和 CLR）
标量函数和聚合函数（Transact-SQL 和 CLR）
同义词
表
表值函数（Transact-SQL 和 CLR）
视图
CONTROL
过程（Transact-SQL 和 CLR）
标量函数和聚合函数（Transact-SQL 和 CLR）
Service Broker 队列
同义词
表
表值函数（Transact-SQL 和 CLR）
视图
⑨ 在SQLserver里面“命名管道”是什么意思
SQL Server中的命名管道(named pipe)及其使用
1. 什么是命名管道？
与TCP/IP（传输控制协议或internet协议）一样，命名管道是一种通讯协议。它一般用于局域网中，因为它要求客户端必须具有访问服务器资源的权限。
要解释这个问题，我还是摘录微软官方的资料比较好
http://msdn.microsoft.com/zh-cn/library/ms187892.aspx
若要连接到 SQL Server 数据库引擎，必须启用网络协议。Microsoft SQL Server 可同时通过多种协议处理请求。客户端用单个协议连接到 SQL Server。如果客户端程序不知道 SQL Server 正在侦听哪个协议，可以配置客户端按顺序尝试多个协议。使用 SQL Server 配置管理器启用、禁用以及配置网络协议。
Shared Memory
Shared Memory 是可供使用的最简单协议，没有可配置的设置。由于使用 Shared Memory 协议的客户端仅可以连接到同一台计算机上运行的 SQL Server 实例，因此它对于大多数数据库活动而言是没用的。如果怀疑其他协议配置有误，请使用 Shared Memory 协议进行故障排除。
注意：
使用 MDAC 2.8 或更早版本的客户端不能使用 Shared Memory 协议。如果这些客户端尝试使用，将自动切换为 Named Pipes 协议。
TCP/IP
TCP/IP 是 Internet 上广泛使用的通用协议。它与互连网络中硬件结构和操作系统各异的计算机进行通信。TCP/IP 包括路由网络流量的标准，并能够提供高级安全功能。它是目前在商业中最常用的协议。将计算机配置为使用 TCP/IP 可能会很复杂，但大多数联网的计算机已经配置正确。若要配置未在 SQL Server 配置管理器中出现的 TCP/IP 设置，请参阅 Microsoft Windows 文档。
Named Pipes 是为局域网而开发的协议。内存的一部分被某个进程用来向另一个进程传递信息，因此一个进程的输出就是另一个进程的输入。第二个进程可以是本地的（与第一个进程位于同一台计算机上），也可以是远程的（位于联网的计算机上）。
VIA
虚拟接口适配器 (VIA) 协议和 VIA 硬件一同使用。有关如何使用 VIA 的信息，请与硬件供应商联系。
Named Pipes 与 TCP/IP 套接字
在快速局域网 (LAN) 环境中，传输控制协议或 Internet 协议 (TCP/IP) 套接字客户端和 Named Pipes 客户端在性能方面不相上下。但是，网络速度越慢[如在广域网 (WAN) 或拨号网络上]，TCP/IP 套接字客户端与 Named Pipes 客户端的性能差异越明显。这是因为进程间通信 (IPC) 的机制在对等项间的通信方式不同。
对于 Named Pipes，通常网络通信交互性更强。一个对等方直到另一个对等方使用读取命令请求数据时才发送数据。在开始读取数据前，网络读取一般包括一系列窥视 Named Pipes 的信息。这在慢速网络中可能开销非常大，并会导致过多的网络流量，其他的网络客户端反过来也会受到影响。
阐明所讨论的是本地管道还是网络管道也很重要。如果服务器应用程序在运行 SQL Server 实例的计算机的本地运行，则可以选择本地 Named Pipes 协议。本地 Named Pipes 以内核模式运行且速度非常快。
对于 TCP/IP 套接字，数据传输的效率更高，开销也更少。数据传输还可以利用 TCP/IP 套接字性能增强机制的优点，例如窗口化、延迟确认等。这在慢速网络中可能非常有益。对于应用程序的不同类型，这类性能差异可能非常大。
TCP/IP 套接字还支持积压队列。试图连接到 SQL Server 时，与可能导致管道忙错误的 Named Pipes 相比，该队列可以带来有限的平稳效果。
通常，TCP/IP 在慢速 LAN、WAN 或拨号网络中效果较好。而当网络速度不成问题时，Named Pipes 则是更好的选择，因为其功能更强、更易于使用并具有更多的配置选项。
启用协议
该协议必须在客户端和服务器上都启用才能正常工作。服务器可以同时监听所有已启用的协议的请求。客户端计算机可以选取一个协议，或按照 SQL Server 配置管理器中列出的顺序尝试这些协议。
注意：
Microsoft SQL Server 不支持 Banyan VINES 顺序包协议 (SPP)、多协议、AppleTalk 或 NWLink IPX/SPX 网络协议。以前使用这些协议连接的客户端必须选择其他协议才能连接到 SQL Server。
实际上，命名管道在SQL Server配置管理器中看起来是下面这样。其实，在安装好SQL Server之后就自动会有一个管道名称。你当然也可以修改该名称的。
2. 为什么用命名管道？
使用命名管道的原因一般有两个方面
提高速度
假设同样在局域网中，那么使用命名管道协议会比TCP/IP协议快一些。
增加安全性
因为命名管道是只能用于局域网的，那么如果服务器关闭了TCP/IP协议而仅启用命名管道，就可以避免一些安全隐患
3. 如何使用命名管道？
要使用命名管道连接到SQL Server，客户端代码中的连接字符串大致的语法是这样的
"server=.;database=northwind;uid=sa;pwd=pass@word;Network Library=dbnmpntw"
如果服务器是命名实例，则
"server=.\instanceName;database=northwind;uid=sa;pwd=pass@word;Network Library=dbnmpntw"
【注意】必须在服务器启用named pipe协议，并且启动Broswer服务
为了避免在连接字符串中这么麻烦，也为了避免泄露我们连接数据的一些机密信息。SQL Server Native Client还支持定义别名
⑩ 怎样查出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"需要设置得比你服务器曾经达到的最大连接数更高。