Ken Henderson（1967-2008）SQL Sewer世界级权威。生前供职于微软SQL Sewer开发组。以Gurus Guide系列经典著作和SQLDiag等工具享誉业界。
　　创作团队，来自SQL Server开发小组的7位开发人员和来自微软客户支持服务机构的3位支持专家，他们都有丰富的开发经验，熟悉SQL Sewer源代码。

　　本书帮助你解决众多数据库引擎方面的问题，每一章从关键的SQL Server 组件入手，然后探讨用户遇见的常见问题，并给出解决方案。本书的主要内容包括等待和阻塞、数据毁坏和恢复、内存、过程缓存、查询进程等。本书的作者都是来自微软公司SQL Server 开发团队和客户支持服务部门的支持专家。在你的SQL Server 系统遇到问题时，本书将变得不可或缺。
　　本书适合数据库管理员和数据库开发人员阅读。
　　作者简介：
　　Ken Henderson（1967-2008）SQL Sewer世界级权威。生前供职于微软SQL Sewer开发组。以Gurus Guide系列经典著作和SQLDiag等工具享誉业界。
　　创作团队  来自SQL Server开发小组的7位开发人员和来自微软客户支持服务机构的3位支持专家，他们都有丰富的开发经验，熟悉SQL Sewer源代码。

　　“本书的内容是其他任何博客、网站和图书都没有的。系统出问题时。它将成为你的救命稻草。”
　　——Pinal Dave，微软MVP
　　“此书得非常好，涵盖了对大量复杂问题进行故障排查的详细解析。我认为每一位优秀的MSSQL DBA都应该拥有。
　　——Amazon.com评论

