SQL SERVER 2005安装错误提示- 性能监视器计数器要求 (错误)!          今天重装Sql Server 2005的时候突然提示错误.如下图: 查看报告如下: .这问题碰到过. 原因刚查了下:造成这种错误的原因在于Microsoft SQL Server 安装程序中的安装配置检查器 (SCC)在安装SQL Server前会验证计数器注册表项的值。如果 SCC 无法验证现有的注册表项，或 SCC 无法运行 lodctr.exe 系统程序，则 SCC 检查会失败，致使安装受阻。 解决办法如下: 1.　　 运行cmd，然后执行 unlodctr w3svc  unlodctr msftpsvc  unlodctr asp unlodctr inetinfo 　　以上是将四个计数器都删除 　　2.　　 以下重新安装计数器 lodctr w3ctrs.ini lodctr ftpctrs.ini lodctr axperf.ini lodctr infoctrs.ini 呵呵.赶紧试试吧. 祝君好运!  本文转自 w156445045 51CTO博客，原文链接：http://blog.51cto.com/enetq/283257，如需转载请自行联系原作者

问题1：使用.net2005自带的SQL-Express连接不上。 　　解决方法： 　　1、网络防火墙阻止数据库连接； 　　2、默认SQL-Express没有启动Sa账户->下载一个management studio express界面工具管理SQL-Express 　　3、无线网络会出现根据机器名找不到SQL服务器的情况，直接用IP连接 　　4、服务端通过开始菜单打开->配置工具->SQL Server外围应用配置器->服务和连接的外围应用配置器->远程连接->右边选择“本地连接和远程连接”->同时使用TCP/IP和named pipes. 　　问题2：在Win-XP上安装开发版提示“对性能监视器计数器注册表执行系统配置检查失败” 　　解决方法： 　　注册表定位到/local_machine/software/microsoft/windows nt/currentversion/perflib下，两个值last counter 和last help 的值改成和004（英文系统为009）目录中相关键值的最大值一样。 　　问题3：其他版本的SQL2005数据库通过“复制”、“导出”、“备份”等方法将数据库复制到SQL DEV上面去后，右键表、新建表等会出现以下错误： 　　类别不支持集合（或类别对象为远程对象） （异常来自 HRESULT：0x80040110 （CLASS_E_NOAGGREGATION）） （Microsoft.SqlServer.SqlTools.VSIntegration） 　　分析：可能是SQL Server 2005的一个Bug，也可能是.net framework变化了，比如安装了其他版本的SQL Server 2005。 　　解决方法： 　　经验证，这样操作先卸载SQL DEV（网上说是卸载客户端即可，笔者是把所有的SQL Server 2005都删掉），再重装/修复.NET 2.0 Framework，再重装SQL DEV，解决问题。 　　问题4：vs2005中gridview不能删除SQL2005中VARCHAR类型字段，提示--“异常详细信息： System.Data.SqlClient.SqlException： 数据类型 ntext 和 nvarchar 在 equal to 运算符中不兼容。” 　　解决方法： 　　SqlDataSource连接的时候不能选择并发控制，就可以编辑和删除了，否则即使不报错，也无法操作。 　　注释：在安装SQL Server 2005的过程中需要关闭注册表监视软件和病毒防护等软件。 本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/

