wapysun

浏览: 21488716 次
性别:
来自: 杭州

最近访客更多访客>>

devcang

hunankeda110

辽东小小

apex53

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

2012-06 ( 77)
2012-05 ( 587)
2012-04 ( 177)
更多存档...

SQL Server 2005性能排错

SQL Server 2005 性能排错

SQL Server 技术文章

作者 : Sunil Agarwal, Boris Baryshnikov, Tom Davidson, Keith Elmore, Denzil Ribeiro, Juergen Thomas

发布于 : 2005 年 10 月

适用于 : SQL Server 2005

摘要 : 很少会有偶然的性能下降。设计不良的数据库或工作负载配置不正确的系统会经常导致性能问题。管理员需要能预先阻止或最小化问题的影响，当管理员遇到问题时，应该诊断问题并采取正确操作来修复问题。本文提供了按部就班的指导，通过使用可用的工具例如 SQL Server Profiler ， System Monitor 和在 SQL Server 2005 中新的 Dynamic Management View 来为一般的性能问题诊断和排错。

版权声明

本文档中的信息（包括 URL 及其他 Internet 网站参考资料）可能随时变更，恕不另行通知。使用本文档的全部风险或因此导致的后果均由用户自行承担。

本文档仅供参考， Microsoft 对本文档中的信息不提供任何明示或暗示的保证。

用户必须遵守所有适用的著作权法。在不限制著作权法所保障的权利下，未经 Microsoft Corporation 书面许可，不得将本文档的任何部分复制、存储或引入检索系统，或以任何形式、手段 ( 电子、机械、影印、录音等等 ) 或基于任何目，转发本文任何部分。

Microsoft 可能拥有本文档主体的涉及的专利、专利使用、商标、著作权或其他知识产权。除非在 Microsoft 书面许可协议中明确提到，否则本文档并不向您提供其中的任何专利、商标、版权或其他知识产权。

除非注解，否则这里描述的样例公司、企业、产品、域名称、电子邮件地址、徽标、人员、地点和事件纯属虚构，不要有意或推断，将其与真实的公司、企业、产品、域名称、电子邮件地址、徽标、人员、地点或事件相联系。

Microsoft, Excel, SharePoint, Visual Basic, Visual C++, Visual C#, Visual J#, Visual Studio, 和 Windows 是微软公司在美国和 / 或其他国家（地区）的注册商标或商标。

此处提到的实际公司名称和产品名称可能使其所有者的商

简介 1

目标 1

方法 1

资源瓶颈 .. 2

解决资源瓶颈的工具 .. 2

CPU 瓶颈 .. 2

过多的编译和重编译 .. 3

检测 .. 3

解决 .. 6

效率低的查询计划 .. 6

检测 .. 7

解决 .. 7

内部查询的并行 .. 8

检测 .. 8

解决 .. 10

拙劣游标使用 .. 11

检测 .. 11

解决 .. 12

内存瓶颈 .. 12

背景 .. 12

虚拟地址空间和物理内存 .. 12

Windows 地址扩展和 SQL Server 12

内存压力 .. 13

检测内存压力 .. 14

外部物理内存压力 .. 14

外部虚拟内存压力 .. 15

内部物理内存压力 .. 15

高速缓存和内存压力 .. 21

Ring buffers 22

内部虚拟内存压力 .. 25

一般的内存错误排错步骤 .. 26

内存错误 .. 26

I/O 瓶颈 .. 29

解决 .. 31

Tempdb. 34

监视 tempdb空间 .. 35

磁盘空间问题排错 .. 35

用户对象 .. 35

版本存储 .. 36

内部对象 .. 37

过多的 DLL 和分配操作 .. 39

解决 .. 41

运行缓慢的查询 .. 41

阻塞 .. 41

识别长时间的阻塞 .. 43

通过 sys.dm_db_index_operational_stats查看阻塞的每个对象 .. 45

使用 SQL waits 阻塞对整体性能的影响 .. 48

监视索引的使用 .. 50

总结 52

附录 A: DBCC MEMORYSTATUS 描述 .. 52

附录 B: 阻塞脚本 .. 52

分析操作的索引统计 .. 54

等待状态 .. 72

msdnsample_topic4

简介

很多客户偶尔会遇到 SQL Server 数据库性能下降。原因可能涉及从不良好的数据库设计到不正确的负载配置。作为一个管理员，你应该预先阻止或最小化问题，并当问题发生时，诊断原因并尽可能的做出正确的操作来解决问题。这片白皮书所述的问题通常来源于 Microsoft® Corporation 的 Customer Support Service （ CSS 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 的压力。

资源瓶颈

接下来的部分讨论了 CPU ，内存和 I/O 子系统资源及这些瓶颈如何产生。（网络问题不在本文的讨论范围）每个资源瓶颈，我们描述了如何识别问题并找到原因。例如，一个内存瓶颈可以导致过渡分页，将会影响性能。

在决定你遇到资源瓶颈前，你需要了解在普通环境下资源是如何使用的。你可以使用在这片白皮书中所列出的方法收集有关资源使用的基线信息（即使你没有遇到性能问题）。

你也许找到问题是一个资源运行到设计容量并且 SQL Server 当前的配置不能支持这种负载。为了解决这问题，你也许需要添加处理能力，内存或增加 I/O 的带宽或网络通道。但是，在你进行下一步之前，理解这种资源瓶颈的通常原因是非常重要的。有一些解决方案不需要添加额外资源，例如重新配置。

解决资源瓶颈的工具

下列工具是在解决特殊性能瓶颈时经常使用的工具。

· 系统监视器 (PerfMon) ：这是 Windows 所带的一个工具。更多信息，请见系统监视器文档。

· SQL Server Profiler ：在 SQL Server 2005 程序组中的 Performance Tools 组中可以看到 SQL Server Profiler 。

· DBCC 命令：详细信息请见 SQL Server 联机丛书中和附录 A 。

· DMVs : 详细信息请见 SQL Server 联机丛书。

CPU 瓶颈

当没有额外负载，突然发生的 CPU 瓶颈通常由于没有查询计划，不良的配置或设计因素和不足的硬件资源所引起。在购买更快或更多处理器前，你需要首先确定 CPU 的最大处理能力带宽并查看是否他们都在使用中。

系统监视器一般是确定 CPU 资源的最好工具。你应该查看 Processor:%Processor Time 计数器是否偏高；该计数器值超过 80% 一般被认为是瓶颈。你也可以使用 sys.dm_os_schedulers 视图来监视是否正在运行的任务不是 0 。非 0 的值预示有任务需要等待时间切片来运行；这个数值高表明一个 CPU 瓶颈的征兆。你可以用下列查询列出所有的调度器并产看等待运行的任务数量。

select

scheduler_id,

current_tasks_count,

runnable_tasks_count

from

sys.dm_os_schedulers

where

scheduler_id < 255

下列查询给你一个查看当前缓存中最耗费 CPU 的批或过程高级别视图。查询根据具有相同 plan handle （意味着属于同一个批或过程）的语句聚合 CPU 的调用。如果给出的 plan handle 对应多个语句，你将不得不继续找到在整个 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

本节剩下的部分将讨论一些其他的在 SQL Server 中 CPU 敏感的操作，也有有效的检查和解决这些问题的方法。

过多的编译和重编译

当批或远端过程调用 (RPC) 被提交到 SQL Server ，在开始执行前，服务器检查查询计划的有效性和正确性。如果这些检查中的一个失败时，批将被再次编译声称不同的查询计划。这种编译就是所说的重编译。当服务器确认当底层数据改变时有更优化的查询计划时，重编译确认正确性再完成编译。编译是 CPU 敏感的，因此过多的重编译将导致在系统中的 CPU 性能问题。

在 SQL Server 2000 中，当 SQL Server 重编译一个存储过程，整个存储过程都被重编译，不仅是触发重编译的语句。 SQL Server 2005 引入了语句级的存储过程的重编译。当 SQL Server 2005 重编译存储过程，只有导致重编译的语句被编译 - 而不是整个存储过程。这减少了 CPU 的负载并减少了对例如 COMPILE 锁的资源争用。重编译可以有多种原因出发，例如：

· 架构变化

· 统计变化

· 延期编译

· Set 属性改变

· 临时表改变

· 存储过程创建时使用了 RECOMPLIE 查询提示或使用了 OPTION （ RECOMPILE ）。

检测

你可以使用系统监视器（ PerfMon ）或 SQL Trace(SQL Server Profiler) 来检测过多的编译和重编译。

系统监视器 (Perfmon)

SQL Statistics 对象提供了监视重编译的计数器和发送到 SQL Server 实例的请求类型。你必须监视查询编译和重编译的数量以及相关联的接受的批的数量来找出是否这个编译是最耗费 CPU 资源。理想环境下， SQL Recompilations/sec 和 Batch Request/sec 的比值应该很低，除非用户提交了大量的单独查询。

下列显示了关键的数据计数器。

· SQLServer: SQL Statistics: Batch Requests/sec

· SQLServer: SQL Statistics: SQL Compilations/sec

· SQLServer: SQL Statistics: SQL Recompilations/sec

更多信息请看 SQL Server 联机丛书中的 “SQL Statistics Object”

SQL 跟踪

如果 PerfMon 计数器显出了很高的重编译数量，编译将在 SQL Server 中占用很多的 CPU 资源。我们将需要查看 Profiler 跟踪并从中找到找到被重编译的存储过程。 SQL Server Profiler 跟踪给出我们重编译原因的信息。你可以使用下列事件。

SP:Recompile 和 SQL:StmtRecompile 事件类指出了哪个存储过程和语句被重编译。当你编译一个存储过程，一个事件为这个存储过程生成，其中每条语句将被编译。然而，当存储过程重编译时，只有导致重编译的语句被重编译（在 SQL Server 2000 中将是整个存储过程）。下面列出了 SP:Recompile 事件类更多重要的数据列。特别是 EventSubClass 数据列决定重编译的原因。 SP:Recompile 当存储过程或触发器被重编译被触发一次，但不会被独立查询引发。在 SQL Server 2005 中，监视 SQL:StmtRecompiles 也非常有用，该事件类在所有类型的重编译中都会被触发，包括批，独立查询，存储过程和触发器。如下是我们关系的事件中关键的数据列：