　　第8章　SQLOS和调度问题
　　Sameer Tejani
　　本章内容
　　●  SQLOS架构
　　●  配置及故障排查
　　●  进阶阅读
　　当今的电脑架构日益多样化，并且难以发挥其最大性能及可扩展性。昨天的研究成果今天就被广泛应用到行业中。看看早些年，多处理器计算机非常罕见。而今，多CPU不再是大企业的特权了。市面上已经有多核CPU了，家用电脑也拥有了多处理器特性。可以预见在未来市场中，拥有多个CPU和大量内存的计算机将成为主流。像非统一内存访问（Non-Uniform Memory Access，简称cc-NUMA）之类的计算机架构的市场份额将持续增长。一些处理器厂商已经为CPU构建了私有内存总线，从而在低端架构上开启cc-NUMA。
　　企业级硬件设计的趋势变得更戏剧化。今天的企业计算机与之前的超级计算机看起来差不多。现在有64个CPU和512GB内存的计算机不再稀奇。如按现在的趋势发展下去，很快256个物理/逻辑CPU及1TB以上内存的配置将统治企业级装置。随着CPU数量的增长，硬件厂商越来越偏向于cc-NUMA架构，而不是对称多处理（Symmetrical Multi-Processing，SMP）。现今的市场中，cc-NUMA计算机已经成为厂商在开发16个以上CPU的平台时的标准。追求大内存和多CPU并不是企业级市场上唯一的趋势。硬件厂商正尝试最小化系统宕机时间，并通过引入对热插拔内存和CPU的支持来扩展其系统的灵活性。热插拔使得系统管理员可以随心所欲地重新配置硬件，而不用重启系统。
　　处理能力和可用的内存数据持续按照摩尔定律的速度增长，但内存访问延迟没能跟上这个步伐。硬件厂商一直致力于改善CPU内存处理能力。他们构建了多层缓存，并对指令级并发、弱一致性模型以及预存取增加了更多支持。
　　对于正在设计面向性能的、提供弹性管理支持的可伸缩应用程序的软件工程师来说，理解并利用这些特性变得非常重要。
　　为了充分利用这一新规范，我们引入了一个新的层——SQLOS，以便将操作系统从SQL Server引擎中抽象出来，并提供服务以最大限度利用这些架构，同时保留现有架构。SQLOS对服务器的其他部分提供用户级的操作系统服务，这就是“SQLOS”名称的由来。SQL Server引擎中的组件利用SQLOS提供的服务，来调度单个或者多个任务、分配内存等。
　　SQLOS有几个主要的要求。SQLOS层必须具有高度可配置性，以便SQL Server在低/高端硬件平台上都可以运行。SQLOS层必须对上层开发者屏蔽复杂性，同时为低层开发者提供宽广的灵活性。另外，它还要在新的硬件上扩展操作系统的服务，即使真正的底层OS对这些服务的支持有限。SQLOS目前由以下几部分组成。
　　●  调度子系统；
　　●  内存管理；
　　●  错误/异常处理；
　　●  死锁检测；
　　●  作为外部组件的宿主。
　　8.1  SQLOS架构
　　硬件趋势显示本地性探测是允许应用程序可伸缩性的关键，尤其对于不同类型的硬件而言。有几种不同的方法可以探测到本地性。要达到这个目的，常用的一个方法是创建一个分层的对象家族，其中每个对象提供对本层来说有意义的本地—中央的功能及服务。
　　SQLOS设计的主要要求之一就是允许程序的可伸缩性。SQLOS必须在高端和低端硬件上都允许可伸缩性。由于本地性探测是满足伸缩性需求的方法之一，并且本地性探测可以逐层实现，SQLOS就选用了层级结构。SQLOS设计中主要的对象有结点、调度者和任务。每个对象在其所在的层中探测最大化本地状态、并最小化全局状态的功能。SQLOS尝试去尽可能最小化全局状态。图8-1描述了在有两个结点、每个结点有两个CPU的cc-NUMA硬件上的SQLOS配置（见图8-1）。
　　图8-1  cc-NUMA硬件上的SQLOS
　　8.1.1  内存和CPU结点
　　SQLOS层级中的第一批对象是内存结点。将内存结点想象为绑定到一个CPU或者一组CPU上的内存之外的一个原始的抽象物。不同的硬件配置在CPU和内存之间有不同的关系。比如SMP架构在所有CPU之间共享内存，而cc-NUMA架构在一组CPU之间共享内存。内存共享可以描述为内存或者归属关联，而它代表内存本地性。内存结点的目标是在cc-NUMA或者类cc-NUMA的硬件上提供内存管理本地性。
　　CPU结点是SQLOS层次中的下一个对象。CPU结点提供CPU逻辑组。在SMP架构中，这就是单个CPU结点。默认情况下，cc-NUMA架构下这表示硬件平台所有的CPU结点。CPU结点提供引用本地性以及调度关联。它们使开发者可以将相关的任务指派给彼此相邻的CPU。
　　内存结点与CPU结点之间的关系很重要。CPU结点是内存结点的一个子集。如图8-1所描述的，一个CPU结点只能与一个内存结点有关，但一个内存结点可以与多个CPU结点相关。这个规则说明了两个问题：首先，它简化了软件模型，并结出一个定义明确的结点间关系；其次，它使SQLOS在cc-NUMA和高端SMP硬件平台上都能够构建不同的结点配置。
　　除了精确的硬件配置，SQLOS还可以被配置为使用逻辑CPU结点。由于历史遗留因素，如果系统的配置如果不能完全映射到真正的硬件配置，就被称为Soft NUMA。Soft NUMA这个概念非常强大。它使在SQLOS上构建的应用程序服务器，可以利用硬件或者应用程序域本身所提供的不同类型的本地性。比如，一个有两个双核CPU的SMP系统，可以被配置为包含两个CPU结点的单个内存结点，其中每个结点管理两个核。图8-2描述了这种配置。Soft NUMA的优点还包括一种测试SQLOS和SQL Server的cc-NUMA支持的方法，而不需要真正昂贵的硬件。
　　图8-2  SMP硬件上的SQLOS
　　每个CPU结点包含一组调度器，结点中的每个CPU都绑定了一个调度器。如图8-3所示，一个CPU结点除了调度器之外，还有一个与其相关的I/O完成端口（I/O Completion Port）。一个I/O完成端口可以绑定到多个I/O设备，比如网卡和磁盘。每个结点有一个I/O完成端口用以提供I/O本地性，以便所有的I/O请求可以被该结点的启动它们的CPU直接调度和完成。
　　图8-3  上层CPU结点的基础结构
　　CPU结点的本地存储可以用于存储及联系该结点本地的数据。在结点级别上拥有本地存储，使得开发者可以对每个结点拥有本地状态、同时可以在结点间的分割全局状态。
　　CPU结点还提供像在其调度器、I/O关联，以及本地存储之间做负载平衡的功能。图8-3描述了上层CPU结点的基本结构。
　　8.1.2  调度器
　　调度器最主要的目的是在一个特定的CPU上调度作业请求，比如批处理或者一个并发查询的一部分。这些作业请求是由任务驱动的。调度器被设计为一个时间只能有一个任务运行或执行（比如，在该调度器绑定的CPU上，只能运行一个任务）。这与OS中任何时间一个CPU（或者核）上只能有一个线程运行相似。要做到这点，调试器会以一种非抢占式的方式操作，这样切换到其他任务的重担就落在在SQL Server引擎中执行的代码的作者身上。尽管这会加重代码所有者的负担，但人们已经注意到，由于数据库查询的本质，数据库服务器在非抢占式模式下工作得最出色[③]。这样就允许任务在公共点进行切换，而不是被OS随机切换出上下文。
　　调度器可以用于存储每个CPU的本地状态，以及在CPU之间分割全局状态。SQL Server大量使用每个调度器的本地状态，因为有保证只有一个任务运行，在访问本地状态信息时，没必要做同步处理。调度器还提供对非抢占式I/O的支持。在一个调度器上下文切换时完成的异步I/O被称为非抢占式I/O。与其对立的——异步I/O是被CPU结点的I/O完成端口所处理的——被称为抢占式I/O。非抢占式I/O的优点是在完成后，完成程序不会被OS内核调用，那样会经历一个异步程序调用（APC），并产生一次额外的上下文切换。在某些情况下，可能会使I/O完成的时间更长。因此，SQL Server使用非抢占式I/O来完成那些在一定时帧之内能完成的I/O，比如磁盘I/O。网络I/O使用抢占式I/O完成模式。
　　8.1.3  任务和worker
　　任务和worker组成了SQLOS的主要层级。一个任务就是一个执行请求。worker是用于执行任务的逻辑上的执行上下文（想一想线程）。根据模式的不同，一个worker要么映射到一个OS线程或者要么到一个纤程（逻辑线程）。由于SQLOS采用的是一种非抢占式调度模式，这变得更容易。一个任务同时也被指派到一个CPU的调度器上。任务也有本地存储，以便将每个任务的数据及出色数据的分区存储起来。为了遵守SQLOS的非抢占模式，一个任务将在允许的额度内运行尽量长的时间，或者直到因为一个同步对象而被未决的。SQL Server（和SQLOS）代码会定期检查时间片的过期，并切换到正在等待机会运行的其他任务。检查是否要进行切换的地方包括：
　　●  取数据库页面。
　　●  对结果集中每64KB的记录进行的排序。
　　●  在批处理的每个语句执行之后。
　　●  编译查询时的公共点。
　　8.1.4  SQL Server和SQLOS
　　SQLOS通过其基础结构和API设计，给SQL Server带来了可伸缩性。SQL Server开发者有一个可配置性极强的平台，以便他们研究下层硬件并写出高性能、高伸缩性的数据库服务代码。SQL Server开发者充分利用了SQLOS暴露出来的函数性。此外，从SQL Server 2005开始，数据库管理员（DBA）可以选择根据硬件或者应用程序需求来配置或者动态地重新配置SQL Server。比如，如果DBA有两个应用程序共享一个SQL Server，SQL Server可以被配置为运行在双结点的配置下，以便每个应用程序可以使用它自己的结点。这将使两块工作量完全分离。没有SQLOS，这是很难做到的。