1.问题引出 老鸟为了重点栽培菜鸟，决定交给菜鸟一个艰巨而光荣的任务。这天，菜鸟刚到公司还未坐下，老鸟便劈头盖脸的问道：“你知道，我们如何Trace SQL Server执行语句吗？怎么手动分析这些Trace文件？如何将Trace File与Windows的性能监视器结合，看到每个语句执行时的性能开销？以及如何自动分析SQL Server Trace文件？”。 菜鸟还没有反应过来，就被杀死了99%的老细胞，下意识的回答：“啊？”。 “去研究下吧”，这个周给我答复就好了，老鸟看出来了菜鸟的困惑，心理暗自骄傲。 2.手动Trace SQL Server 菜鸟怀着一颗万事不着急，先问G哥的平稳心态，开始疯狂的问G哥，如何“手动Trace SQL Server”。G哥开始调动亿万个神经细胞，搜索着散落在地球上每一个角落的问题与答案，哦，原来使用SQL Server Profiler工具： Start => All Programs => Microsoft SQL Server R2 => Performance Tools => SQL Server Profiler 或者是： Start => Run => Profiler 打开SQL Server Profiler后， File => New Trace => Server type: Database Engine => Server name: XXXX => Login: XXXX => Password: XXXX => Connect 连接完毕以后，设置Trace Properties： Events Selection => Show all Events => 选择要Trace的事件和字段 => Run。一个简单的Demo长相如下：Trace启动后，一会儿就有被抓到的语句跑出来：欧耶，手动部署SQL Server Trace很简单嘛，搞定。菜鸟迫不及待的问G哥，“如何手动部署Windows性能监视器”。 3.部署Windows 性能监视器 G哥心想，这两个是关联问题吧，早知道你要问这个问题了，早已在你问第一个问题时，已经帮你做了最佳推荐： Start => Run => Perfmon => User Defined => right click on the right side blank space => New => Data Collector Set => type Name: PERFMON_BASE => Create manually(Advanced) => Next Create data logs => Performance counter => Event trace data => Next => Select counters from computer => 展开性能指标分类，比如：SQL Server:Buffer Manager => Page read/sec, page writes/sec等 => Add => OK Next => Root directory => Finish 性能监视器创建完毕后，最后一个步骤需要启动这个性能监视器，来抓取SQL Server性能指标。选择刚才创建的数据收集器 => 右键点击 => Start。 4.Trace文件关联性能监视器log文件 当菜鸟完成手动搜集Windows性能监视器以后，信心大增。再回过头来问G哥，哪知道G哥早已推荐他：“SQL Server Trace file与性能监视器log文件关联”。G哥是何等聪明绝顶啊。当SQL Trace文件与性能监视器log文件关联以后，画面为分为四个区域： 查询语句区域：查看和选择查询语句 性能指标做图区域：可以看到选中的查询语句对应的各项性能指标做图（性能指标做图区域中红色的竖线） 性能指标选择区域：性能指标选择区域选中或者取消相关的性能指标 查询语句显示区域：查看被选中的相关查询语句详情 5.手动分析Trace文件 菜鸟能够将SQL Server Trace文件与性能监视器log文件关联在一起分析，是巨大的进步啊。可是，他还是不满足于现状，觉得一个个去点击查询语句，太过于原始，效率很难提升，而且不方便过滤出自己关心的查询语句。比如过滤出CPU占用最高的TOP 5查询；I/O最高的TOP 5查询；执行最为频繁的查询语句TOP 5等。 于是菜鸟想到了将SQL Server Trace File文件通过系统函数将其读出来，存到一个表里面。这样，就可以利用数据库强大的筛选，过滤，聚合功能得到自己关心的查询语句了。 declare @trace_file_path sysname ; select @trace_file_path = N'C:\Temp\perfmon\XXXX.trc' ; SELECT * FROM sys.fn_trace_gettable(@trace_file_path, NULL) AS T 到目前为止，菜鸟已经找到了人生努力的方向，成为高富帅，迎娶白富美是指日可待了。可是菜鸟在分析性能的过程中逐渐意识到，由于查询语句或者存储过程的参数值是“乱七八糟”的，很难做有效的聚合统计。 6.自动化分析Trace文件 革命尚未成功，同志还需努力，到底如何实现自动化分析Trace文件呢？菜鸟又想到了G哥，G哥很豪爽并不加思索的说“用RML Utilities for SQL Server啊”。看来现在G哥已是菜鸟的救火队长了，度娘表示很受伤，羡慕滴妒恨。 6.1.RML Utilities功能介绍 RML（Replay Markup Language）Utilities是MS SQL Server产品支持服务团队内部开发使用的一个trace文件分析工具。支持SQL Server 2005，2008，2008R2，2012和SQL Server 2014。 主要的功能包括以下几个个方面： 分析最消耗SQL Server系统资源的应用和查询 去除参数干扰，统计汇总查询性能消耗 生成可视化报表，性能消耗大户一目了然 6.2.RML Utilities安装 首先从下面的地址下载对应的版本，分为X86的32位版和64位版： X86：[https://www.microsoft.com/en-us/download/details.aspx?id=8161] X64：[https://www.microsoft.com/en-us/download/details.aspx?id=4511] RML安装文件(RMLSetup_AMD64.msi)是基于Windows MSI的文件。因此安装过程你懂的，非常简单，在此不一一截屏说明安装步骤了。安装完毕后，RML的默认安装目录会在"C:Program FilesMicrosoft CorporationRMLUtils" 6.3.使用方法 打开RML Command：Start => All programs => RML Utilities for SQL Server => RML Cmd Prompt 执行如下命令： ReadTrace -I"C:\Temp\perfmon\XXX.trc" -o"C:\Temp\OUTPUT" -S"." -d"PerfAnalysis" -E -f Readtrace的参数是区分大小写的，并且输入文件和输出目录不能够在同一个目录下。详情参见Readtrace -?的参数描述，这条语句的参数说明： -I: 输入的Trace文件目录和文件名 -o: 日志文件输出目录 -S: 数据存放的数据库服务器 -d: 数据库名字 -E: Windows认证模式链接数据库 -f: 不用生成每一个会话和请求的详细RML输出文件 命令执行完毕后会自动化生成以下的分类报表： Performance OverviewPerformance Overview分类报表包括其他分类报表的入口，资源使用率的统计，性能总览的详细信息。 Application Name按照应用程序名称做分类统计，这个统计报表可以知道每个应用程序对SQL Server系统资源的消耗情况。利用这个报表，我们很轻松就可以找到资源使用的大户，针对性的采取必要的措施。 Unique Batches这个分类报表非常有价值，在这个报表中，我们非常轻松的就可以发现占用CPU，Run Duration，IO Read，IO Write TOP Batches语句块。这个为我们优化具体的SQL语句块提供了非常方便的统计汇总。 Interesting Events针对SQL Server数据库事件的统计分类报表。 Database ID按照数据库标识ID的分类报表，从这个报表，我们可以很容易发现哪个数据库的压力比较大，可以选择作为我们重点优化的数据库。 Unique Statements这个与Unique Batches分类统计报表类似，也是非常有价值的报表，只不过这个是针对特定语句的分类统计报表，而不是针对语句块，所以，这两个报表的分析方式非常类似。 这个报表分别从CPU，Duration，Reads和Writes四个角度统计出查询语句执行次数及所占百分比。当我们查看具体的执行语句的时候（点击处的执行语句），会打开下图中的Unique Statement Details页面。这个页面展示了相应查询语句非常详细的信息，包括：执行语句模版，按照CPU，Duration，Reads和Writes的统计汇总图展示，按照时间顺序的统计汇总表格，格式化后的查询语句。既然拿到TOP Unique Query语句，接下来的要做的事情就是花80%的时间和精力去优化这20%的TOP Query并加以改善到产品环境，这样我们SQL Server性能问题就可以解决了。 Data Lineage这个报表是Readtrace数据导入的日志信息统计，包含你使用的参数信息和RML的错误警告信息等。比如，这里就提示，我们的SQL Server Trace文件少了SP:StmtStarting事件的跟踪。 Login Name按照登录用户聚合的分类统计报表，从这报表我们可以很容易发现哪些用户是数据库系统资源的大户。 总结来看，RML Utilities for SQL Server是一款与SQL Profiler结合得非常好的自动化Trace文件分析工具。利用这个工具强大的统计汇总功能，使得我们可以非常容易从多角度，多视野，多维度来发现问题，分析问题，解决问题，真正做到工欲善其事必先利其器的效果。 7.写在最后 当菜鸟把这份心得呈现在老鸟面前的时候，老鸟简直惊呆了：“不错啊，来，给你十三个赞，每月一个赞”。 “每年不是十二个月吗？”，菜鸟疑惑的问道。 “多的一个是十三薪”，老鸟一边走着一边回答。留着菜鸟一个人在风中凌乱。

安装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 值：29082这样看的） 将HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\Last Counter的值替换成 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\004\Counter中的值即可。 无法连接到WMI 提供程序 请注意，你只能使用SQL Server 配置管理器来管理SQL Server 2005服务器 在连接数据库应该经常遇到的问题，尤其是对盗版的xp系统而言。 解决问题的方法：检查一下 windows下的system32 中是否有framedyn.dll这个系统文件，如果没有到system32 下的wbem文件中拷贝framedyn.dll到system32 目录下 本文转自 BruceAndLee 51CTO博客，原文链接：http://blog.51cto.com/leelei/297709，如需转载请自行联系原作者

  问题:对性能监视器计数器注册表值执行系统配置检查失败  解决方法:在注册表中的HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Perflib位置找到Last Counter和Last Help，他们的值分别为004和009相应的Counter最大值和Help最大值

今天给同事安装sql server2005的时候总是报一个错误：对性能监视器计数器注册表值执行系统配置检查失败，上网一查问题解决了方法如下： 在安装SQL2005系统时，有时会提示“对性能监视器计数器注册表值执行系统配置检查失败 ”的错误，处理方法如下： 开始->运行->regedit ，  定位到  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib        1，目录下有Last Counter 和 Last Help 两个键值。     Last Counter"=dword:00000ed4 (3214)     Last Help"=dword:00000ed5 (3215)     (注修改Last Counter 和 Last Help的值是,该项默认是16进制，而我们修改时则选10进制)     如果装中文版的  Last Counter值(即3214)必须等于以下注册表项中 Perflib\004 的      Counter 项的最大值(即最后一个值)，如下图         如果装中文版的  Last Help值(即3215)必须等于以下注册表项中 Perflib\004 的      Help 项的最大值(即最后一个值)，如下图      2，英文版和上面差不多，只是 Last Counter值 和 Last Help值，是在Perflib\009目录下面。       修改后关闭再安装了。 本文转自sucre03 51CTO博客，原文链接：http://blog.51cto.com/sucre/591879，如需转载请自行联系原作者

前言 本书通过“系统慢”为主题，介绍管理员如何使用Windows Server 2008操作系统内置工具监控操作系统的性能、如何使用专业管理软件Microsoft System Center Operations Manager 2007和Quest的Spotlight系列产品监控Active Directory、Exchange Server 2003、SQL Server数据库，通过SQL代码优化和SQL日志如何监控和管理数据库，如何集中管理服务器产生的日志事件。本书技术通用性强，可以将介绍的知识和方法应用到Windows其他服务器操作系统中，是管理员优化系统的得力帮手。 本书内容具有很强的实践性和指导性，本书的读者需要具有一定的网络知识和一定的水平，可以作为企事业、各单位信息部门参考用书，可以作为高级网络培训班的参考教材，也可以作为计算机网络专业毕业生在即将走向工作岗位以前的实习参考书。   内容提要 在部署Windows系统的网络中，任何一个服务器操作系统使用者都能够遇到同样一个问题，就是随着数据量的增加，累计运行时间越来越多时，系统速度越来越慢，对客户端用户的响应时间越来越迟钝，用户抱怨声四起。面对如此状况，管理员不知道到底是是服务器、存储、网络、数据库、软件（操作系统和应用系统）中哪个部件出现问题，还是由于硬件性能低下需要进行硬件设备升级。 本书以Windows Server 2008服务器操作系统为基础，通过对操作系统的监控，使读者知道服务器需要监控的内容，通过对CPU、内存、磁盘等性能计数器的理解，通晓制作系统稳定性基线的方法，这个基线可以作为衡量系统是否稳定的标准。当系统出现问题后，如何使用内置工具分析和调整系统性能，而不要听信别人善意的“谎言”——出现性能问题就要升级硬件设施。 其他部分以Microsoft System Center Operations Manager 2007（SCOM）和Quest的Spolight系列产品为基础，监控在网络环境中应用广泛的Active Directory、SQL Server数据库和Exchange Server，由于Windows产品存在许多共性，本书介绍的方法读者可以部署其他版本的Windows Server服务器操作系统中。其中重点介绍了对SQL Server数据库的监控和调整，通过对日志监控可以了解数据库中数据的变化，通过对SQL代码优化可以大幅度提高SQL Server的性能。需要注意的是，SQL Server是运行在Windows Server 操作系统之上的，监控SQL Server数据库的同时一定要监控操作系统。 SCOM中引入了对分布式操作系统监控方法，对Active Directory的监控就是一个很好的例子。本书通过对一个分布式应用程序实例的部署，让读者掌握自定义部署监控分布式应用程序的方法，了解SCOM监控应用程序的过程，以及监控部件之间的逻辑关系，将操作系统监控、端口监控、数据库监控、数据源监控集成到一个监控控制台的方法，读者可以根据自己网络状况，定制监控平台。 本书共分15章，内容涵盖Windows Server操作系统监控和常用应用系统监控，内容概要介绍如下。 第1章，系统监控概述，概要介绍为什么要监控系统，以及介绍根据监控的结果如何判断系统是否存在性能问题。第2章，监控系统资源，介绍Windows Server 2008中任务管理器和资源管理器的使用，资源管理器使用评估模式对当前系统进行综合评估，可以直观的了解当前系统状态。第3章，可靠性和性能监视器，介绍Windows Server 2008中性能监视器、可靠性监视器和数据收集器的使用，使用上述的三种监视器，可以创建性能基线，作为评估系统的基础依据。第4章，系统事件日志管理，介绍在Windows Server 2008中事件、事件关联任务，以及如何基于操作系统收集其他系统事件。第5章，系统资源管理器，介绍如何为应用程序或者服务分配系统资源，将有限的资源充分使用。第6章，监控安全审核策略，审核与事件相对应，如果不开启审核策略在系统中将不能产生日志，本章介绍如何启用审核策略。第7章，监控和调整Windows Server，介绍使用Spotlight on Windows监控Windows Server 2008操作系统，和最基本的性能调整。第8章，部署SCOM，介绍如何在网络环境中部署Microsoft System Center Operations Manager 2007，该软件是微软公司专业的监控系统性能软件，可以和微软知识库结合，为管理员提供对应的故障解决方案。第9章，监控Active Directory，引导读者通过SCOM和Spotlight on Active Directory软件监控Active Directory。第10章，监控Exchange Server 2003，介绍网络中如何部署SCOM监控Exchange Server。第11章，SQL Server数据库监控，引导读者通过SCOM和Spotlight on SQL Server软件监控SQL Server数据库。第12章，事件统一监控，介绍使用SCOM的收集审核服务收集服务器日志，统一管理。第13章，SCOM自定义监控任务，介绍使用SCOM部署端口监控、数据源监控、分布式应用程序监控、警报通知等常见任务，引导读者学会根据网络状况自定义部署监控任务。第14章，SQL Server代码优化，介绍通过SQL Server 2005数据库引擎优化顾问和Toad工具优化SQL代码，提高代码的执行效率，从而提高数据库系统的性能。第15章，SQL Server日志监控与管理，介绍使用Log Explorer工具监控和管理SQL Server数据库日志。 在这个日新月异的信息化时代，网络新技术、新应用不断涌现。为此，我们也将密切关注网络技术的发展和读者的需要，将更新、更实用的技术介绍给读者，将更好的产品和应用推荐给大家。   本文转自wangshujiang51CTO博客，原文链接：http://blog.51cto.com/wangshujiang/211855 ，如需转载请自行联系原作者

性能分析器事件选择对话框上有大量可供选择，现介绍工作中最常使用的事件。   1. Errors and Warnings: Attention 当用户意外地同SQL Server断开连接时，一般就会激发该事件。最常见的原因是客户库超时，而通常来说，一个30秒的计时器在提交查询时便启动了。如果查询超时，就立即发现，因此这个事件使用很频繁。   2. Errors and Warnings: Exception 和 Errors and Warnings: User Error Message 异常和用户错误信息一起出现，一般都一起跟踪这两个类。当出现用户异常时，这两个事件就会被激发。异常事件包含错误数、严重性和状态，而用户错误信息事件包含错误的实际文本。   3. Locks: Deadlock graph 和 Locks: Lock:Deadlock Chain 在SQL Server之前的版本，死锁只能通过Deadlock Chain事件识别出来。SQL Server 2005之后引入了更多可用的Deadlock graph事件，这个事件生成标准XML，性能分析器可以将其呈现为非常清晰的图形输出。   4. Locks: Lock:Acquired 、 Locks: Lock:Released 和 Locks: Lock:Escalation 主要在解决死锁的同时使用这些事件，使用户知道在一个事务期间SQL Server用了什么锁，以及这些锁被保持了多长时间。如果用户对SQL Server各种隔离级别的运转感兴趣，可以监视这些事件。使用这些事件时，要确保对特定的目标spid进行过滤，以免得到太多的信息而不方便处理。   5. Performance: Showplan XML Statistics Profile 该事件可以用来捕获用户正在服务器上进行性能分析的查询过的XML显示计划输出。这里实际上有一些不同的显示计划和XML显示计划事件类，这一个是最有用的，因为它包含了实际行数及其他统计数据，而这些有助于优化查询。   6. Security Audit（事件类别） 尽管这并不是一个事件类，但实际上是一个包含多个事件类的类别，由于它包含了许多有用的事件类，而这些事件类有助于监视服务器上出现的几乎所有安全相关的活动，因此，应当将其加入到这个列表中。它包含了许多信息，例如失败的登录尝试（“Audit Login Failed”事件类），对特定的表或其他对象的访问（“Audit Schema Object Access Event”事件类），甚至还有服务器启动时间（“Audit Server Starts And Stops”事件类）。这些事件类的绝大部分都是为SQL Server的内置服务器审核跟踪而设计的。   7. Security Audit: Audit Login 和 Security Audit: Audit Logout 将这两个事件从整体的安全审核类别中挑选出来，因为这两个事件每天都会用到，尤其是在做性能调校时十分有用。通过监视这两个事件及存储过程和T-SQL类别中的各种查询事件，用户可以更方便地在单个会话的基础上积聚信息。   提示：得益于SQL Server 2005 SP2中的一个改进，连聚集起来的登录和登出也可以出发这些事件，使得它们比以前更加有用。要检测被激发的事件是否基于一个汇集连接，可以查看EventSubClass列的值是否为2。   8. Stored Procedures: RPC:Starting 和 Stored Procedures: RPC:Completed 当一个客户应用程序执行一个远程过程调用时（RPC：通常是一个带参数的查询或存储过程调用，具体是哪个取决于使用的连接库），这些事件就会被激发。   9. TSQL: SQL:BatchStarting 和 TSQL: SQL:BatchCompleted 当一个客户应用程序执行一个ad hoc批处理时，这些事件就会被激发。结合RPC事件类使用这些事件可以允许用户捕捉到外部调用程序提交给服务器的所有请求。“SQL:BatchCompleted”事件类和相应的“RPC:Completed”事件类都填充信息至4个关键的列：CPU、Reads、Writes和Duration。   10. Stored Procedures: SP:StmtStarting 和 Stored Procedures: SP:StmtCompleted 在一个复杂的充满了流程控制语句的存储过程中，有时很难确定到底选择了哪条访问路径。每次执行一个存储过程中的一条语句时，这些事件就会被激发，为用户显示发生事件的全景。这些事件可能会生成极其大量的数据。因此，最好仅在已经过滤了该跟踪之后再使用这些事件，这种过滤可通过一个正在跟踪的给定spid或一个特定的存储过程名称或对象ID（相应地使用ObjectName或ObjectId列）来完成。   11. Stored Procedures: SP:Recompile 通过分析认为存储过程重编译意味着一个潜在的SQL Server性能故障。SQL Server包含了一个帮助跟踪计数器（SQL Server: SQL统计值: SQL重编译/秒），如果发现该计数器的值居高不下，就可以考虑使用这个事件类来进行性能分析，以便确定到底是哪个存储过程引起了故障。   12. Stored Procedures: SP:Starting 每当调用一个存储过程或函数时，该事件类就会被激发，无论是客户直接调用还是被其他的存储过程或函数嵌套调用。由于该事件类不填充信息至读、写和CPU列，因此它对性能调校并没有太大的用户，但是也有价值。经常使用这个类来获取给定时间间隔内一个特定存储过程被调用的次数统计，也可以用在存储过程嗲用被大量嵌套的情况下，并且需要明确确定哪些序列调用导致了执行一个特定的存储过程。   13. Transactions: SQL Transaction 这个事件可以用来监视事务的启动、提交和回滚。通过查看EventSubClass列可以确定事务出于何种状态，0、1、2分别代表事务的启动、提交和回滚。由于每次数据修改都会占用一个事务，因此这个事件可能会在一台忙碌的服务器上造成大量待返回的数据。如果可能，要确保基于正在跟踪的一个特定spid来过滤跟踪。   14. User configurable（事件类别） 该事件类别包含了10个事件，命名从用户配置：0一直到用户配置：9。这些事件可以被有足够ALTER TRACE访问权限的用户或模块激发，且允许跟踪用户数据。 本文转自UltraSQL51CTO博客，原文链接：http://blog.51cto.com/ultrasql/1588738 ，如需转载请自行联系原作者

概览: 数据库性能问题故障排除 检查硬件原因 使用 PerfMon 跟踪数据库瓶颈 评估查询性能 解决数据库系统的性能问题可能是一项艰巨的任务。了解如何找到问题很重要，但是了解系统对特定请求作出特定反应的原因更加重要。影响数据库服务器上的 CPU 利用率 的因素有很多：SQL 语句的编译和重新编译、缺少索引、多线程操作、磁盘瓶颈、内存瓶颈、日常维护以及抽取、转换和装载 (ETL) 活动和其他因素。利用 CPU 本身并不是一件坏事情，执行任务是 CPU 的职责所在。CPU 利用率正常的关键是确保 CPU 处理您需要它处理的任务，而不是将循环浪费在不良优化的代码或缓慢的硬件上。 达到同一目的的两种途径 概括来讲，有两种途径可以确定 CPU 的性能问题。第一种途径是检查系统的硬件性能，这种做法有助于继续确定使用第二种途径 — 检查服务器的查询效率时从何处入手。第二种途径在确定 SQL Server™ 性能问题时通常更有效。然而，除非您确切知道查询性能问题的具体所在，否则，应该始终从系统性能评估开始着手。最后，通常是这两种途径齐头并进。让我们先了解一些基础知识，以便我们研究这两种途径。 了解基础知识 超线程 超线程影响 SQL Server 的方式使超线程成为一个非常值得讨论的主题。超线程实际上代表每个物理处理器的两个操作系统逻辑处理器。超线程实质上利用物理处理器上的闲置时间，以便每个处理器得到更充分的利用。Intel 网站 (intel.com/technology/platform-technology/hyper-threading/index.htm) 对超线程的工作原理进行了更为全面的介绍。 对于 SQL Server 系统，DBMS 实际上处理自己的极其有效的操作系统队列和线程，因此，超线程仅在 CPU 利用率已经很高、系统上的物理 CPU 超载的情况下使用。当 SQL Server 在多个计划程序上对执行任务请求进行排队时，实际上操作系统必须在物理处理器上来回切换线程的上下文，以满足不断发出的请求，即使同一物理处理器上存在两个逻辑处理器也不例外。如果每个物理处理器的 Context Switches/sec 高于 5000，我们强烈建议您考虑关闭系统上的超线程并重新测试性能。 在 SQL Server 上出现高 CPU 利用率时应用程序极少能有效地使用超线程。在生产系统上实施更改之前，必须在超线程启动和关闭这两种情况下针对 SQL Server 测试应用程序。 高端双核处理器肯定会优于计算机中的 RAM，而后者又比附加的存储设备快。一个好的 CPU 可以处理的吞吐量大约是当前顶尖 DDR2 内存的六倍，大约是顶尖 DDR3 内存的两倍。典型内存吞吐量是最快的光纤信道驱动器的 10 倍以上。这样，硬盘只能执行次数有限的 IOPS（每秒的输入/输出操作），该值完全受驱动器每秒可以执行的寻道次数限制。公平地讲，仅使用一个存储驱动器处理企业数据库系统的所有存储需求的情况并不常见。目前，大多数组织在企业数据库服务器或更大的 RAID 组（消除或最大程度地减小磁盘 I/O 处理器问题）上利用存储区域网络 (SAN)。最重要的是，无论您的组织规模如何，磁盘瓶颈和内存瓶颈都会影响处理器的性能。 由于 I/O 速度不同，从磁盘中检索数据的开销会远远大于从内存中检索数据的开销。SQL Server 中的一个数据页为 8KB。SQL Server 中的一个扩展由八个 8KB 页组成，即该扩展的大小等于 64KB。了解这一点非常重要，因为当 SQL Server 从磁盘请求特定数据页时，它不仅仅检索该数据页，还会检索该数据页驻留的整个扩展。实际上，存在各种使 SQL Server 更经济高效的因素，但是我在此不再详细阐述。在性能最佳的状态下，从缓冲池中提取已经缓存的数据页花费的时间应该不到半毫秒；在最佳环境下，从磁盘检索单个扩展会花费 2 至 4 毫秒的时间。通常，我认为从性能良好、状态正常的磁盘子系统读取数据应花费 4 至 10 毫秒。从内存检索数据页通常比从磁盘提取数据快 4 至 20 倍。 当 SQL Server 请求某个数据页时，它会在从磁盘子系统上查找此数据页之前检查内存中的缓冲区高速缓存。如果该数据页位于缓冲池中，则处理器将检索数据，然后执行请求的任务。这称为软页面错误。软页面错误是 SQL Server 的理想选择，因为作为请求的一部分检索的数据必须位于缓冲区高速缓存中才能使用。在缓冲区高速缓存中找不到的数据页必须从服务器的磁盘子系统中检索。当操作系统必须从磁盘检索数据页时，这称为硬页面错误。 使内存性能、磁盘性能和 CPU 性能相互关联时，一个通用标准可以帮助我们看清所有问题：吞吐量。从不太专业的角度而言，吞吐量是对可以填满有限管道的数据量的测量结果。 途径 1：系统性能 实际上，用于确定服务器是否遇到 CPU 瓶颈的方法只有几种，而且导致高 CPU 利用率的潜在因素并不多。其中的部分问题可以使用 PerfMon 或类似的系统监视工具进行跟踪，而其他问题可以使用 SQL Profiler 或类似的工具进行跟踪。另一种方法是通过查询分析器或 SQL Server Management Studio (SSMS) 使用 SQL 命令。 评估系统性能时我使用的基本原理是“先广泛开展调查，然后集中深入研究”。显然，只有确定问题范围之后，才能集中进行深入研究。使用像 PerfMon 这样的工具评估整体 CPU 利用率之后，您可以使用该工具查看两个非常简单、易于理解的性能计数器。 最熟悉的性能计数器之一是 % Processor Time；在 PerfMon 中，打开“添加计数器”窗口时就会突出显示该计数器。% Processor Time 是处理器忙于执行任务的时间量。当大多数高峰操作时间此值为 80％或更高时，通常认为处理器的利用率很高。即使服务器的利用率不到 80％，通常您也会看到峰值高达 100％，您应该会预见到这种情况。 您应该查看的另一个计数器是 Processor Queue Length，在 PerfMon 中的“系统性能”对象下可以找到该计数器。Processor Queue Length 显示正在等待在 CPU 上执行任务的线程数。SQL Server 通过数据库引擎中的计划程序管理其任务，在计划程序中对请求进行排队和处理。由于 SQL Server 管理自己的任务，对于每个逻辑处理器它将只利用单个 CPU 线程。这意味着在专用于 SQL Server 的系统上，正在处理器队列中等待执行任务的线程数应该最少。通常，在专用的 SQL Server 上，线程数不应超过物理处理器数的五倍，但是我认为超过两倍就会出现问题。在 DBMS 与其他应用程序共享系统的服务器上，除了此计数器外，还需要查看 % Processor Time 和 Context Switches/sec 性能计数器（稍后我将简要介绍一下上下文切换），从而确定是否需要将其他应用程序或 DBMS 移至其他服务器。 了解处理器队列和高 CPU 利用率后，下面我们查看 SQL Server:SQL Statistic 性能对象下的 Compilations/sec 和 Re-Compilations/sec 计数器（请参阅图 1）。编译和重新编译查询计划增加了系统的 CPU 利用率。您应该可以看到 Re-Compilations 的值接近于零，但是观察系统内的趋势可以确定服务器的通常行为以及正常的编译次数。不可能始终避免重新编译，但是可优化查询和存储过程以在最大程度上减少重新编译，并重新使用查询计划。通过 Batch Requests/sec（也可以在 SQL Server:SQL Statistic 性能对象中找到）将这些值与进入系统的实际 SQL 语句进行比较。如果每秒的编译和重新编译在进入系统的批请求中占很高比例，则说明应该检查这一方面。在某些情况下，SQL 开发人员也许并不了解他们的代码对这些类型的系统资源问题有什么影响以及为什么会有影响。在下文中，我将提供一些参考资料，帮助您在最大程度上减少这种行为。 图 1 选择用于监视的计数器 (单击该图像获得较大视图) 在 PerfMon 中，请检查名为 Context Switches/sec 的性能计数器（参阅图 2）。此计数器显示为了为其他等待线程执行任务必须从操作系统计划程序（而非 SQL 计划程序）中取出线程的次数。对于与其他应用程序（如 IIS）或其他供应商应用程序服务器组件共享的数据库系统，上下文切换可能更加频繁。我使用的 Context Switches/sec 阈值大约是服务器中处理器数量的 5000 倍。在启用了超线程并且对 CPU 的利用率达到中高程度的系统上，该阈值还可更高。如果 CPU 利用率和上下文切换经常同时超出各自的阈值，这就表明出现了 CPU 瓶颈。如果经常发生这种情况，并且您的系统已过时，则应该开始计划购买更多或处理速度更快的 CPU。有关详细信息，请参阅侧栏上的“超线程”。  Figure 2 需要注意的性能计数器 性能计数器 计数器对象 阈值 注释 % Processor Time 处理器 > 80% 潜在因素包括内存不足、低查询计划重用率和未经优化的查询。 Context Switches/sec 系统 > 5000 x 处理器数 潜在因素包括服务器上的其他应用程序、在同一服务器上运行了多个 SQL Server 实例和超线程已打开。 Processor Queue Length 系统 > 5 x 处理器数 潜在因素包括服务器上的其他应用程序、频繁的编译或重新编译以及在同一服务器上运行了多个 SQL Server 实例。 Compilations/sec SQLServer:SQL Statistics 趋势 与 Batch Requests/sec 进行比较。 Re-Compilations/sec SQLServer:SQL Statistics 趋势 与 Batch Requests/sec 进行比较。 Batch Request/sec SQLServer:SQL Statistics 趋势 与每秒编译和重新编译数进行比较。 Page Life Expectancy SQLServer:Buffer Manager < 300 内存不足的潜在因素。 Lazy Writes/sec SQLServer:Buffer Manager 趋势 大量数据缓存刷新或内存不足的潜在因素。 Checkpoints/sec SQLServer:Buffer Manager 趋势 根据 PLE 和 Lazy Writes/sec 评估检查点。 Cache Hit Ratio:SQL Plans SQLServer:Plan Cache < 70% 表示计划重用率低。 Buffer Cache Hit Ratio SQLServer:Buffer Manager < 97% 内存不足的潜在因素。         当 CPU 的利用率很高时，还需要监视 SQL Server Lazy Writer（在 SQL Server 2000 中）或 Resource Monitor（在 SQL Server 2005 中）。通过称为 Resource Monitor 的资源线程刷新缓冲区和过程缓存可增加 CPU 时间。Resource Monitor 是一个 SQL Server 进程，它确定要保留的页以及需要从缓冲池刷新到磁盘的页。缓冲区和过程缓存中的每一个页最初都分配了成本，成本代表将该页放置到缓存时所耗费的资源。 Resource Monitor 每次扫描该页，该成本值都会减少。当请求要求提供缓存空间时，系统会根据与每个页关联的成本刷新这些页；值最低的页将首先被刷新。Resource Monitor 的活动可通过 PerfMon 中 SQL Server:Buffer Manager 对象下的 Lazy Writes/sec 性能计数器进行跟踪。您应该跟踪查看该值的趋势，以确定系统上的典型阈值。该计数器通常与 Page Life Expectancy 和 Checkpoints/sec 计数器一起查看，以确定是否内存不足。 Page Life Expectancy (PLE) 计数器帮助确定是否内存不足。PLE 计数器显示数据页在缓冲区高速缓存中停留的时间。行业中该计数器的可接受阈值为 300 秒。如果在很长一段时间内显示的值平均小于 300 秒，则表明从内存中刷新数据页的频率过高。如果出现这种情况，将导致 Resource Monitor 负载加重，从而导致处理器的活动增多。应该将 PLE 计数器和 Checkpoints Pages/sec 计数器一起进行评估。在系统中出现检查点时，缓冲区高速缓存中的脏数据页被刷新到磁盘，从而导致 PLE 值下降。Resource Monitor 进程是真正将这些页刷新到磁盘的机制，所以在出现这些检查点期间，您应该还会看到 Lazy Writes/sec 值增加。如果完成检查点后 PLE 值立即增加，您可以忽略这种短暂现象。另一方面，如果发现经常低于 PLE 阈值，则此时非常适合使用多出的内存缓解您的问题，同时将一些资源释放回 CPU。所有这些计数器都可在 SQL Server:Buffer Manager 性能对象中找到。 途径 2：查询性能 SP 跟踪 跟踪 SQL Server 应用程序时，应该先熟悉用于跟踪的存储过程。使用 GUI 界面 (SQL Server Profiler) 进行跟踪可将系统负载增加 15％ 到 25％。如果可以在跟踪过程中利用存储过程，则对系统产生的负载可减少大约一半。 当我知道系统在某个地方发生瓶颈，并且想确定哪些 SQL 语句导致服务器出现问题时，我运行以下查询。这个查询帮助我了解各个语句及其当前正在使用的资源，以及需要对其进行检查以改进性能的语句。有关 SQL 跟踪的详细信息，请参阅msdn2.microsoft.com/ms191006.aspx。 复制代码 SELECT substring(text,qs.statement_start_offset/2 ,(CASE WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2 ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) ,qs.plan_generation_num as recompiles ,qs.execution_count as execution_count ,qs.total_elapsed_time - qs.total_worker_time as total_wait_time ,qs.total_worker_time as cpu_time ,qs.total_logical_reads as reads ,qs.total_logical_writes as writes FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st LEFT JOIN sys.dm_exec_requests r ON qs.sql_handle = r.sql_handle ORDER BY 3 DESC 向 SQL Server 提交新查询后，会对查询计划进行评估、优化、编译，并将其放置到过程缓存中。每次向服务器提交查询，都会检查过程缓存以尝试使查询计划与请求匹配。如果找不到，则 SQL Server 将为其创建新计划，此操作可能会造成很大的开销。 T-SQL CPU 优化应注意以下几个方面： 查询计划重用 减少编译和重新编译 排序操作 不适当联接 缺少索引 表/索引扫描 SELECT 和 WHERE 子句中的函数使用情况 多线程操作 我们来更详细地了解一下。SQL Server 经常从内存和磁盘中提取数据，所以仅使用单一数据页的情况很少见。在大多数情况下，应用程序的多个部分会对一项记录进行操作、运行多个较小的查询，或者联接表以提供相关数据的完整视图。在 OLAP 环境中，应用程序可能会从一个或两个表中提取成千上百行，以便您合并、累积或汇总数据以生成地区销售报表。在上述情况下，如果数据存在于内存中，返回数据的速度可以毫秒计算，但是如果从磁盘而非 RAM 上检索相同数据，就要以分钟计算。 第一个示例是存在大量事务的情况，并且计划重用情况取决于应用程序。低计划重用造成对 SQL 语句的大量编译，从而导致大量 CPU 处理开销。在第二个示例中，由于必须经常从缓冲区高速缓存刷新数据，以便为大量新数据页留出空间，所以大量使用系统资源可导致系统的 CPU 过度活跃。 假设存在一个高事务性的系统，在该系统中，为了检索装运箱的相关信息，下面显示的 SQL 语句在 15 分钟内执行了 2000 次。如果没有查询计划重用，可能每个语句大约 450 毫秒就要执行一次。如果在第一次执行后使用相同的查询计划，则每个后继查询可以在大约 2 毫秒内完成，从而使整体执行时间减少到大约 5 秒钟。 复制代码 USE SHIPPING_DIST01; SELECT Container_ID ,Carton_ID ,Product_ID ,ProductCount ,ModifiedDate FROM Container.Carton WHERE Carton_ID = 982350144; 查询计划重用对于实现存在大量事务的系统的最佳性能至关重要，并且大多数情况下是通过参数化查询或存储过程实现的。以下是有关查询计划重用信息的一些有用资源： SQL Server 2005 中的批处理编译、重新编译和计划缓存问题 (microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx) 优化 SQL Server 存储过程以避免重新编译 (sql-server-performance.com/rd_optimizing_sp_recompiles.asp) SQL Server 2000 中的查询重新编译 (msdn2.microsoft.com/aa902682.aspx) SQL Server 2005 动态管理视图 (DMV) 中包含大量信息，很有帮助。当 CPU 利用率很高时，我使用几个 DMV 帮助我确定对 CPU 的利用是否合理。 我查看的一个 DMV 是 sys.dm_os_wait_stats，它用于为 DBA 提供一种确定 SQL Server 使用的每种资源类型或函数的方法，并测量由于该资源导致的系统等待时间。此 DMV 中的计数器具有累积性。这意味着为了清楚地了解哪些资源会影响系统的不同领域，在查看任何未解决的问题的数据之后，首先您必须发出 DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) 命令以重置所有的计数器。Sys.dm_os_wait_stats DMV 与 SQL Server 2000 中的数据库一致性检查命令 DBCC SQLPERF(WAITSTATS) 等效。您可以在 msdn2.microsoft.com/ ms179984.aspx 上的 SQL Server 联机丛书中找到有关不同等待类型的更多信息。 应该了解，即使在一切都以最优方式运行时，系统出现等待也是很平常的。您只需确定等待是否受 CPU 瓶颈影响。信号等待相对于全部等待时间来说，应该尽可能短。特殊资源等待处理器资源的时间可以直接由总等待时间减去信号等待时间来确定；此值不应该大于总等待时间的大约 20％。 sys.dm_exec_sessions DMV 显示 SQL Server 上所有打开的会话。此 DMV 提供了每个会话的性能以及每个会话启动后执行的所有工作的高级视图。这包括会话等待的总时间、CPU 使用总量、内存使用情况以及读取和写入计数。该 DMV 还将为您提供登录、登录时间、主机和会话最后一次发出 SQL Server 请求的时间。 使用 sys.dm_exec_sessions DMV，您能够确定的只是活动会话，因此，如果看到 CPU 使用率很高，应该先查看此视图。首先查看具有高 CPU 计数的会话。确定一直执行此任务的应用程序和用户，然后开始对其深入了解。将 sys.dm_exec_sessions 与 sys.dm_exec_requests DMV 配对使用可以提供通过 sp_who 和 sp_who2 存储过程获得的大量信息。如果通过 sql_handle 列将此数据与 sys.exec_sql_text 动态管理函数 (DMF) 结合在一起，那么可以获得会话当前运行的查询。图 3中的代码段显示了如何同时提取此数据以帮助确定某个服务器上当前的情形。  Figure 3 确定服务器活动 复制代码 SELECT es.session_id ,es.program_name ,es.login_name ,es.nt_user_name ,es.login_time ,es.host_name ,es.cpu_time ,es.total_scheduled_time ,es.total_elapsed_time ,es.memory_usage ,es.logical_reads ,es.reads ,es.writes ,st.text FROM sys.dm_exec_sessions es LEFT JOIN sys.dm_exec_connections ec ON es.session_id = ec.session_id LEFT JOIN sys.dm_exec_requests er ON es.session_id = er.session_id OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st WHERE es.session_id > 50 -- < 50 system sessions ORDER BY es.cpu_time DESC 我发现此语句有助于确定需要重点了解哪些应用程序。当将一个应用程序的各个会话的 CPU、内存、读取、写入和逻辑读取进行比较，确定 CPU 资源要远远高于正在使用的其他资源时，我开始重点关注这些 SQL 语句。 为了完整跟踪应用程序的 SQL 语句，我使用 SQL Server 跟踪。可以通过 SQL Server Profiler 工具或跟踪系统存储过程实现上述目的，以帮助评估正在进行的操作。（有关本主题的详细信息，请参阅侧栏“SP 跟踪”。）对于具有高 CPU 使用率的语句，以及哈希和分类警告、缓存未命中以及其他红色标志，应查看探查器。这有助于您把范围缩小到特定的 SQL 语句或产生高资源使用率的特定时间段。探查器能够跟踪 SQL 语句文本、执行计划、CPU 使用率、内存使用率、逻辑读取、写入、查询计划缓存、重新编译、对来自缓存的查询计划的拒绝、缓存未命中、表和索引扫描、缺少的统计信息以及许多其他事件。 通过 sp_trace 存储过程或 SQL Server Profiler 收集数据后，我通常会使用一个数据库，该数据库有两种填充方式：事后使用跟踪数据填充；将跟踪设置为写入数据库。事后填充数据库可以通过名为 fn_trace_getinfo 的 SQL Server 系统函数来完成。此方法的优点在于我可以通过多种方式查询和分类数据来查看哪些 SQL 语句使用的 CPU 最多或读取的次数最多、计算发生重新编译的次数等。以下示例说明如何使用此函数加载具有探查器跟踪文件的表。Default 指定将按照创建顺序加载此跟踪的所有跟踪文件： 复制代码 SELECT * INTO trc_20070401 FROM fn_trace_gettable('S:\Mountpoints\TRC_20070401_1.trc', default); GO 总结 您可以看到，高的 CPU 使用率并不一定表示出现了 CPU 瓶颈。高 CPU 使用率也可能是大量其他应用程序或硬件出现瓶颈造成的。尽管其他计数器看起来运行状况良好，但确定 CPU 使用率过高后，您可以在系统内查找原因，然后找出解决方案（购买更多的 CPU 或优化 SQL 代码）。不管怎样做，都不要放弃！使用本文中提供的提示，再进行一点实践和研究，在 SQL Server 下优化 CPU 使用率这一执行计划是完全可以实现的。 分类: SqlServer 本文转自快乐就好博客园博客，原文链接：http://www.cnblogs.com/happyday56/archive/2009/08/21/1551157.html，如需转载请自行联系原作者

今天在安装SQL Server 2005时，出现“性能监视器计数器要求”错误，因为以前出现过这种错误，得到了解决。今天又又出现这种错误，但并不是很清楚当时的解决办法，所以这次把解决方法记录下来，供自己以后参考，也希望对大家有帮助。　　 错误原因　　 造成这种错误的原因在于Microsoft SQL Server 安装程序中的安装配置检查器 (SCC)在安装SQL Server前会验证计数器注册表项的值。如果 SCC 无法验证现有的注册表项，或 SCC 无法运行 lodctr.exe 系统程序，则 SCC 检查会失败，致使安装受阻。　　解决办法(手动设置计数器注册表项的增量)　　ü　 解决办法一　　1.　　 在Windows Server 2003或者Windows Xp中，依次单击“开始”，“运行”，然后在“打开”中输入“regedit”单击“确定”打开注册表，在Windows 2000中输入“regedt32”打开注册表。　　2.　　 定位到注册表项：[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsNTCurrentVersionPerflib]"Last Counter"=dword:00000ed4 (5276)"LastHelp"=dword:00000ed5 (5277)　　3.　　 第2步中的“Last Counter”值 (5276) 必须与以下注册表项中“Perflib09”的“Counter”项的最大值匹配，并且第2步中的“Last Help”值 (5277) 必须与以下注册表项中“Perflib09”的“Help”项的最大值匹配。（注意：Perflib中有两个子项004和009，004代表中文，009代表英文。）[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionPerflib09]　　“Last Counter”和“Last Help”值是由 Windows 动态分配的；这两个值会因计算机的不同而不同。　　4.　　 如果完成第3步还无法安装的话，可修改“Perflib”项中的“Last Counter”和“Last Help”值的值。右键单击“Last Counter”或“Last Help”，单击“修改”，再单击“Base = "Decimal"”，在“值数据”中设置值，再单击“确定”。如有必要，对另一个项重复以上过程，然后关闭注册表编辑器。　　ü　 解决办法二　　1.　　 运行cmd，然后执行unlodctr w3svc  unlodctr msftpsvc  unlodctr asp unlodctr inetinfo　　以上是将四个计数器都删除　　2.　　 以下重新安装计数器lodctr w3ctrs.inilodctr ftpctrs.inilodctr axperf.inilodctr infoctrs.ini　　 一般情况下第一种方法就可以解决问题，第一种方法中更改的值只需比当前的值大就可以，没有限制。第二种方法是备用方法。 本文转自左正博客园博客，原文链接：http://www.cnblogs.com/soundcode/archive/2010/12/26/1917466.html，如需转载请自行联系原作者