· EventClass

· EventSubClass

· ObjectID (represents stored procedure that contains this statement)

· SPID

· StartTime

· SqlHandle

· TextData

更多信息，请见 SQL Server 联机丛书中 “SQL:StmtRecompile Event Class” 。

如果你有保存的跟踪文件，你可以使用下列查询查看所有捕捉的重编译事件。

select

spid,

StartTime,

Textdata,

EventSubclass,

ObjectID,

DatabaseID,

SQLHandle

from

fn_trace_gettable ( 'e:/recompiletrace.trc' , 1)

where

EventClass in(37,75,166)

事件类 37 是 Sp:Recompile ， 75 是 CursorRecompile ， 166 是 SQL:StmtRecompile

你可以通过 SqlHandle 和 ObjectID 列或其他列将这个查询的结果分组，也可以查看是否最多的重编译类型是存储过程或其他原因（例如 SET 选项改变等）。

Showplan XML For Query Compile .

Showplan XML For Query Compile 事件发生于 Microsoft SQL Server 编译或重编译一段 SQL 语句时。该事件有关于语句编译或重编译的信息。信息包括查询计划和过程的对象 ID 。捕获这些事件是有性能开销的，因为它捕获了每次编译或重编译。如果你在系统监视其中看到很高的 SQL Compilations/sec 计数器值，你应该监视这个事件。通过这些信息，你可以看到那条语句被频繁的重编译。你可以使用这些信息改变这些语句的参数。这将影响重编译的数量。

DMVs .

当你使用 sys.dm_exec_query_optimizer_info DMV ，你可以得到 SQL Server 花费在优化的时间。如果获取了这个 DMV 的 2 个快照，你可以得到在给定的时间段内花费在查询优化的时间。

select *

from sys.dm_exec_query_optimizer_info

counter occurrence value

---------------- -------------------- ---------------------

optimizations 81 1.0

elapsed time 81 6.4547820702944486E-2

特别是查看 elapsed time ，该时间由于优化而产生。因为优化过程的时间基本上就是用户优化操作的 CPU 时间（因为优化处理是 CPU 时间的主要部分），你可以得到一个好的度量，找到那段编译时间占用了大量的 CPU 时间。

其他包含有用信息的 DMV 有：

sys.dm_exec_query_stats .

你希望查看的数据列有 :

· Sql_handle

· Total worker time

· Plan generation number

· Statement Start Offset

更多信息请查看 SQL Server 联机丛书相关主题

sys.dm_exec_query_stats .

特别是 plan_generation_num 预示了查询编译时的次数。下面是示例给你展示了被重编译次数最多的 25 个存储过程。

select *

from sys.dm_exec_query_optimizer_info

select top 25

sql_text.text,

sql_handle,

plan_generation_num,

execution_count,

dbid,

objectid

from

sys.dm_exec_query_stats a

cross apply sys.dm_exec_sql_text(sql_handle) as sql_text

where

plan_generation_num >1

order by plan_generation_num desc

解决

如果你监测到过多的编译 / 重编译，考虑下列选项。

· 如果重编译因为 SET 选项改变而发生，使用 SQL Server Profiler 确定哪个 SET 选项被改编。避免在存储过程中改变 SET 选项。如果改变最好在连接级别设置。确认在该连接的生存周期内不要改变 SET 选项。

在临时表上重编译的阀值比在普通表上的低。在临时表上的重编译时由于统计改变而引起，你可以降临时表改为使用表变量。表变量的改变不会引起重编译。这种方法的确定是查询优化器不识别表变量，因为统计不会被创建或维护表变量。这将导致没有查询计划。你可以测试不同的选项，并选择最好的方法。另外一个选项时使用 KEEP PLAN 查询提示。设置临时表的这个阀值与使用永久表相同。 EventSubclass 列预示了在临时表上的 ”Statistics Changed” 的操作。

· 为避免由于改变统计而产生的重编译（例如，因为数据统计导致计划不理想），特别是 KEEPFIXED PLAN 查询提示。根据设置的影响，重编译可以仅因为相关正确的原因（例如，当底层表结构改变导致计划不再适用），而不根据统计的变化。如果语句引用的表的架构改变时或者表是被标记为 sp_recompile 的存储过程，重编译将发生。

· 关闭自动更新索引统计和表或视图的统计，防止由于对象的统计改变而产生的重编译。注意，通过使用这种方法关闭 ”auto-stats” 特性不是一个好的想法。这是因为查询优化器不再为在这些对象上的数据改变而敏感，将导致不良的查询计划。使用这种方法仅在尝试了所有其他选择之后，做为最后的手段。

· 批应该尽量使用对象全名（例如， dbo.Table1 ）避免重编译并避免不明确的对象。

· 为避免由于延期编译导致的重编译，不要混杂 DML 和 DDL 或从条件结构创建 DDL ，例如 IF 语句。

· 运行 Database Engine Tuning Advisor(DTA) 查看改变索引是否可以改善编译时间和查询的执行时间。

· 检查是否存储过程通过 WITH RECOMPILE 选项创建或使用了 RECOMPILE 查询提示。如果过程通过 WITH RECOMPILE 选项创建，在 SQL Server 2005 中，如果在过程中特殊的语句需要被重编译，我们可以利用语句级的 RECOMPILE 提示。这将避免在每次执行的时候对整个过程重编译，而同时允许个别语句被编译。更多有关 RECOMPILE 提示的信息，请查看 SQL Server 联机丛书。

效率低的查询计划

当为一个查询生成查询计划时， SQL Server 查询优化器尝试选择一个计划为查询提供最快的响应时间。注意最快的查询时间并不意味最小的 I/O 开销，也不意味使用最少的 CPU 资源 - 它会在各种资源中平衡。

某些操作类型比其他操作对 CPU 更敏感。 Hash 操作和 Sort 操作扫描他们各自的输入数据。使用扫描向前读取（ prefetch ）时，在需要操作页面前，页面几乎都在缓存中。因此可以减少或消除物理 I/O 操作。这使这些操作的类型将不被物理 I/O 所限制。与之相比，嵌套循环连接有很多索引查找，如果索引查找使用很多不同的表以至于页面不适合缓存的大小，将导致生成 I/O 负载。

最有意义的输入优化用于评估为每中操作生成不同查询计划开销的评估，你可以在 Showplan （ EstimateRows 和 EstimateExecution 属性）中看到结果。没有精确的评估，用于优化的主输入是有缺陷的。

为获取 SQL Server 优化器如何使用统计的详细信息，请查看 Statistics Used by the Query Optimizer in Microsoft SQLServer2005 。该白皮书讨论了优化器如何使用统计，维护和更新统计的最佳实践，以及一些常见的查询设计问题。

检测

低效率的查询计划通常可以被检测出来。低效率的查询计划可以导致增加 CPU 的消耗。

查询 sys.dm_exec_query_stats 是确定哪个查询累计使用 CPU 时间最多的有效方法。

select

highest_cpu_queries.plan_handle,

highest_cpu_queries.total_worker_time,

q.dbid,

q.objectid,

q.number,

q.encrypted,

q.[text]

from

(select top 50

qs.plan_handle,

qs.total_worker_time

from

sys.dm_exec_query_stats qs

order by qs.total_worker_time desc) as highest_cpu_queries

cross apply sys.dm_exec_sql_text(plan_handle) as q

order by highest_cpu_queries.total_worker_time desc

还可以选择，也可以查询 sys.dm_exec_cached_plans 并通过使用过滤器查找可疑的类似于 ‘%Hash Match%’, ‘%Sort%’ 这样 CPU 敏感的各种操作。

解决

如果你监测到效率低的查询计划，考虑下列选项。

· 使用 Database Engine Tuning Advisor 调节查询，查看是否生成对修改索引的建议

· 检查有问题的评估。

编写的查询中使用的更有限制性的 WHERE 从句是否合适？无限制条件的查询是资源敏感的。

在查询中涉及的表上运行 UPDATE STATISTICS ，检查是否还有这种问题。

是否查询使用的构造导致优化器不能精确的评估？

考虑是否可以将查询修改为其他的方法，避免这种问题。

· 如果不能修改架构或查询， SQL Server 2005 有一个新的查询计划特性，允许你将指定查询提示添加到满足某种文本的查询中。这可以用在独立查询中，也可以用在存储过程内。例如 OPTION(OPTIMIZE FOR) 这样的提示允许你影响评估而忘记所有列出的潜在计划。其他的提示，类似 OPTION(FORCE ORDER) 或 OPITON(USE PLAN) 允许你改变控制查询计划的程度。

内部查询的并行

当为一个查询生成执行计划时， SQL Server 优化器尝试为该查询选择最快的相应计划。如果查询的开销超过了在 cost threshold for parallelism 选项中指定的值，并行不会被禁用，优化器尝试生成一个可以用于并行的计划。并行查询计划使用多线程处理查询，每个线程分布在可用的 CPU 上并同时利用每个 CPU 的时间资源。最大的并行度可以通过服务器上的 max degree of parallelism 选项或每个查询使用 OPTION(MAXDOP) 提示限制。

用于执行实际并行度（ DOP ）的结果——度量有多少线程将在给定的操作上并行——是知道执行时才能确定。在执行查询前， SQL Server 2005 决定有多少个调度器未充分利用并为查询选择 DOP 来充分利用剩余的调度器。一旦一个 DOP 被选择了，直到完成，查询将使用这个选择的并行度来运行。并行查询的使用时 CPU 有一些偏高，但是它在 elapsed time 上的时间很短。如果没有其他瓶颈，类似于物理 I/O 等待，并行计划将会使用所有处理器的 100% 资源。

