sqlserver性能监视器

A. sqlserver 2005 怎么实现性能检测与优化

SQL Server数据库查询速度慢的原因有很多，常见的有以下几种：
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是数据库设计的缺陷)
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足
5、网络速度慢
6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）
7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)
8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列
10、查询语句不好，没有优化
●可以通过以下方法来优化查询 :
1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要。
2、纵向、横向分割表，减少表的尺寸(sp_spaceuse)
3、升级硬件
4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段。
5、提高网速。
6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。
配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行 Microsoft SQL Server? 2000时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的1.5倍。如果另外安装了全文检索功能，并打算运行Microsoft搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的3倍。将SQL Server max server memory服务器配置选项配置为物理内存的1.5倍（虚拟内存大小设置的一半）。
7、增加服务器CPU个数;但是必须 明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MSSQL自动评估选择的。单个任务分解成多个任务，就可以在处理器上运行。例如耽搁查询 的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作UPDATE,INSERT， DELETE还不能并行处理。
8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。 like ''a%'' 使用索引 like ''%a'' 不使用索引用 like ''%a%'' 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR。对于字段的值很长的建全文索引。
9、DB Server 和APPLication Server 分离；OLTP和OLAP分离
10、分布式分区视图可用于实现数据库服务器联合体。
联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层 Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。（参照SQL帮助文件''分区视图''）
a、在实现分区视图之前，必须先水平分区表
b、 在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上 运行。系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 设置自动收缩日志.对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。
在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的：
1、 查询语句的词法、语法检查
2、 将语句提交给DBMS的查询优化器
3、 优化器做代数优化和存取路径的优化
4、 由预编译模块生成查询规划
5、 然后在合适的时间提交给系统处理执行
6、 最后将执行结果返回给用户。
其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。

B. 如何识别SQL Server中的CPU瓶颈

问题：
如果经常遇到CPU瓶颈而导致的SQLServer宕机，那如何去发现并解决这些相关的问题？

解决方案：
导致CPU成为SQLServer性能问题的原因有很多，比较明显的原因是因为资源不足。但是，CPU的利用率可以通过配置的更改和查询的优化来降低，所以当你想买更快更好的处理器之前，先要考虑前面的操作。下面是使用一些内置工具来识别CPU相关瓶颈：

性能监视器（Performance Monitor）：
可以使用性能监视器来检查CPU的负载。检查Processor:% Processor Time 这个计数器：如果长期超过80%/处理器，那很有可能面临了CPU相关瓶颈。

CPU密集操作主要是编译和重编译。你可以通过使用SQL Statistics对象计数器来监视它们的情况。也可以监控批处理接收的数量来查看。如果SQL Recompilations/sec 中的BatchRequests/sec的速率很高，那就有潜在的问题：
配置和监视以下计数器：
SQL Server: SQL Statistics: SQL Compilations/sec
SQL Server: SQL Statistics: SQL Recompilations/sec
SQL Server: SQL Statistics: Batch Requests/sec
可以从MSDN中获取关于这部分的详细信息： MSDN Library.

另外一个用于探测CPU相关问题的计数器是：SQL Server: Cursor Manager By Type – CursorRequests/Sec ，用于显示你的服务器上游标使用情况。如果你看到每秒有数以百计的游标请求，那很有可能是因为低效的游标使用和小体积提取操作（small fetch size）引起性能问题。

内部并行查询同样会引起CPU问题，可以检查：
SQL Statistics:Batch Requests/sec counter 计数器。在CPU生命周期中，每秒的批处理应该很小。如果过多，意味着正在使用并行计划运行。

动态管理视图（DMVs）：
以下是对排查CPU瓶颈游泳的DMVs。动态视图：sys.dm_exec_query_stats显示目前缓存的批处理或者使用CPU的过程。下面的查询用于检查耗费CPU的执行计划：
select plan_handle,
sum(total_worker_time) as total_worker_time,
sum(execution_count) as total_execution_count,
count(*) as number_of_statements
from sys.dm_exec_query_stats
group by plan_handle
order bysum(total_worker_time), sum(execution_count) desc

SQLServer2008在每个查询编译时，会计算其hash值。你可以在query_hash列中找到该值，是否两个查询仅仅字面值不同但是使用相同query_hash值。该值也在 Showplan/Statistics XML QueryHash属性中可以查看。
Plan_generation_num列显示一个查询被重编译的次数。
SQLServer优化器尝试选择能提供最快响应时间的执行计划，但是不代表总是低CPU利用。低效的查询计划会引起CPU的好用，此时同样可以使用sys.dm_exec_query_stats 来监控。
如果你想有一个对SQLServer优化所耗费时间的总览，可以检查：
sys.dm_exec_query_optimizer_info 。其中的消耗时间和最后开销会非常有用。
可以使用以下DMVs来查询内部并行查询及其查询文本、执行计划的情况：
sys.dm_exec_cached_plan: Shows the cached query plans.
sys.dm_exec_requests: Shows each executing request in the SQL Server instance.
sys.dm_exec_sessions: Shows all active user connections and internal tasks.
sys.dm_exec_sql_text: Shows the text of the SQL batches.
sys.dm_os_tasks: Shows each active task within SQL Server.

SQL Server Profiler:
如果性能监视器发现有问题，同样可以使用SQLServer Profiler来发现不必要的编译和重编译。SQLServer Profiler 跟踪能帮助你找到一直重编译的存储过程。可以使用下面的事件：
SP:Recompile, CursorRecompile, SQL:StmtRecompile: 这个事件是针对SQLServer的重编译。SP:Recompile事件中的EventSubClass 说明了重编译的原因。
· Showplan XML For Query Compile: 这个事件是针对T-SQL语句的重编译。包含了查询计划和过程的对象ID.注意对这个事件运行一个跟踪，能得到利用系统资源的重要信息。但是，如果性能计数器报告SQL Compilations/sec 的值很高时，跟踪将非常好资源。
低效的游标可以使用RPC:Completed事件来跟踪。查看sp_cursorfetch语句并检查第四个参数，包含每次提前（fetch）包含的行数。

C. 怎样查出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"需要设置得比你服务器曾经达到的最大连接数更高。

D. sqlserver 2005 复制监视器中一直是性能严重

这个应该跟网络环境和复制的量有关吧

E. 性能监视器和SQL Server Profile 的功能和用途分别是什么

应该不是配置上的问题，你可以使用sqlserver的事件探查器来看下自己的数据库中那个地方占用cpu和内存比较多，来进行下优化，另外可以找找是否是有地方有没释放的资源，比如临时表之类的。

F. sqlserver性能监视器有哪些

您好：
附上参考资料，通过sql server profiler进行性能监视
http://jingyan..com/article/a378c9609af34eb32828303a.html
请查收，谢谢。

G. 安装SQL Server 2005时，在检测时出现“性能监视器计数器要求

安装SQL
Server
2005时，在检测时出现“性能监视器计数器要求（错误）”
。
打开注册表，找到：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\Last
Counter
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\Last
Help
这两个的值要与同级目录下009或004文件夹下的Counter和Help最大值对应保持一至即可。
注意：中文版找004，英文版找009
例：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\Last
Counter
值：12072
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\004\Counter
值：10000
将HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\Last
Counter的值替换成
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Perflib\004\Counter中的值即可。