第1章 等待和阻塞
1.1 等待类型
1.2 对阻塞问题进行故障排查
1.3 识别阻塞
1.3.1 通过sys.dm_os_waiting_tasks来识别阻塞
1.3.2 从统计上识别阻塞
1.4 确定阻塞的原因
1.4.1 当前的语句和计划
1.4.2 阻塞模式
1.4.3 阻塞链
1.5 资源类型的细节
1.5.1 闩锁
1.5.2 锁
1.5.3 外部等待类型
1.5.4 计时器和队列等待类型
1.5.5 IO操作的等待类型
1.5.6 其他等待类型
1.6 死锁
1.7 监视阻塞
1.7.1 等待的统计信息
1.7.2 当前的等待信息
1.8 小结
1.9 其他资源

第2章 数据损坏及恢复
2.1 基本原理
2.2 SQL Server 2005存储内幕
2.2.1 数据库及文件状态
2.2.2 资源数据库
2.2.3 目录视图和基本系统表
2.2.4 分配结构
2.2.5 数据库校验和
2.2.6 快速恢复
2.2.7 延期事务
2.2.8 只读的压缩数据库
2.3 SQL Server 2005增强
2.3.1 备份增强
2.3.2 还原增强
2.3.3 DBCC CHECKDB增强
2.4 数据恢复最佳实践
2.4.1 备份/还原最佳实践
2.4.2 数据库及日志最佳实践
2.4.3 DBCC CHECKDB最佳实践
2.5 数据恢复故障排查场景
2.5.1 系统数据库恢复
2.5.2 恢复资源数据库
2.5.3 创建tempdb故障
2.5.4 重装操作系统
2.6 用户数据库不可访问
2.6.1 数据库被标记为RECOVERY_PENDING
2.6.2 处理延迟事务
2.6.3 数据库被标记为SUSPECT
2.6.4 粘贴数据库故障
2.7 BACKUP/RESTORE故障
2.7.1 BACKUP故障
2.7.2 RESTORE故障
2.8 数据库一致性错误
2.8.1 处理数据库一致性运行时错误
2.8.2 处理DBCC CHECKDB错误
2.8.3 修复与还原
2.8.4 每个错误表示什么
2.8.5 解释
2.8.6 用户动作
2.8.7 REPAIR_ALLOW_DATA_LOSS真正的意思是什么
2.8.8 进行恢复之前的根本原因分析
2.8.9 如果修复没有用，应该怎么办
2.8.10 复制数据与修复
2.8.11 找出损坏的根本原因：清单