查询开始执行后，一个关键的因素（系统有多空闲）可以导致运行并行计划的改变。例如，如果查询运行在空闲时间，服务器可以选择使用并行计划并使用 DOP 为 4 ，在 4 个不同的处理器上产生线程。一旦这种线程开始执行，现存的连接可以提交其他需要大量 CPU 的查询。在这种情况，所有不同的线程将共享可用的 CPU 的时间切片，导致更高的查询持续时间。

通过并行计划运行不是一定是不好的，并行可以为查询提供最快的响应时间。然而，给定查询的响应时间必须与整体的吞吐量和系统其他查询的响应进行衡量。并行查询一般最适合批处理和决策支持系统，而不适合一个事务处理环境。

检测

内部查询的并行问题可以通过下列方法检测。

系统监视器 (Perfmon)

考虑 SQL Server:SQL Statistics – Batch Requests/sec 计数器，并查看 SQL Server 联机丛书中的 “SQL Statistics Object” 获取更多信息。

因为在考虑使用并行计划前，查询必须评估开销超过为并行配置设置的开销阀值（默认被设置为 5 ），服务器每秒处理的批小于运行在并行计划中的批。运行很多并行查询的服务器一般配置为较小的每秒批请求数（例如，小于 100 的值）。

DMVs

在运行的服务器上，你可以使用下列查询确认在给定会话中是否可以并行运行任何活动的请求。

select

r.session_id,

r.request_id,

max(isnull(exec_context_id, 0)) as number_of_workers,

r.sql_handle,

r.statement_start_offset,

r.statement_end_offset,

r.plan_handle

from

sys.dm_exec_requests r

join sys.dm_os_tasks t on r.session_id = t.session_id

join sys.dm_exec_sessions s on r.session_id = s.session_id

where

s.is_user_process = 0x1

group by

r.session_id, r.request_id,

r.sql_handle, r.plan_handle,

r.statement_start_offset, r.statement_end_offset

having max(isnull(exec_context_id, 0)) > 0

通过这些信息，查询的文本可以通过使用 sys.dm_exec_sql_text 轻松获取，而查询计划可以使用 sys.dm_exec_cached_plan 获取。

你也可以搜索符合运行在并行的计划。这可以通过搜索缓存的计划来查看如果关系操作符有 Parrallel 属性为非零的值。这些计划也许可以不运行在平行中，但是他们如果系统不忙，他们也适合这样做。

-- Find query plans that may run in parallel

select

p.*,

q.*,

cp.plan_handle

from

sys.dm_exec_cached_plans cp

cross apply sys.dm_exec_query_plan(cp.plan_handle) p

cross apply sys.dm_exec_sql_text(cp.plan_handle) as q

where

cp.cacheobjtype = 'Compiled Plan' and

