SQL Server 2005性能排错(1)
目录
简介
目标
方法
资源瓶颈
解决资源瓶颈的工具
CPU 瓶颈
过多的编译和重编译
检测
解决
效率低的查询计划
检测
解决
内部查询的并行
检测
解决
拙劣游标使用
检测
解决
内存瓶颈
背景
虚拟地址空间和物理内存
Windows地址扩展和SQL Server
内存压力
检测内存压力
外部物理内存压力
外部虚拟内存压力
内部物理内存压力
高速缓存和内存压力
Ring buffers
内部虚拟内存压力
一般的内存错误排错步骤
内存错误
I/O 瓶颈
解决
Tempdb
监视tempdb空间
磁盘空间问题排错
用户对象
版本存储
内部对象
过多的DLL和分配操作
解决
运行缓慢的查询
阻塞
识别长时间的阻塞
通过sys.dm_db_index_operational_stats查看阻塞的每个对象
使用SQL waits阻塞对整体性能的影响
监视索引的使用
总结
附录A: DBCC MEMORYSTATUS 描述
附录B: 阻塞脚本
分析操作的索引统计
等待状态
简介
很多客户偶尔会遇到SQL Server 数据库性能下降。原因可能涉及从不良好的数据库设计到不正确的负载配置。作为一个管理员，你应该预先阻止或最小化问题，并当问题发生时，诊断原因并尽可能的做出正确的操作来解决问题。这片白皮书所述的问题通常来源于Microsoft® Corporation 的Customer Support ServiceCSS or PSS）部门所遇到的，因为将所有可能的问题都详尽的分析是不合实际的。我们提供了按部就班的指导，通过使用可用的工具例如SQL Server Profiler，System Monitor和在SQL Server 2005中新的Dynamic Management View来为一般的性能问题诊断和排错。
目标
这篇文章的主要目标是提供一套常规的方法通过使用公开的工具在一般的客户场景中诊断和排错SQL Server性能问题。
SQL Server 2005在用户支持上有了很大的提高。内核层SQL-OS）被重新架构过，内部结构和统计数据通过动态管理视图(DMVs)暴露为关系型行集。SQL Server 2000通过像sysprocesses这样的系统表暴露一些信息，但是有时你需要将SQL Server进程内存映射为物理文件并从中抽取内部结构的相关信息。这里有2个主要的问题。第一，客户不能总是提供物理映射文件，因为文件的尺寸原因，并且这个过程很耗时。第二，这将花费更长的时间诊断问题，因为文件必须传回Microsoft Corporation来分析。
这带给我们本文的第二个目标，展示DMVs的优点。DMVs通过除去大多数情况下需要的生成和分析物理映射步骤可以加速调试的过程。本文尽可能的提供了和SQL Server 2000中同样问题的比较。DMVs提供为获取关键系统信息的简单而熟悉的界面。这些信息也可以用于监视目的，警告管理员潜在的问题。或者也可以被周期性的收集为以后的分析所用。
方法
这里有很多降低SQL Server速度的原因。我们使用下列3个主要症状来诊断问题。
◆资源瓶颈: CPU，内存，和I/O瓶颈是在本文中主要涉及的。这里我们不考虑网络因素。对每种资源瓶颈，我们会描述如何识别问题并阐述可能的原因。例如，内存瓶颈可以导致过多的分页，最后影响性能。
◆Tempdb 瓶颈:因为每个SQL Server 实例只有一个tempdb，这可以产生性能和磁盘空间的瓶颈。不好的应用程序在过多的DDL和DML操作会使tempdb过载。这导致其他在这台服务器上运行的不相关的应用程序运行缓慢或失败。
◆缓慢运行的用户查询:现有的查询性能下降或新的查询显示比预期时间更长。这可能有很多原因。例如：
◆改变统计信息可以导致现有查询的较差的查询计划。
◆制表扫描，降低查询性能。
◆即使资源利用正常由于阻塞也可以导致应用程序运行缓慢。
过多的阻塞可能是由于不良的应用程序设计或架构设计或者是选择了错误的事务隔离级别的原因。
这些症状的原因不需要每个都独立出来。不良的查询计划选择可以使系统资源加重并导致整体性能的下降。所以，如果大表缺失的有用的索引，或查询优化器没有选择它，这样不仅导致查询缓慢，也会导致将不需要数据页读取到内存buffer pool）中在缓存中存储，这样会加重I/O子系统的压力。同样的，频繁运行查询的重编译可以导致CPU的压力。