• ----:)欢迎访问源码网(:----
    • 首页
    • 博客
    • 学院
    • 下载
    • 论坛
    • 影视
    • 发布源码
    • RSS
    • ITPig
    • 笑话网
    • 百家姓
    • 繁體中文

源码网 - 中国第一源码门户
选择镜像:网通镜像 - 电信主站
  • 首 页
  • 新闻动态
  • 网站运营
  • 网页制作
  • WEB开发
  • 编程开发
  • 图像媒体
  • 操作系统
  • 数据库
  • 服务器
热门搜索 优化 SEO 故事 cms IIS7 MySQL 个人 AdSense 主题推广 | 文章搜索: 高级搜索
会员登录/控制面版您的位置: 学院首页 >> 数据库 >> MSSQL >> 详细内容
 

推荐文章

  • SQL数据库的备份、压缩与SQL数据库数据处理的方法
  • 压缩SQL数据库
 
 

热点文章

  • 安装SQL Server 2005实例环境图解
  • SQL数据库的备份、压缩与SQL数据库数据处理的方法
  • SQL SERVER 2005数据库镜像
  • SQL数据库还原出现错误112(磁盘空间不足)的解决办法
  • Server 2005性能排错
  • 在SQL Server中的关系型数据仓库分区策略
  • 如何使用SQL Server 2000中的XML功能
  • 压缩SQL数据库
  • SQL Server 2000中的SQL语言简介
  • SQLServer删除日志方法
  • SQL精妙语句
  • SQL Server 2000中的SQL语言简介(一)
 
 

相关文章

  • “农村包围城市”SQL Server 2005“绸缪”企业级市场
  • 修改SQL Server 2005执行环境
  • SQL Server 2005中处理表分区问题
  • SQL Server 2005中Tempdb变化分析
  • SQL Server 2005的XML支持机制和安全机制
  • SQL SERVER 2005数据库镜像
  • 安装SQL Server 2005实例环境图解
  • SQL Server 2005与DB2 8.2之对比
  • 了解SQL Server 2005五个有用的动态管理对象
  • SQL Server 2005:你应该知道的13件事情
  • 用SQL Server 2005的三个理由
  • SQL Server 2005密码安全追踪与存储
 
 

百度搜索

 
 

SQL Server 2005性能测试之CPU篇

  • 阅览次数:
  • 文章来源: a hear
  • 原文作者: 不详
  • 整理日期: 2007-04-06
  • 发表评论
  • 字体大小:
  • 小
  • 中
  • 大

如果在没有额外复杂条件下突然出现CPU瓶颈,有可能是因为没有优化查询,错误的数据库配置,或者是数据库设计上的原因和硬件资源不足引起。在决定采用增加CPU数量或者使用更快速的CPU之前,应该先检查消耗CPU资源最多的操作是否能够被优化。

如果发现性能计数器Processor: % Processor Time的值很高,每一个CPU的% Processor Time都超过80%时,可视为出现CPU瓶颈。也可以通过视图sys.dm_os_schedulers监视SQL Server的进程调度(schedulers)来确认可执行的任务是否为非零值。非零值表示任务被迫等待时间片来运行,如果这个数值非常高,说明存在CPU瓶颈。

Select scheduler_id,current_task_count,

runnable_task_count from sys.dm_os_schedulers where scheduler_id<255

下面的查询将给出一个较高层的视图来说明当前被缓存的消耗CPU资源最多的批处理或者过程。查询通过相同查询句柄的所有语句合计CPU的消耗情况。

Select top 50 sum (qs_total_worker_time) as total_cpu_time,sum(qs.execution_count)

as total_execution_count, count(*) as number_of_statements,

qs.plan_handle from sys.dm_exec_query_stats qs group by qs.plan_handle order

by sum(qs.total_worker_time) desc

过多的compilation和recompilation



在批处理或者远程过程调用(RPC)提交到服务器执行之前,系统会检查查询计划的有效性和正确性。如果在检查过程中出现了失败的情况,这些批处理可能会被再次编译来产生新的查询计划。这样的编译被称为重编译(recompilations)。这些重编译一般必须确定正确性且通常在服务器认定在潜在数据发生变化后存在可能被优厚的查询计划时执行。编译的特性是CPU敏感的操作,因此过分的重编译可以导致CPU性能问题。

在SQL Server 2000中,当SQL Server重新编译一个存储过程时,整个存储过程都会被重编译,而不只是触发重编译的语句。SQL Server 2005引入了一种语句级别重编的存储过程。当SQL Server 2005重新编译存储过程时,只有引起重编译的语句才会被编译而不是整个过程。这就减少了CPU带宽并且减少了资源锁出现的可能,例如:COMPLIE locks. 重编译可以由于很多不同的原因造成,如:

◆架构变化

◆统计变化

◆延期编译

◆SET选项变化

◆临时表变化

◆存储过程以RECOMPLIE选项建立。

检测

使用System Monitor 或者 SQL Server Profiler来检测过多的编译和重编译。

System Monitor



SQL Statistics对象提供计数器来监视编译和发送到SQL Server实例的请求类型。必须通过监视查询编译和重编译的数量结合接收到的批处理数量来找出高CPU消耗是否是由编译引起。理想情况下,SQL Recompilations/sec和Batch Requests/sec的比率应该应该非常低,除非用户提交的是即席查询。

以下是关键数据计数器:

◆SQL Server: SQL Statistics: Batch Requests/sec

◆SQL Server: SQL Statistics: SQL Compilations/sec

◆SQL Server: SQL Statistics: SQL Recompilations/sec

SQL Trace

如果性能计数器显示非常大的重编译数量,重编译可能正在造成高CPU消耗。接下来需要需要利用SQL Profiler纪录的trace来找出当时被重新编译的存储过程。SQL Server Profiler trace可以给出这些信息连同重编译的原因。可以使用事件来获取这些信息。

SP: Recompile / SQL: StmtRecompile. The SP:Recompile and the SQL:StmtRecompile事件类显示哪些存储过程和语句曾经被重新编译过。当编译一个存储过程时,为存储过程和每一个被编译的语句生成事件。然而,当一个存储过程被重新编译时,只有引起重新编译的语句才会被生成一个事件(不同于SQL Server 2000中的整体存储过程编译)。

SP:Recompile事件类中的重要的数据列如下所示:

◆Event Class

◆EventSubClass

◆ObjectID(表示包含这个语句的存储过程)

◆SPID

◆Start Time

◆SqlHandle

◆TextData


[1] [2]

上一篇:比AcdSee功能还强大的图片处理、编辑软件,推荐下载!
下一篇:ASP上传漏洞防范
  • 网友评论:
  • 查看所有评论
  • 我要发表评论
您的网名:
留言主题:
你要发表的内容:

 

关于本站 | 广告联系 | 版权声明 | 网站地图 | 发布软件 | 帮助中心 | 源码论坛

Copyright © 2005-2007 CodePub.Com  程序支持:木翼  滇ICP备05005971号