p.query_plan.value('declare namespace p="http://schemas.microsoft.com/sqlserver/2004/07/showplan";

max(//p:RelOp/@Parallel)', 'float') > 0

一般来说，查询的持续时间长于 CPU 时间总量，因为一些时间花费在等待资源上例如锁或物理 I/O 。查询使用 CPU 时间长于持续时间的唯一场景是当查询运行在并行计划例如多线程并发使用 CPU 。注意并不是所有并行查询将证明这种行为（ CPU 时间大于持续时间）。

select

qs.sql_handle,

qs.statement_start_offset,

qs.statement_end_offset,

q.dbid,

q.objectid,

q.number,

q.encrypted,

q.text

from

sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.plan_handle) as q

where

qs.total_worker_time > qs.total_elapsed_time

SQL Trace

Look for the following signs of parallel queries, which could be either statements or batches that have CPU time greater than the duration.

select

EventClass,

TextData

from

::fn_trace_gettable('c:/temp/high_cpu_trace.trc', default)

where

EventClass in (10, 12) -- RPC:Completed, SQL:BatchCompleted

and CPU > Duration/1000 -- CPU is in milliseconds, Duration in microseconds

Or can be Showplans (un-encoded) that have Parallelism operators in them

select

EventClass,

TextData

from

::fn_trace_gettable('c:/temp/high_cpu_trace.trc', default)

where

TextData LIKE '%Parallelism%'

解决

任何运行在并行计划的查询被查询优化器认为是成本昂贵的，并会超过并行阀值，默认为 5 （粗略的是在涉及的机器上 5 秒执行一次）。任何通过上述方法确认的查询都是以后要调节的候选者。

· 使用 Database Engine Tuning Advisor 查看是否任何索引改变，改变索引视图或分区改变能减少查询的开销

· 检查实际值和评估集的重要不同因为评估集在评估查询开销中是重要因素。如果找到重要的不同：

如果 auto create statistics 数据库设置被禁用，确认在 Showplan 输出的 Warnings 列中没有 MISSING STATS 项。

尝试在关闭评估的表上运行 UPDATE STATISTICS 。

验证查询没有使用优化器无法精确评估的查询构造，例如多语句表值函数或 CLR 函数，表值或 Transact-SQL 变量比较（参数比较是可以的）。

· 评估是否可以使用不同的 Transact-SQL 语句或表达式将查询写的更有效率

拙劣游标使用

SQL Server 2005 之前的 SQL Server 版本仅支持在每个连接上有单个活动的操作。一个查询正在执行或有了结果等待发送到客户端时将被认为是活动的。在一些情形中，客户端应用程序也许需要从结果中读取并向 SQL Server 提交其他基于刚刚从结果集中读取的行的查询。这在默认的结果集中是不能实现的，因为还有其他等待的结果。一般的解决方法是改变连接属性是用服务器端游标。

当使用服务器端游标，数据库客户端软件 (OLE DB 提供者或 ODBC 驱动 ) 显然会封装客户端请求在特殊的扩展存储过程中，例如 sp_cursoropen ， sp_cursorfetch 等等。这提到了 API 游标（而不是 TSQL 游标）。当用户执行查询，查询文本通过 sp_cursoropen 被发送到服务器，请求读取从 sp_cursorfetch 指示服务器进发送某些数量的行。通过控制获取行的数量，可以为 ODBC 驱动或 OLE DB 提供者缓存行。这阻止发生服务器等待客户端都区所有发送的行的情形。因此，服务器可以在这个连接上接受新的请求。

一次性打开游标并获取 1 行（或少量行）的应用程序能被网络延时的网络瓶颈影响，特别是在广域网（ WAN ）。在有快速网络并有不同用户连接时，处理很多游标请求的开销变得更重要。因为开销来自于游标位置的变化来适应在结果集上的位置改变，预请求的处理开销，类似的处理，服务器处理 1 个请求返回 100 行必处理 100 不同请求相同的 100 行但是每次 1 行更有效率。

检测

你可以使用下列方法为拙劣游标使用排错。

系统监视器 (Perfmon)

通过考虑 SQL Server:Cursor Manager By Type – Cursor Requests/Sec 计数器，你可以通过这个性能计数器知道有多少游标在系统中使用。系统还有很高的 CPU 利用率，因为小量的读取通常会有每秒数百个游标请求。这里没有特殊的计数器告诉你关于获取的缓存大小。

DMVs

接下来的查询可以用于测定使用 API 游标（不是 TSQL 游标）连接获取一行使用的缓存大小。它对于大的获取缓存更有效，例如 100 行。

select

cur.*

from

sys.dm_exec_connections con

cross apply sys.dm_exec_cursors(con.session_id) as cur

where

cur.fetch_buffer_size = 1

and cur.properties LIKE 'API%' -- API cursor (TSQL cursors always have fetch buffer of 1)

SQL 跟踪

使用包括 RPC:Completed 事件类的跟踪用于搜索 sp_cursorfetch 语句。第 4 个参数的值是通过获取返回的行数。请求返回的最大行数是被指定为与 RPC:Starting 事件类关联的参数。

解决

· 确定游标是完成操作的最佳方法或是否基于集合这种更有效的操作是可行的。

· 当连接到 SQL Server 2005 ，考虑使用多活动结果集 (MARS)

· 参考你使用的 API 文档决定如何指定游标的获取缓存大小：

ODBC - SQL_ATTR_ROW_ARRAY_SIZE

OLE DB – IRowset::GetNextRows or IRowsetLocate::GetRowsAt

内存瓶颈

这部分给出了低缓存的条件和对不同内存错误诊断方法，可能的原因和排错方法。

背景

引用不同的内存资源通过使用简单的术语内存。但是却有一些内存资源类型，对于理解和区分特殊的内存资源这是很重要的。

虚拟地址空间和物理内存

在 Microsoft Windows® ，每个进程都有自己的虚拟地址空间 (VAS) 。进程可用所有虚拟地址有 VAS 的大小决定。 VAS 的大小依赖于架构（ 32 位或 64 位）和操作系统。在排错的上下文中，理解虚拟地址空间使用内存资源，了解应用程序可以超出 VAS 即使在 64 位平台只要物理地址可能一直可用，这些很重要。

更多有关于虚拟地址空间，请查看 SQL Server 联机丛书中 “Process Address Space” 和 MSDN 中的 Virtual Address Space 。

Windows 地址扩展和 SQL Server

Windows 地址扩展 (AWE) 是允许 32 位应用程序跨越 32 位地址限制操作内存的 API 。 AWE 机制技术上不需要 64 位平台。然而它出现了。内存页通过 AWE 机制涉及在 64 位平台上的锁定页。

在 32 位和 64 位平台上，内存通过 AWE 机制分配不能分页出界。这可以有益于应用程序（这是在 64 位平台上使用 AWE 机制的原因）。这也影响了系统和其他应用程序可用 RAM 总数，这可能是有害的影响。因为这个原因为了使用 AWE ， Lock Pages in Memory 权利必须分配该运行 SQL Server 的账号。

从排错的角度来看，要点是 SQL Server 缓存池使用 AWE 映射内存；然而，只有数据库（ hash 过的）页面可以利用 AWE 分配内存。通过 AWE 机制内存分配将不会在任务管理器或在 Process: Private Bytes 性能计数器中看到。你需要使用 SQL Server 特殊的计数器或动态管理视图来获取这些信息。

更多关于 AWE 映射内存的信息，请在 SQL Server 联机丛书中查看 “Managing memory for large databases” 和 “Memory Architecture” 以及 MSDN 中的 Large Memory Support

下列表汇总了不同 SQL Server 2005 支持的最大内存（注意特殊的 SQL Server 版本或 Windows 可以有不同支持内存的限制）

表 1

配置	VAS	最大物理内存	AWE/locked pages 支持
Native 32-bit on 32-bit OS with /3GB boot parameter <!-- [if !supportFootnotes]-->[1] <!-- [endif]-->	2GB 3GB	64GB 16GB	支持支持
32-bit on x64 OS (WOW)	4GB	64GB	支持
32-bit on IA64 OS (WOW)	2GB	2GB	不支持
Native 64-bit on x64 OS	8terabyte	1terabyte	支持
Native 64-bit on IA64 OS	7terabyte	1terabyte	不支持

内存压力

内存压力表示当可用内存数量受到限制。识别 SQL Server 何时运行在内存压力下将帮助你排除内存相关的问题。 SQL Server 依赖于不同类型的内存压力特征也不一样。下表汇总了内存压力类型，和他们潜在的原因。在所有的情况下，你可以更多的会见到超时或显示的内存不足错误消息。

表 2

压力

外部

内部

物理

物理内存 (RAM) 运行值低。这导致系统整理当前运行的工具集，导致整体性能下降。

SQL Server 监测到这种条件，依赖于配置，可以减少缓存池的目的提交并开始清理内部缓存。

SQL Server 检测内部较高的内存消耗，导致在不同内部组件间的内存重新分配。

内部内存压力可以导致：

· 导致外部内存压力（ SQL Server 设置地的内存使用能力）。

· 改变内存设置（例如 ‘max server memory’ ）。

· 改变内部组件的内存分布（导致预留的高百分比并从缓存池中获取页）。

虚拟的

在系统页面文件运行在较低值。这样可以导致系统分配内存失败。不能扩展当前的内存分配。这可以导致着整个系统响应很慢或者可能导致系统关机。

在 VAS 运行值低，导致分页（很多 VAS 可用，但是被分为小块）与 / 或消耗（直接分配， DLL 加载到 SQL VAS ，大量的线程）。

SQL Server 检测到这种条件并可以释放 VAS 中保留的区域，减少缓存池提交的目标并开始收缩缓存。

Windows 有通知的机制 ^{^[2]} 如果物理内存运行在过高或过低的情况下。 SQL Server 在他的内存管理决策中使用这种机制。

一般排错的步骤显示在表 3 中。

表 3

压力

内部

外部

物理

· 找到主要的系统内存消耗组件。

· 尝试消除消耗 ( 如果可能 ) 。

· 检查适当的系统 RAM 和考虑添加额外 RAM （通常需要更仔细研究）

· 识别 SQL Server 内主要的内存消耗

· 确认系统配置。

· 进一步操作依赖于研究；检查负载；可能出现的设计问题；其他的资源瓶颈。

虚拟

· 增加交换文件大小。

· 检查主要物理内存的使用和外部物理内存压力调用步骤。

· 外部物理内存压力调用步骤。

工具

下列工具和资源可以用于排错。

· 内存相关的 DMVs

· DBCC MEMORYSTATUS 命令

· 性能计数器 : 性能监视器或 SQL Server 指定对象的 DMV

· 任务管理器

· 事件查看器 : 应用程序日志和系统日志

检测内存压力

内存压力自身不会预示问题。内存压力是需要的，但时不是为服务器以后遇到内存错误的充分条件。在内存压力下工作将被任务是服务器的正常操作。然而内存压力的征兆可以于是服务器运行已经接近设计容量并且潜在存在内存不足的错误。在正常运行情况下，这些信息将作为基线决定以后内存不足的原因。

外部物理内存压力

打开人物管理器的性能视图，检查 Physical Memory 节的 Available 项的值。如果可用内存总数很低，这表现了有外部内存压力。这个准确值依赖于很多因素，然而你可以在当这个值降低到 50-100MB 开始查找问题。当这个总数小于 10MB 时，外部内存压力将表现得很明显。

相同信息也可以使用在系统监视器中的 Memory: Available Bytes 计数器获取。

如果存在外部内存压力并且你看到了内存相关的错误，你需要确认在系统中主要的内存消耗者。为了这个，考虑 Process: Working Set 性能计数器或在任务管理器中 Process 栏中的 Mem Usage 列，找到最大的内存消耗者。

系统中所有使用的物理内存可以通过汇总下列计数器获取。

· Process 对象，每个进程的 Working Set 计数器

· Memory 对象

· 系统的 Cache Bytes 计数器

· 未分页池的 Pool Nonpaged Bytes 计数器

· Available Bytes ( 等于任务管理其中的 Available 值 )

如果没有外部压力， Process: Private Bytes 计数器或在任务管理器中虚拟内存将接近工作集的大小（ Process: Working Set 或任务管理器中的 Mem Usage ），意味着我们没有内存用于分页了。

注意任务管理器中的 Mem Usage 列和相应的性能计数器不能计算通过 AWE 分配的内存。这样如果使用 AWE ，信息将是不完整的。这种情况下，你需要考虑在 SQL Server 内分配的内存来获取完整的信息。

你可以使用 sys.dm_os_memory_clerks DMV 找到 SQL Server 通过 AWE 机制分配了多少内存，如下所示。

select

sum(awe_allocated_kb) / 1024 as [AWE allocated, Mb]

from

sys.dm_os_memory_clerks

注意在 SQL Server 中，只有当前缓存池（ ’ MEMORYCLERK_SQLBUFFERPOOL’ 类型）使用这种机制并且只能是在使用 AWE 功能时。通过识别和除去主要物理内存使用者（如果有可能）和 / 或通过添加更多的内存的方法解除外部内存压力一般可以解决与此相关的内存问题。

外部虚拟内存压力

你需要确定是否页面文件为当前内存的分配能提供足够的空间。为了检查，可以打开任务管理器中的性能视图，并检查 Commit Charge 节。如果 Total 接近于 Limit 则说明可以被提交的最大数量内存没有扩展页面的空间。注意任务管理器中的 Commit Charge Total 指出潜在使用的页面文件，而不是实际使用值。实际使用的页面文件将增加物理内存压力。

同样可以通过下列技术起获取相关信息： Memory: Commit Limit , Paging File: %Usage , Paging File: %Usage Peak 。

你可以通过每个进程的 Process: Working Set 减去 Process Private Bytes 计数器来评估内存总数。

如果 Paging File: %Usage Peak （或 Peak Commit Charge ）很高，检查系统日志中是否有指出页面文件增长或通知 “running low on virtual memory” 的信息。你可能需要增加你的页面文件大小。 High Paging File: %Usage 指出物理内存超过要提交的值并也要考虑外部物理内存压力（大量的内存需求，没有足够的 RAM ）。

内部物理内存压力

内部内存压力来自于 SQL Server 自身，应首先通过检查在缓存分布中的异常来考虑在 SQL Server 内存分布。通常在 SQL Server 中缓存会占用最多提交的内存。为了确定在缓存池中的内存总数，我们可以使用 DBCC MEMROYSTATUS 命令。在 Buffer Counts 节，可以找到 Target 值。下列输出显示了在服务器达到正常负载时 DBCC MEMORYSTATUS 的结果。

Buffer Counts Buffers

------------------------------ --------------------

Committed 201120

Target 201120

Hashed 166517

Reserved Potential 143388

Stolen Potential 173556

External Reservation 0

Min Free 256

Visible 201120

Available Paging File 460640

Target 是 SQL Server 计算出它在不导致分页时可以提交的 8-KB 每页的页数。 Target 是被定期的重新计算的来反映内存的低或高。在常规服务负载下 target 页面过低可能预示出现了外部内存压力。

如果 SQL Server 占用了大量的内存 ( 通过 Process: Private Bytes 或任务管理器中 Mem Usage 列显示 ) ，请查看是否 Target 的数值。注意，如果启用 AWE ，你还要从 sys.dm_of_memory_clerks 或 DBCC MEMORYSTATUS 输出计算 AWE 分配的总量。

考虑上面的示例（没有启用 AWE ）， Target*8KB=1.53GB ，而服务器的 Process: Private Bytes 大约是 1.62GB 或缓存池用 SQL Server 占用了 94% 的内存。注意，如果服务器没有过载， Target 是应该超过 Process: Private Bytes 性能计数器报告的数量。

如果 Target 过低，但是服务器的 Process: Private Bytes 或任务管理器中 Mem Usage 值很高，我们也许要面对从缓存池外使用内存的组件带来的内部内存压力。被加载到 SQL Server 进程中的组件，例如 COM 对象，连接服务器，扩展存储过程， SQLCLR 或其他会从缓存池外占用内存。如果不使用 SQL Server 内存接口，将没有方法跟踪组件在缓存池外占用的内存。

适用于 SQL Server 内存管理机制的组件使用在缓存池中分配很少的内存。如果分配的大于 8KB ，这些组将将通过多页分配器借口使用缓存池外的内存。

下列方法可以快速检查通过多业分配器接口占用的内存数量。

-- amount of mem allocated though multipage allocator interface

select sum(multi_pages_kb) from sys.dm_os_memory_clerks

你可以这样获得通过多页分配器分发内存的详细信息：

select

type, sum(multi_pages_kb)

from

sys.dm_os_memory_clerks

where

multi_pages_kb != 0

group by type

type

------------------------------------------ ---------

MEMORYCLERK_SQLSTORENG 56

MEMORYCLERK_SQLOPTIMIZER 48

MEMORYCLERK_SQLGENERAL 2176

MEMORYCLERK_SQLBUFFERPOOL 536

MEMORYCLERK_SOSNODE 16288

CACHESTORE_STACKFRAMES 16

MEMORYCLERK_SQLSERVICEBROKER 192

MEMORYCLERK_SNI 32

如果通过多页分配器分发了过大的内存 ( 100-200MB 或更多 ) ，应该做进一步的研究。

如果你看到了通过多页分配器分发的大量内存，检查服务器的配置并尝试使用之前或后续的查询确定哪个组件占用的最多的内存。

如果 Target 值低，但是在百分比上它占用了最多的内存，请在前面部分中查找描述外部内存压力的部分 (External Physical Memory Pressure ) ，或查看服务器内存配置参数。

如果你设置了 max server memory 和 / 或 min server memory ，你应该用这些值和 Target 值进行比较。 max server memory 选项限制了在缓存池中占用内存的最大值，而服务器还可以占用其他的部分。 min server memory 选项告诉服务器当小于该值时不能释放缓存池的内存。如果 Target 小于 min server memory 设置并且服务器没有过载，这可能预示服务器遇到了外部内存压力并且不能获得这个设置大小的内存。它也可能预示着从内部组件的内存压力，就像上面描述的那样。 Target 数值不能超过 max server memory 选项的设置。

首先，检查从 DBCC MEMORYSTATUS 输出中 Stolen 页面数量

Buffer Distribution Buffers

------------------------------ -----------

Stolen 32871

Free 17845

Cached 1513

Database (clean) 148864

Database (dirty) 259

I/O 0

Latched 0

相对于 Stolen 和 Target 页面的高百分比 (>75-80%) 预示着内部内存压力。

更多关于服务器组件内存分配的信息可以使用 sys.dm_of_memory_clerks DMV 获取。

-- amount of memory consumed by components outside the Buffer pool

-- note that we exclude single_pages_kb as they come from BPool

-- BPool is accounted for by the next query

select

sum(multi_pages_kb

+ virtual_memory_committed_kb

+ shared_memory_committed_kb) as [Overall used w/o BPool, Kb]

from

sys.dm_os_memory_clerks

where

type <> 'MEMORYCLERK_SQLBUFFERPOOL'

-- amount of memory consumed by BPool

-- note that currenlty only BPool uses AWE

select

sum(multi_pages_kb

+ virtual_memory_committed_kb

+ shared_memory_committed_kb

+ awe_allocated_kb) as [Used by BPool with AWE, Kb]

from

sys.dm_os_memory_clerks

where

type = 'MEMORYCLERK_SQLBUFFERPOOL'

每个组件的详细信息可以通过下列语句获取（这包括从缓存池内和缓存池外分配的内存）。

declare @total_alloc bigint

declare @tab table (

type nvarchar(128) collate database_default

,allocated bigint

,virtual_res bigint

,virtual_com bigint

,awe bigint

,shared_res bigint

,shared_com bigint

,topFive nvarchar(128)

,grand_total bigint

);

-- note that this total excludes buffer pool committed memory as it represents the largest consumer which is normal

select

@total_alloc =

sum(single_pages_kb

+ multi_pages_kb

+ (CASE WHEN type <> 'MEMORYCLERK_SQLBUFFERPOOL'

THEN virtual_memory_committed_kb

ELSE 0 END)

+ shared_memory_committed_kb)

from

sys.dm_os_memory_clerks

'Total allocated (including from Buffer Pool): '

+ CAST(@total_alloc as varchar(10)) + ' Kb'

insert into @tab

select

type

,sum(single_pages_kb + multi_pages_kb) as allocated

,sum(virtual_memory_reserved_kb) as vertual_res

,sum(virtual_memory_committed_kb) as virtual_com

,sum(awe_allocated_kb) as awe

,sum(shared_memory_reserved_kb) as shared_res

,sum(shared_memory_committed_kb) as shared_com

,case when (

(sum(single_pages_kb

+ multi_pages_kb

+ (CASE WHEN type <> 'MEMORYCLERK_SQLBUFFERPOOL'

THEN virtual_memory_committed_kb

ELSE 0 END)

+ shared_memory_committed_kb))/(@total_alloc + 0.0)) >= 0.05

then type

else 'Other'

end as topFive

,(sum(single_pages_kb

+ multi_pages_kb

+ (CASE WHEN type <> 'MEMORYCLERK_SQLBUFFERPOOL'

THEN virtual_memory_committed_kb

ELSE 0 END)

+ shared_memory_committed_kb)) as grand_total

from

sys.dm_os_memory_clerks

group by type

order by (sum(single_pages_kb + multi_pages_kb + (CASE WHEN type <> 'MEMORYCLERK_SQLBUFFERPOOL' THEN virtual_memory_committed_kb ELSE 0 END) + shared_memory_committed_kb)) desc

select * from @tab

注意之前的查询将 Buffer Pool 与通过单页分配器提供给组件的内存视为不同的部分。通过下列查询可以确定在缓存池中耗费内存最多的 10 个组件（通过单页分配器）。

-- top 10 consumers of memory from BPool

select

top 10 type,

sum(single_pages_kb) as [SPA Mem, Kb]

from

sys.dm_os_memory_clerks

group by type

order by sum(single_pages_kb) desc

你通常不会控制内部组件对内存的占用。然而，确定哪个组件占用最多的内存可以帮助对问题的后续研究。

系统监视器 (Perfmon)

你也可以通过检查下列计数器来确定内存压力（ SQL Server 联机丛书中有详细地描述）：

SQL Server: Buffer Manager 对象

· Low Buffer cache hit ratio

· Low Page life expectancy

· High number of Checkpoint pages/sec

· High number Lazy writes/sec

不足的内存和 I/O 开销经常会导致瓶颈。请查看本文的 I/O 瓶颈部分。

高速缓存和内存压力

查看外部和内部内存压力的方法是查看内存中高速缓存的行为。

SQL Server 2005 与 SQL Server 2000 的高速缓存设计上有一些细微的不同，其中之一就是统一了高速缓存的框架。为了从高速缓存中删除最近很少使用的项，该框架实现了一套时钟算法。现在它使用 2 支不同的时钟指针，一个是内部时钟指针，一个是外部时钟指针。

内部时钟指针控制与其他高速缓存相关的缓存大小。当框架预测到高速缓存要使用到尽头是它开始移动。

当 SQL Server 总体上陷入内存压力时，外部时钟指针开始移动。外部时钟指针的移动可以导致外部和内部的内存压力。在内部和外部内存压力时不会混乱的移动外部时钟和内部时钟。

关于时钟移动的信息可以通过 sys.dm_os_memory_cache_clock_hands DMV 显示，如下代码所示。每个高速缓存项在内部和外部时钟指针都有不同的行。如果你看到 rounds count 和 removed all rounds count 增加，说明服务器遇到内部 / 外部内存压力。

select *

from

sys.dm_os_memory_cache_clock_hands

where

rounds_count > 0

and removed_all_rounds_count > 0

通过如下所示，通过通过 sys.dm_os_cache_counters DMV 你可以获得更多关于缓存的信息。

select

distinct cc.cache_address,

cc.name,

cc.type,

cc.single_pages_kb + cc.multi_pages_kb as total_kb,

cc.single_pages_in_use_kb + cc.multi_pages_in_use_kb as total_in_use_kb,

cc.entries_count,

cc.entries_in_use_count,

ch.removed_all_rounds_count,

ch.removed_last_round_count

from

sys.dm_os_memory_cache_counters cc

join sys.dm_os_memory_cache_clock_hands ch on (cc.cache_address = ch.cache_address)

--uncomment this block to have the information only for moving hands caches

where

ch.rounds_count > 0

and ch.removed_all_rounds_count > 0

order by total_kb desc

注意 USERSTORE 项，正在使用的页面数量将不会被报告，因为结果将是 NULL 。

Ring buffers

更多有意义的内存调试信息可以通过 sys.dm_os_ring_buffers 的 ring buffers DMV 获取。每个 ring buffer 保留了之前几次某种类型的通知。指定 ring buffer 的详细信息将在下面描述。

RING_BUFFER_RESOURCE_MONITOR

你可以使用从资源监视器的通知识别内存改变的状态。在内部， SQL Server 有一个监视不同内存压力的架构。当内存状态改变，资源监视器任务生成一个通知。这个通知用于内部组件根据内存状态调整它们内存使用并通过 sys.dm_os_ring_buffers DMV 来暴露，如下列代码所示。

select record

from sys.dm_os_ring_buffers

where ring_buffer_type = 'RING_BUFFER_RESOURCE_MONITOR'

结果类似于

<Notification>RESOURCE_MEMPHYSICAL_LOW</Notification>

</ResourceMonitor>

</MemoryNode>

</MemoryRecord>

</Record>

从这些记录来看，你可以减少服务器收到的低物理内存的通知。你也可以查看内存总量（ KB 为单位）。你可以通过使用 SQL Server 的 XML 能力来查询这些信息，例如下列代码。

select

x.value('(//Notification)[1]', 'varchar(max)') as [Type],

x.value('(//Record/@time)[1]', 'bigint') as [Time Stamp],

x.value('(//AvailablePhysicalMemory)[1]', 'int') as [Avail Phys Mem, Kb],

x.value('(//AvailableVirtualAddressSpace)[1]', 'int') as [Avail VAS, Kb]

from

(select cast(record as xml)

from sys.dm_os_ring_buffers

where ring_buffer_type = 'RING_BUFFER_RESOURCE_MONITOR') as R(x)

order by

[Time Stamp] desc

上面收到了低内存的通知，缓存池重新计算 target 。注意 target 数量保持在指定的 min server memory 和 max server memory 选项限制中。如果缓存池中心的提交比当前的提交缓存还小，缓存池将开始收缩直到外部内存压力被移除。注意，当运行在启用 AWE 时 SQL Server 2000 不是这样来缓解物理内存压力的。

RING_BUFFER_OOM

下列代码示例，展示了 ring buffer 中包含预示服务器内存不足的记录。

select record

from sys.dm_os_ring_buffers

where ring_buffer_type = 'RING_BUFFER_OOM'

结果类似于：

<OOM>

<Action>FAIL_VIRTUAL_COMMIT</Action>

</OOM>

这条记录告诉我们那个操作失败了（提交，保留或页面分配）并表明了请求的内存数量。

RING_BUFFER_MEMORY_BROKER and Internal Memory Pressure

当监测到内部内存压力时，为组件在缓存池分配内存的低内存通知将被打开。打开低内存通知允许从使用缓存池的高速缓存和其他组件中回收页面。

内部内存压力可以通过调整 max server memory 选项或当 stolen 页面与缓存池的比例超过 80% 时触发。

内部内存压力通知 (‘Shrink’) 能通过使用下列代码查询 ring buffer 的调用来发现。

select

x.value('(//Record/@time)[1]', 'bigint') as [Time Stamp],

x.value('(//Notification)[1]', 'varchar(100)') as [Last Notification]

from

(select cast(record as xml)

from sys.dm_os_ring_buffers

where ring_buffer_type = 'RING_BUFFER_MEMORY_BROKER') as R(x)

order by

[Time Stamp] desc

RING_BUFFER_BUFFER_POOL

ring buffer 将包含预示严重的缓存池失败的记录，包括缓存池溢出的条件。

select record

from sys.dm_os_ring_buffers

where ring_buffer_type = 'RING_BUFFER_BUFFER_POOL'

结果类似于：

< BufferPoolFailure id="FAIL_OOM">

</ BufferPoolFailure >

这条记录告诉我们出现了什么样的失败 (FAIL_OOM, FAIL_MAP, FAIL_RESERVE_ADJUST, FAIL_LAZYWRITER_NO_BUFFERS) 基当时的缓存池状态。

内部虚拟内存压力

VAS 的占用可以使用 sys.dm_os_virtual_address_dump DMV 来跟踪。 VAS 汇总可以使用下列视图来查询。

-- virtual address space summary view

-- generates a list of SQL Server regions

-- showing number of reserved and free regions of a given size

CREATE VIEW VASummary AS

SELECT

Size = VaDump.Size,

Reserved = SUM(CASE(CONVERT(INT, VaDump.Base)^0) WHEN 0 THEN 0 ELSE 1 END),

Free = SUM(CASE(CONVERT(INT, VaDump.Base)^0) WHEN 0 THEN 1 ELSE 0 END)

FROM

(

--- combine all allocation according with allocation base, don't take into

--- account allocations with zero allocation_base

SELECT

CONVERT(VARBINARY, SUM(region_size_in_bytes)) AS Size,

region_allocation_base_address AS Base

FROM sys.dm_os_virtual_address_dump

WHERE region_allocation_base_address <> 0x0

GROUP BY region_allocation_base_address

UNION

--- we shouldn't be grouping allocations with zero allocation base

--- just get them as is

SELECT CONVERT(VARBINARY, region_size_in_bytes), region_allocation_base_address

FROM sys.dm_os_virtual_address_dump

WHERE region_allocation_base_address = 0x0

)

AS VaDump

GROUP BY Size

下列查询可以用于访问 VAS 状态

-- available memory in all free regions

SELECT SUM(Size*Free)/1024 AS [Total avail mem, KB]

FROM VASummary

WHERE Free <> 0

-- get size of largest availble region

SELECT CAST(MAX(Size) AS INT)/1024 AS [Max free size, KB]

FROM VASummary

WHERE Free <> 0

如果最大可用区域小于 4MB ，我们可能遇到了 VAS 压力。 SQL Server 2005 监视和响应 VAS 压力。 SQL Server 2000 不会监视从 VAS 带来的压力，但是当出现虚拟内存不足错误是，它会清理高速缓存。

一般的内存错误排错步骤

下列是一些常规步骤，有助于你排除内存错误。

1. 验证是否服务器运行在外部内存压力。如果出现外部内存压力，尝试先解决它，然后再看是否依然存在这个问题或错误。

2. 开始收集性能计数器： SQLServer: Buffer Manager, SQLServer: Memory Manager

3. 确认内存配置参数 (sp_configure ) ， min memory per query ， min/max server memory ， awe enabled 和 Lock Pages in Memory 权利。观察不正常的值。纠正配置。提供为 SQL Server 2005 增加内存的理由。

4. 检查所有可能影响服务器的非默认 sp_configure 参数。

5. 检查内部内存压力。

6. 当你见到内存错误消息时，观察 DBCC MEMORYSTATUS 输出和改变的方法。

7. 检查负载（并发会话数量，并发执行查询数量）。

内存错误

701 - There is insufficient system memory to run this query.

原因

这是服务器内存不足的典型现象。它预示了内存分配失败。它可以有多种原因导致，包括在当前工作负载上的内存提示。通过增加 SQL Server 2005 需要的内存和一些配置上的设置（例如 max server memory 选项）用户可能会看到这种错误。通常失败的事务不是因为这个错误。

排错

不论是否错误是持续的和可重复的（同样状态）或是随机的（显示为随机的不同状态），当你看到这个错误时你需要研究服务器内存分布。当这个错误出现时，可能导致诊断查询失败。可以开始从外部进行评估。接下来的步骤在一般的内存错误排错步骤中描述。

可能的解决方案包括：除去外部内存压力；增加 max server memory 设置。使用下列语句释放缓存 DBCC FREESYSTEMCACHE ， DBCC FREESESSIONCACHE ，或 DBCC FREEPROCCACHE 。如果问题还是出现，则应减少工作负载。

802 - There is insufficient memory available in the buffer pool.

原因

这个错误不是引起内存不足的必要条件。它可能预示缓存池内存被其他的一些组件使用。在 SQL Server 2005 中很少出现。

排错

使用常规的排错步骤和 701 错误的建议。

8628 - A time out occurred while waiting to optimize the query. Rerun the query.

原因

这个错误指出查询编译过程失败因为它不能获取完成编译所需的内存。当查询经历了这种编译过程，包括解析，代数求解和优化，它的内存需求会增加。因而查询将和其他的查询争夺内存资源。如果查询超过的预定的超时时间（查询增加内存的占用）当等待资源时，这个错误会返回。这种情况的最可能的原因是在服务器上出现很多大型查询的编译。

排错

1. 在常规的排错步骤后查看是否服务器内存占用正常。

2. 检查负载。确认被不同组件占用的内存数量（具体信息请参考内部物理内存压力）。

3. 检查 DBCC MEMORYSTATUS 输出的在每个 gateway 上的等待数量（这些信息将告诉你是否有其他的查询在占用大量内存）。

Small Gateway Value

------------------------------ --------------------

Configured Units 8

Available Units 8

Acquires 0

Waiters 0

Threshold Factor 250000

Threshold 250000

(6 row(s) affected)

Medium Gateway Value

------------------------------ --------------------

Configured Units 2

Available Units 2

Acquires 0

Waiters 0

Threshold Factor 12

(5 row(s) affected)

Big Gateway Value

------------------------------ --------------------

Configured Units 1

Available Units 1

Acquires 0

Waiters 0

Threshold Factor 8

4. 尽可能减少工作负载。

8645 - A time out occurred while waiting for memory resources to execute the query. Rerun the query.

原因

这个错误指出在服务器上有很多内存敏感的查询被同时执行。使用排序（ ORDER BY ）和连接的查询可以在执行过程中会占用大量的内存。如果有高度并行或如果查询操作一个非联合索引的分区表时，查询内存需求会有很大的增加。无法或取所需内存资源的查询在预先确定的超时时间时（默认，超时是 25 倍的评估查询时间或 sp_configure 设置的 ’query wait’ ）将收到这个错误。通常，收到这个错误的查询占用内存的那个查询。

排错

1. 根据一般步骤评估内存的情况。

2. 识别有问题的查询：确认有大量的在分区表上的查询，检查是否他们使用非联合索引，检查是否有大量包括连接和排序的查询。

3. 检查 sp_configure 参数中 degree of parallelism 和 min memory per query 。尝试降低并行度并验证是否 min memory per query 没有设置很高的值。如果设置了很高的值，即使少量的查询也会占用指定查询的数量。

4. 为了找到查询是否等待 RESOURCE_SEMAPHORE ，请查看本白皮书中阻塞的部分。

8651 - Could not perform the requested operation because the minimum query memory is not available. Decrease the configured value for the 'min memory per query' server configuration option.

原因

原因和 8645 错误类似；它也预示服务器内存过低。 min memory per query 太高也可能导致这个错误。

排错

1. 根据一般内存错误排错步骤。

2. 验证 sp_configure min memory per query 选项设置。

I/O 瓶颈

SQL Server 性能非常依赖于 I/O 子系统。除非你的数据库适合物理内存， SQL Server 经常地会有数据库页面进出缓存池。这样就发生了实质的 I/O 流量。同样，在事务被明确的提交前，日志记录需要写入磁盘。 SQL Server 为各种目的可以使用 tempdb ，例如存储中间结果，排序，保持行的版本或其他。所以好的 I/O 子系统对于 SQL Server 性能非常重要。

除了当事务需要回滚时，访问日志文件是非常频繁的，而包括访问数据文件，包括 tempdb ，是随机访问的。所以作为一个通常的规则，为获取更好的性能，你最好将日志文分布不到不同的物理磁盘。本文重点于不是在如何配置你的 I/O 设备，而是描述识别你的 I/O 瓶颈的方法。一旦识别了 I/O 瓶颈，你也许需要重新配置你的 I/O 子系统。

如果你有一个慢速的 I/O 子系统，你的用户会遇到性能问题，例如很长的响应时间，任务由于超时而中断。

你可以使用下列性能参数来识别 I/O 瓶颈。注意，如果你的收集间隔过长，这些平均值可能会倾向于过小。例如，很难通过 60 秒一次的快照获取正确的 I/O 值。所以，你不能依赖于一个计数器来确定瓶颈；要考虑多个技术起来反复校验。

· PhysicalDisk Object: Avg. Disk Queue Length 表现在采样周期中所选择的物理磁盘队列中的物理读和写平均请求数量。如果你的 I/O 系统过载，更多的读 / 写操作将被等待。如果在很少使用 SQL Server 时，你的磁盘队列长度经常超过 2 ，这样你可能遇到了 I/O 瓶颈

· Avg. Disk Sec/Read 是平均每次从磁盘读取数据的时间

小于 10 ms – 很好

在 10 - 20 ms 之间 - 正常

在 20 - 50 ms 之间 - 缓慢，需要注意

大于 50 ms – 严重的 I/O 瓶颈

· Avg. Disk Sec/Write 是平均每次从磁盘读取数据的时间。请引用之前的指导数据。

· Physical Disk: %Disk Time 是所选磁盘驱动器用于服务于读或写请求的总共时间的百分比。一般推荐是如果该值大于 50% ，则表现为 I/O 瓶颈。

· Avg. Disk Reads/Sec 表现磁盘上读操作的速度。你需要确认该值小于 85% 的磁盘设计能力。磁盘访问时间指数高于能力的 85% 。

· Avg. Disk Writes/Sec 表现在磁盘上写操作的速度。确认该值小于 85% 的磁盘设计能力。磁盘访问时间指数高于能力的 85% 。

当使用以上计数器，你在使用 RAID 配置时，你需要使用下列公式调整结果值。

Raid 0 -- I/Os per disk = (reads + writes) / number of disks
Raid 1 -- I/Os per disk = [reads + (2 * writes)] / 2
Raid 5 -- I/Os per disk = [reads + (4 * writes)] / number of disks
Raid 10 -- I/Os per disk = [reads + (2 * writes)] / number of disks

例如，你有带有 2 个物理磁盘的 RAID-1 系统和下列计数器值。

Disk Reads/sec 80
Disk Writes/sec 70
Avg. Disk Queue Length 5

这种情况下，你遇到了 (80 + (2 * 70))/2 = 110 I/Os per disk ，你的磁盘队列长度为 5/2=2.5 ，表明系统接近于 I/O 瓶颈。

你也可以通过考察锁等待来识别 I/O 瓶颈。当数据页通过读或写访问并且在缓存池中页不可用时，这些锁等待占用了大量的物理 I/O 等待。当页面没有在缓存池中找到时，一个异步 I/O 请求被发出， I/O 的状态是被选中的。如果 I/O 已经完成，工作进程处理正常。否则，依赖于请求的类型，它会等待 PAGEIOLATCH_EX 或 PAGEIOLATCH_SH 。从下列的 DMV 查询可以用于找到 I/O 锁等待的统计。

Select wait_type,

waiting_tasks_count,

wait_time_ms

from sys.dm_os_wait_stats

where wait_type like 'PAGEIOLATCH%'

order by wait_type

wait_type waiting_tasks_count wait_time_ms signal_wait_time_ms

-----------------------------------------------------------------------

PAGEIOLATCH_DT 0 0 0

PAGEIOLATCH_EX 1230 791 11

PAGEIOLATCH_KP 0 0 0

PAGEIOLATCH_NL 0 0 0

PAGEIOLATCH_SH 13756 7241 180

PAGEIOLATCH_UP 80 66 0

下划线的是有兴趣的锁等待。当 I/O 完成时，工作者被放置到可用队列中。从 I/O 完成到工作者被实际的调度的时间在 signal_wait_time_ms 列说明。如果你得 waiting_task_counts and wait_time_ms 偏离正常值太多，你可以识别为 I/O 问题。为了这样，通过使用性能计数器和关键 DMV 建立正常时运行时的性能基线就十分重要。 wait_types 可以识别是否你的 I/O 子系统处在瓶颈状态，但是他们不能提供任何关于物理磁盘遇到问题的信息。

你可以使用下列 DMV 查询找到当前等待的 I/O 请求。你可以周期性的执行这些请求检查 I/O 子系统的健康情况，并找到涉及 I/O 瓶颈的物理磁盘。

select

database_id,

file_id,

io_stall,

io_pending_ms_ticks,

scheduler_address

from sys.dm_io_virtual_file_stats(NULL, NULL)t1,

sys.dm_io_pending_io_requests as t2

where t1.file_handle = t2.io_handle

下面是示例的输出。它展示当时在给定的数据库上有 3 个未决定的 I/O 。你可以使用 database_id 和 file_id 来找到映射的物理磁盘文件。 io_pending_ms_ticks 表现了所有等待在未决定队列中的个别的 I/O 。

Database_id File_Id io_stall io_pending_ms_ticks scheduler_address

----------------------------------------------------------------------

6 1 10804 78 0x0227A040

6 2 101451 31 0x02720040

解决

当你识别到 I/O 瓶颈时，你可以下列方法解决：

· 检查 SQL Server 的内存配置。如果 SQL Server 配置的内存不足，将导致更多的 I/O 开销。你可以考察下列计数器来识别内存压力。

· Buffer Cache hit ratio

· Page Life Expectancy

· Checkpoint pages/sec

· Lazywrites/sec

更多关于内存压力的信息，请查看内存瓶颈。

· 增加 I/O 带宽。

· 为当前的磁盘阵列添加更多的物理驱动器和 / 或使用更快的磁盘代替当前的磁盘。这帮助提升读写访问时间。但是添加的磁盘数量不能比当前 I/O 控制器所支持的数量大。

· 添加快速或额外的 I/O 控制器。考虑为当前的控制器添加更多的缓存（如果有可能）

· 考察执行计划并查看那个计划占用了更多的 I/O 。这样可以找到更好的查询进化（例如，索引）可以减少 I/O 。如果缺少索引，你可以运行 Database Engine Tuning Advisor 找到缺失的索引。

下列 DMV 查询能用于找到那个批处理 / 请求生成了最多的 I/O 。你将注意到我们没有说明物理写入。如果你了解数据库如何工作，这也没有问题。请求中的 DML/DDL 并不是直接将数据页写入磁盘。只有通过提交事务语句才能触发将页面物理写入磁盘。通常物理写通过 Checkpoint 语句完成或通过 SQL Server lazy writer 完成。下列 DMV 查询可以用于找到生成最多 I/O 的 5 个请求。调整这些查询，使他们使用较少的逻辑度来完成操作，这样可以减少在缓存池上的压力。这允许其他的查询在缓存池中找到重复执行中所需要的重复数据（而不是通过物理 I/O 完成）。因此整体系统性能被提高了。

select top 5

(total_logical_reads/execution_count) as avg_logical_reads,

(total_logical_writes/execution_count) as avg_logical_writes,

(total_physical_reads/execution_count) as avg_phys_reads,

Execution_count,

statement_start_offset as stmt_start_offset,

sql_handle,

plan_handle

from sys.dm_exec_query_stats

order by

(total_logical_reads + total_logical_writes) Desc

当然你可以改变查询或取数据的不同视角。例如，在一个查询中声称最多 I/O 请求的 5 个请求，你可以通过下列表达式排序：

(total_logical_reads + total_logical_writes)/execution_count

除此之外，你可能希望通过物理 I/O 排序或其他的操作。然而，逻辑读 / 写数量来帮助决定是否查询选择的计划被优化过。例如，它可以做一个表扫描而不是使用索引。一些查询，例如使用嵌套循环连接可能有很高的逻辑计数器但是能更好的适应缓存，因为他们重新访问了同样的页面。

例如 : 让我们考察下列 2 个有 2 个 SQL 查询的批，每个表由 1000 行并且行大小大于 8000 （每页 1 行）。

批 -1

select

c1,

from t1 INNER HASH JOIN t2 ON t1.c1 = t2.c4

order by c2

批 -2

select * from t1

为了这个示例，在运行 DMV 查询前，我们利用下列命名清理了缓存池和过程的缓存。

checkpoint

dbcc freeproccache

dbcc dropcleanbuffers

这是 DMV 查询的输出。你将注意到 2 行表现的这 2 个批。

Avg_logical_reads Avg_logical_writes Avg_phys_reads Execution_count stmt_start_offset

--------------------------------------------------------------------------------------

2794 1 385 1 0

1005 0 0 1 146

sql_handle plan_handle

----------------------------------------------------------------------------

0x0200000099EC8520EFB222CEBF59A72B9BDF4DBEFAE2B6BB

x0600050099EC8520A8619803000000000000000000000000

0x0200000099EC8520EFB222CEBF59A72B9BDF4DBEFAE2B6BB

x0600050099EC8520A8619803000000000000000000000000

你将注意到第 2 个批只发生了逻辑读但是没有物理 I/O 。这是因为需要的数据已经由第 1 个查询缓存到了高速缓存中（有充分的内存）。

你可以通过下列查询或取执行查询的文本。

select text

from sys.dm_exec_sql_text(

0x0200000099EC8520EFB222CEBF59A72B9BDF4DBEFAE2B6BB)

Here is the output.

select

c1,

from t1 INNER HASH JOIN t2 ON t1.c1 = t2.c4

order by c2

你也可以通过下列语句找到独立语句的字符串。

select

substring(text,

(<statement_start_offset>/2),

(<statement_end_offset> -<statement_start_offset>)/2)

from sys.dm_exec_sql_text (0x0200000099EC8520EFB222CEBF59A72B9BDF4DBEFAE2B6BB)

statement_start_offest 和 statement_end_offset 的值需要除以 2 来补偿 SQL Server 使用 Unicode 来存储这种数据的。 statement_end_offse 值为 -1 指出语句先前到了批的最后。而 substring() 函数不识别 -1 ，并将其作为非法值。使用 (<statement_end_offset> -<statement_start_offset>)/2 , 代替 -1 ，一个需要输入 64000 的值，来确认语句覆盖了所有的情况。通过这种方法，长时间运行或资源消费语句可以被过滤出大型的存储过程或批。

同样的你可以运行下列查询，找到查询计划确定是否当选择了较差的计划时有大量的 I/O 。

select *

from sys.dm_exec_query_plan

(0x0600050099EC8520A8619803000000000000000000000000)

Tempdb

Tempdb 用于全局存储内部或用户对象，临时表，对象和在 SQL Server 操作是创建的存储过程。每个 SQL Server 实例只有 1 个单一的 tempdb 。它可能是一个性能和磁盘空间的瓶颈。有限可用空间和过多的 DDL/DML 会使 Tempdb 超过负载。这能导致运行在同一个服务器中的其他无关应用变得运行缓慢或失败。

下面列出一些 tempdb 的常规问题：

· Tempdb 磁盘空间不足

· 由于 tempdb 中的 I/O 瓶颈，导致查询运行缓慢。这在 I/O瓶颈部分提到过。

· 过多 DDL 操作导致系统表的瓶颈

· 分配争夺

Before we start diagnosing problems with tempdb , let us first look at how the space in tempdb is used. It can be grouped into four main categories. 当开始调试 tempdb 问题前，让我们先看一下在 tempdb 中如何使用空间。它可以分为 4 个主要的类别。

用户对象	这些对象被用户会话显示创建并在系统目录中被跟踪。这包括： <!-- [if !supportLists]-->· <!-- [endif]-->表和索引 <!-- [if !supportLists]-->· <!-- [endif]-->全局临时表 (##t1) 和索引 <!-- [if !supportLists]-->· <!-- [endif]-->本地临时表 (#t1) 和索引 <!-- [if !supportLists]-->· <!-- [endif]-->会话范围 <!-- [if !supportLists]-->· <!-- [endif]-->存储过程范围内创建 <!-- [if !supportLists]-->· <!-- [endif]-->表变量 (@t1). <!-- [if !supportLists]-->· <!-- [endif]-->会话范围 <!-- [if !supportLists]-->· <!-- [endif]-->存储过程范围内创建
内部对象	这有语句范围的对象，通过 SQL Server 处理的查询创建和销毁。这些对象不能被系统目录跟踪。这包括： <!-- [if !supportLists]-->· <!-- [endif]-->工作文件 (hash join) <!-- [if !supportLists]-->· <!-- [endif]-->排序 <!-- [if !supportLists]-->· <!-- [endif]-->工作表 ( 游标 , 池和临时大对象数据类型 (LOB) 存储 ) 作为优化，当工作表被删除，一个 IAM 页和一个扩展被保存到一个新的工作表。这有 2 个例外：临时 LOB 存储是批范围的和游标工作表示会话范围的
版本存储	用于存储行版本。 MARS ，在索引因操作，触发器和快照隔离级别都是基于行版本。这是 SQL Server 2005 中新的特性。
可用空间	这表示在 tempdb 数据库可用的磁盘空间。

tempdb 使用的总空间等于用户对象加内部对象加版本存储 + 可用空间。

这个可用空间等于性能计数器中 tempdb 的可用空间。

监视 tempdb 空间

阻止问题更好的方法是随后马上解决它。你可以使用下列性能监视器来监视使用中的 tempdb 空间。

· Free Space in tempdb (KB). 这个计数器以 KB 为单位跟踪空闲空间的数量。管理员可以使用这个计数器确定是否 tempdb 运行在较低的磁盘空间上。

然而，识别前面所定义的不同类别如何使用在 tempdb 中使用的磁盘空间，是很有兴趣的并有效率的。

下列查询返回了 tempdb 用户使用的空间和内部组件对象。当前它提供了仅有 tempdb 中的信息。

Select

SUM (user_object_reserved_page_count)*8 as user_objects_kb,

SUM (internal_object_reserved_page_count)*8 as internal_objects_kb,

SUM (version_store_reserved_page_count)*8 as version_store_kb,

SUM (unallocated_extent_page_count)*8 as freespace_kb

From sys.dm_db_file_space_usage

Where database_id = 2

这里有一些示例的输出（空间使用 KB 为单位）。

user_objets_kb internal_objects_kb version_store_kb freespace_kb

---------------- -------------------- ------------------ ------------

8736 128 64 448

注意这些技术不包括其中的混合扩展。页面在混合扩展中可以被分配个别用户和内部对象。

磁盘空间问题排错

用户对象，内部对象和存储的版本可以都可以导致在 tempdb 中的空间问题。这节我们会考虑针对每个类别如何排错。

用户对象

因为用户对象不被特定的会话拥有，你需要理解创建该对象的应用程序的规范并调整需要的 tempdb 大小。你可以通过执行 exec sp_spaceused @objname='<user-object>' 来找到个别用户对象使用的。例如，你可以运行下列脚本枚举所有 tempdb 对象。

DECLARE userobj_cursor CURSOR FOR

select

sys.schemas.name + '.' + sys.objects.name

from sys.objects, sys.schemas

where object_id > 100 and

type_desc = 'USER_TABLE'and

sys.objects.schema_id = sys.schemas.schema_id

open userobj_cursor

declare @name varchar(256)

fetch userobj_cursor into @name

while (@@FETCH_STATUS = 0)

begin

exec sp_spaceused @objname = @name

fetch userobj_cursor into @name

end

close userobj_cursor

版本存储

SQL Server 2005 提供了行版本架构用于实现一些特性。如下列出了使用行版本架构的特性。更多关于下列特性的信息，请参考 SQL Server 联机丛书。

· 触发器

· MARS

· 联机索引

· 基于行版本隔离级别：需要在数据库级设置选项

行版本需要跨会话共享。当行版本被回收时，行版本的创建者没有控制权。你需要找到并杀掉阻止行版本清理的运行最长的事务。

下列查询返回依赖于版本存储运行最长的 2 个事务。

select top 2

transaction_id,

transaction_sequence_num,

elapsed_time_seconds

from sys.dm_tran_active_snapshot_database_transactions

order by elapsed_time_seconds DESC

这是示例的输入，显示了序列号为 3 ，事务 ID 为 8609 的事务已经运行了 6523 秒。

transaction_id transaction_sequence_num elapsed_time_seconds

-------------------- ------------------------ --------------------

8609 3 6523

20156 25 783

因为第 2 个事务运行了相对短的时间，你可以通过杀掉第 1 个事务来释放大量的版本存储。可是，没有方法能评估通过杀掉进能释放的版本空间。你也许需要杀掉一些事务来释放更多的空间。

你可以通过改变用于版本存储的 tempdb 属性或通过尽可能的消除在快照隔离级别的长事务，或在 read-committed-snapshot 下运行的长查询来减轻这个问题。你能使用下列公式粗略的评估行版本存储的大小。

[Size of version store] = 2 * [version store data generated per minute] * [longest running time (minutes) of the transaction]

在所有使用了基于孤立级别行版本，为一个事物每分钟生成版本存储的数据和每分钟生成的日志一样。然而这也有一些异常：只有更新的差异部分生成日志；如果使用了批量导入操作并且恢复模式不是完全恢复时，新插入的数据行不依赖日志，则不被记录版本。

你也可以使用 Version Generation Rate 和 Version Cleanup Rate 性能计数器来调整你的计算。如果 Version Cleanup Rate 为 0 ，这暗示着有长时间运行的事务阻止版本存储的清理。

附带地，在产生 tempdb 空间不足错误前， SQL Server 2005 会做最后一次尝试强制版本存储收缩。在这个收缩过程中，没有生成行版本运行最长的事务会被标识为牺牲者。这可以释放他们使用的版本存储。在错误日志中为牺牲的事务生成一个消息 3967 ，它能不再从版本存储中读取行版本或创建新的版本存储。如果收缩版本存储成功，这样在 tempdb 中会有更多的可用空间。否则 tempdb 将耗尽内存。

内部对象

内部对象在每条语句中被创建和销毁，除非想在前面所描述的。如果你注意到有大量的 tempdb 空间分配，你将需要了解那个会话或任务占用了空间，然后进肯能做一些矫正的操作。

SQL Server 2005 提供了 2 个额外的 DMV ： : sys.dm_db_session_space_usage 和 sys.dm_db_task_space_usage 来跟踪分配给个别会话和任务所用的 tempdb 空间。尽管任务运行在会话的上下文，当任务完成后，任务使用的空间还会被占用。你可以使用下列查询来找到为内部对象分配最多的会话。注意这个查询只包括在会话中已完成的任务。

select

session_id,

internal_objects_alloc_page_count,

internal_objects_dealloc_page_count

from sys.dm_db_session_space_usage

order by internal_objects_alloc_page_count DESC

你可以使用下列查询找到分配对象最多的会话，包括正在运行的任务。

SELECT

t1.session_id,

(t1.internal_objects_alloc_page_count + task_alloc) as allocated,

(t1.internal_objects_dealloc_page_count + task_dealloc) as

deallocated

from sys.dm_db_session_space_usage as t1,

(select session_id,

sum(internal_objects_alloc_page_count)

as task_alloc,

sum (internal_objects_dealloc_page_count) as

task_dealloc

from sys.dm_db_task_space_usage group by session_id) as t2

where t1.session_id = t2.session_id and t1.session_id >50

order by allocated DESC

这是示例的输出。

session_id allocated deallocated

---------- -------------------- --------------------

52 5120 5136

51 16 0

一旦你隔离出生成大量对象分配的任务或会话，你能找到任务的那条 Transact-SQL 语句和它的查询计划来做更详细地分析。

select

t1.session_id,

t1.request_id,

t1.task_alloc,

t1.task_dealloc,

t2.sql_handle,

t2.statement_start_offset,

t2.statement_end_offset,

t2.plan_handle

from (Select session_id,

request_id,

sum(internal_objects_alloc_page_count) as task_alloc,

sum (internal_objects_dealloc_page_count) as task_dealloc

from sys.dm_db_task_space_usage

group by session_id, request_id) as t1,

sys.dm_exec_requests as t2

where t1.session_id = t2.session_id and

(t1.request_id = t2.request_id)

order by t1.task_alloc DESC

这是示例的输出。

分享到：

关于破解windows开机密码 | 第几次失败呢？

2010-07-30 09:27
浏览 1400
评论(0)
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客 更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论

SQL Server 2005性能排错

SQL Server 2005 性能排错

版权声明

目录

CPU 瓶颈

内存瓶颈

Windows 地址扩展和 SQL Server

外部物理内存压力

内部物理内存压力

一般的内存错误排错步骤

I/O 瓶颈

Tempdb

监视 tempdb 空间

评论

发表评论

相关推荐

最近访客更多访客>>