第3章 内存
3.1 Windows内存管理入门
3.1.1 内部的虚拟内存——虚拟地址空间
3.1.2 外部虚拟内存
3.1.3 内部物理内存
3.1.4 外部物理内存
3.1.5 内存压力
3.1.6 NUMA支持
3.2 SQLOS和SQL Server的内存管理
3.2.1 内存结点
3.2.2 内存clerk
3.2.3 内存对象
3.2.4 内存缓存
3.2.5 缓冲池
3.2.6 故障排查

第4章 过程缓存
4.1 过程缓存的架构
4.1.1 缓存对象的类型
4.1.2 过程缓存的结构
4.1.3 过程缓存和内存
4.1.4 非缓存计划和零成本计划
4.1.5 计划的共享
4.1.6 重编译
4.1.7 参数化
4.1.8 缓存查找如何工作
4.1.9 缓存计划复用
4.1.10 刷新过程缓存
4.2 常见缓存相关问题及解决方案
4.2.1 使用过程缓存来确定代价昂贵的查询
4.2.2 参数截取
4.2.3 较差的计划复用造成较高的编译时间
4.2.4 由于过度的缓存查找时间导致的高CPU问题
4.2.5 由过程缓存所引起的内存压力
4.3 小结

第5章 查询处理器
5.1 查询处理器基础
5.1.1 编译-执行序列
5.1.2 执行计划
5.1.3 查询编译和计划选择
5.1.4 特殊的优化方法及场景
5.2 常见问题
5.2.1 编译时间和参数化
5.2.2 索引化
5.2.3 基数和开销估算
5.3 故障排查
5.3.1 诊断
5.3.2 控制
5.4 最佳实践
5.4.1 使用面向集合的编程模型
5.4.2 提供约束和统计的信息
5.4.3 注意复杂的构造
5.4.4 尽可能地避免动态语言特性
5.5 进阶阅读

第6章 服务器崩溃和其他致命故障
6.1 基础知识
6.1.1 SQL Server 2005服务器恢复内幕
6.1.2 SQL Server 2005的增强特性
6.2 致命错误与服务器恢复故障排查
6.2.1 服务器启动故障排查
6.2.2 对服务器致命错误进行故障排查
6.2.3 服务器挂起问题的故障排查

第7章 Service Broker相关问题
7.1 Broker总览
7.1.1 为什么要使用Service Broker
7.1.2 Service Broker的对象和术语
7.1.3 内部架构
7.2 主要的诊断工具和方法
7.2.1 传输队列视图
7.2.2 SQL Profiler——Service Broker跟踪事件
7.2.3 错误日志和NT事件日志
7.3 Broker故障排查实践
7.4 其他Service Broker诊断工具
7.4.1 视图
7.4.2 Perfmon
7.4.3 DBCC CHECKDB
7.5 进阶阅读

第8章 SQLOS和调度问题
8.1 SQLOS架构
8.1.1 内存和CPU结点
8.1.2 调度器
8.1.3 任务和worker
8.1.4 SQL Server和SQLOS
8.2 配置和故障排查
8.2.1 结点配置
8.2.2 网络连接关联
8.2.3 调度器
8.2.4 任务与worker
8.2.5 调度器之间的负载均衡任务
8.2.6 Max Worker Threads配置
8.2.7 Lightweight Pooling配置
8.2.8 Affinity Mask配置
8.2.9 磁盘I/O完成处理
8.2.10 抢占式I/O完成处理
8.2.11 调度器监视器
8.2.12 硬件配置
8.2.13 专用管理员连接
8.3 进阶阅读

第9章 tempdb相关问题
9.1 SQL Server 2005中有何改进
9.1.1 tempdb日志文件的IO动作少了
9.1.2 tempdb数据文件自动增长更快
9.1.3 改进tempdb的并行访问的可扩展性
9.1.4 改进tempdb中多个文件的可扩展性
9.2 tempdb空间是如何使用的
9.2.1 什么是用户对象
9.2.2 什么是内部对象
9.2.3 什么是版本存储对象
9.3 故障排查实践
9.3.1 如果tempdb空间不足，你该怎么办
9.3.2 什么是tempdb页面闩锁竞争
9.4 小结

第10章 群集问题
10.1 示例
10.2 工具
10.3 将性能调整到可接受的水平上
10.3.1 添加结点
10.3.2 为什么群集SQL Server实例发生故障转移
10.3.3 为什么故障转移要花这么长时间
10.3.4 故障转移之后没人可以连接
10.3.5 添加磁盘
10.3.6 替换磁盘
10.3.7 转移数据库
10.4 小结