CruiseYoung提供的带有详细书签的电子书籍目录
http://blog.csdn.net/fksec/article/details/7888251
该资料是《SQL Server求生秘籍》的随书光盘源代码
对应的书籍资料见:
SQL Server求生秘籍(SQL Server故障排除圣经)
基本信息
原书名： SQL Server 2005 Practical Troubleshooting: The Database Engine
原出版社： Addison-Wesley
作者： (美)Ken Henderson 微软SQL Server开发小组和支持部门
译者： 若启 一辉 瞿杰
丛书名： 图灵程序设计丛书.数据库系列
出版社：人民邮电出版社
ISBN：9787115191113
上架时间：2009-2-5
出版日期：2009 年2月
开本：16开
页码：342
版次：1-1
编辑推荐
微软SQL Server内部技术资料大曝光.
来自SQL Server开发小组和支持部门的梦之队打造..
SQL Server故障排除圣经...
内容简介
本书帮助你解决众多数据库引擎方面的问题，每一章从关键的sql server 组件入手，然后探讨用户遇见的常见问题，并给出解决方案。本书的主要内容包括等待和阻塞、数据毁坏和恢复、内存、过程缓存、查询进程等。本书的作者都是来自微软公司sql server 开发团队和客户支持服务部门的支持专家。在你的sql server 系统遇到问题时，本书将变得不可或缺。
本书适合数据库管理员和数据库开发人员阅读。
作者简介：
ken henderson（1967-2008）sql sewer世界级权威。生前供职于微软sql sewer开发组。以guru's guide系列经典著作和sqldiag等工具享誉业界。
创作团队 来自sql server开发小组的7位开发人员和来自微软客户支持服务机构的3位支持专家，他们都有丰富的开发经验，熟悉sql sewer源代码。
作译者
本书的创作团队由来自SQL Server开发小组的开发人员以及来自微软的客户支持服务机构的支持专家组成。其中7位来自SQL Server开发小组，3位来自微软的客户支持服务部门。.
SQL Server开发小组
August Hill是一位具有30多年开发经验的开发人员。在过去的6年里，他一直是SQL Server Service Broker小组中的一员。他为该产品在可支持性方面做出了许多贡献。在业余时间里他喜欢弹吉他以及品味华盛顿葡萄酒。他的联系方式是august.hill@microsoft.com。
Cesar Galindo-Legaria是SQL Server查询优化器部门的主管.他于1992年获得哈佛大学计算机科学专业（数据库方向）的博士学位.在波士顿的一家图形公司工作过一段时间以后,他又返回到数据库领域,在欧洲研究中心进行博士后访问.他于1995年加入微软从事新型关系型查询处理器的工作,该处理器随SQL Serverc7.0一起首次发布,其中引入了一个完全基于开销的查询优化器、一套丰富的执行算法以及许多自动管理的特性.从那时起,他就一直从事SQL Server查询处理的工作.他在查询处理和优化领域拥有多项专利,并且在该领域内发表了许多研究论文.
Ken Henderson是一位具有25年以上开发经验的开发人员.他从1990年开始就从事SQL Server的工作并在其职业生涯内为多家公司开发软件,包括H&R Block、美国中央情报局、美国海军、美国空军、Borland国际公司、摩根大通（JP Morgan）等公司.他于2001年加入微软,目前是SQL Server开发小组中易管理性平台部门（Manageability Platform Group）的一位开发人员.他是SQL Server 2005中SQLDiag工具的开发者,并专注于SQL Server管理工具及相关技术的工作.他是8本涉及多种计算机主题的作者,包括出版自Addison-Wesley公司的SQL Server畅销图书Guru’s Guide系列.他和全家住在达拉斯,他的电子邮箱是khen@khen.com.
Sameer Tejani出生于坦桑尼亚阿鲁沙,在过去的10年里工作于微软的SQL Server部门.他的工作经历使他能够接触到SQL Server引擎的不同领域,包括T-SQL执行框架、开放数据服务（ODS）、连接管理、用户模式调度器（UMS）以及其他领域.他就是那个令支持专家们痛恨的臭名昭著的“non-yielding scheduler”错误消息的唯一负责人！他目前是SQL Server安全小组的软件开发主管.在业余时间内,Sameer喜欢户外活动和长途骑车.他和妻子Farhat住在西雅图...
Santeri Voutilainen,更为常用的名字是Santtu,自从1999年以来就在SQL Server存储引擎小组担任软件设计工程师.他的工作与页分配、闩锁以及锁管理器密切相关.他毕业于哈佛大学,并在华盛顿大学获得计算机科学的硕士学位.尽管称西雅图为自己的家乡,但Santeri生于芬兰,并在尼泊尔渡过了大部分的青年时光.他非常热衷于旅游和户外运动,在闲暇时间内携其妻子与一岁大的儿子在西北太平洋地区进行探险.Santtu的联系方式是santtu@vode.net.
Slava Oks是SQL Server的存储引擎和基础结构小组的软件架构师.他在微软渡过了9年多的时光.在SQL Server 2005的开发项目中,他负责SQLOS的架构和实现.他为该产品在性能、可扩展性、可支持性以及可测试性方面做出了许多贡献.他也是SQL Server的热门博客blogs.msdn.com/slavao的作者.他喜欢在业余时间进行体育运动或者与家人和朋友们一起娱乐.
Wei Xiao从1996年—2006年4月在微软负责SQL Server存储引擎的设计.他主要专注于访问方式、并发模型、空间管理、日志记录以及恢复机制.他也曾从事过SQL Server性能监控和故障排查的工作.他在几次行业会议中做过演讲,包括微软技术大会（TechEd）以及SQL PASS.他目前正在从事微软内部的一个数据存储项目的工作.
微软客户支持服务
Bart Duncan已经从事SQL Server及相关技术有大约10年时间了.他目前是SQL Server产品支持部门的专家级工程师.Bart与他的妻子Andrea Freeman Duncan医生居住在得克萨斯州达拉斯市.
Bob Ward是在位于得克萨斯州艾文市的微软区域支持中心的微软客户服务和支持部门工作的资深专家级工程师.他在微软服务了13年, 并且迄今为止已经支持过微软SQL Server的每一个发行版本, 从OS/2平台下的1.1版到SQL Serverc2005.他在计算机行业的背景持续了20年,包括像在通用动力（General Dynamics）、Harris Hospital以及美国航空公司这样的公司中从事数据库开发项目.Bob于1986年在贝勒大学获得了计算机科学的学士学位.他目前和妻子Ginger以及两个儿子Troy和Ryan居住在得克萨斯州North Richland Hills市.Bob在业余时间会把精力放在青少年体育辅导,支持本地职业体育运动队,并努力提高自己的高尔夫球水平以实现参加PGA巡回赛的梦想.
Cindy Gross从2000年开始成为得州微软PSS的SQL Server和Analysis Services支持小组的成员.在此期间,她担任过许多角色,包括支持工程师、内容主管以及Yukon readiness主管.在加入微软以前,Cindy曾经是一位具有7年经验的SQL Server DBA,负责SQL Server 1.11版及其后续版本的工作.她还是一位热忱的科幻小说读者,关注女性独立的相关图书.她最喜欢的非技术作家是Sheri S. Tepper.Cindy在周末经常开着她的越野摩托（目前是一辆2004年款的本田CRF250X）赛车.你可以从Cindy的网站联系到她：http://cindygross.spaces.live.com/
目录
封面 -13
封底 -12
扉页 -11
版权 -10
版权声明 -9
作者简介 -8
前言 -6
致谢 -4
目录 -3
第1章 等待和阻塞 1
1.1 等待类型 1
1.2 对阻塞问题进行故障排查 2
1.3 识别阻塞 3
1.3.1 通过sys.dm_os_waiting_tasks来识别阻塞 3
1.3.2 从统计上识别阻塞 5
1.4 确定阻塞的原因 8
1.4.1 当前的语句和计划 8
1.4.2 阻塞模式 8
1.4.3 阻塞链 9
1.5 资源类型的细节 10
1.5.1 闩锁 10
1.5.2 锁 18
1.5.3 外部等待类型 29
1.5.4 计时器和队列等待类型 29
1.5.5 IO操作的等待类型 30
1.5.6 其他等待类型 31
1.6 死锁 32
1.7 监视阻塞 33
1.7.1 等待的统计信息 33
1.7.2 当前的等待信息 33
1.8 小结 36
1.9 其他资源 36
第2章 数据损坏及恢复 37
2.1 基本原理 38
2.2 SQL Server 2005存储内幕 39
2.2.1 数据库及文件状态 39
2.2.2 资源数据库 40
2.2.3 目录视图和基本系统表 41
2.2.4 分配结构 50
2.2.5 数据库校验和 53
2.2.6 快速恢复 53
2.2.7 延期事务 54
2.2.8 只读的压缩数据库 54
2.3 SQL Server 2005增强 55
2.3.1 备份增强 55
2.3.2 还原增强 55
2.3.3 DBCC CHECKDB增强 56
2.4 数据恢复最佳实践 58
2.4.1 备份/还原最佳实践 58
2.4.2 数据库及日志最佳实践 59
2.4.3 DBCC CHECKDB最佳实践 60
2.5 数据恢复故障排查场景 61
2.5.1 系统数据库恢复 61
2.5.2 恢复资源数据库 68
2.5.3 创建tempdb故障 69
2.5.4 重装操作系统 69
2.6 用户数据库不可访问 69
2.6.1 数据库被标记为RECOVERY_PENDING 70
2.6.2 处理延迟事务 77
2.6.3 数据库被标记为SUSPECT 78
2.6.4 粘贴数据库故障 79
2.7 BACKUP/RESTORE故障 80
2.7.1 BACKUP故障 80
2.7.2 RESTORE故障 84
2.8 数据库一致性错误 85
2.8.1 处理数据库一致性运行时错误 85
2.8.2 处理DBCC CHECKDB错误 89
2.8.3 修复与还原 100
2.8.4 每个错误表示什么 101
2.8.5 解释 101
2.8.6 用户动作 101
2.8.7 REPAIR_ALLOW_DATA_LOSS真正的意思是什么 102
2.8.8 进行恢复之前的根本原因分析 102
2.8.9 如果修复没有用，应该怎么办 103
2.8.10 复制数据与修复 103
2.8.11 找出损坏的根本原因：清单 103
第3章 内存 110
3.1 Windows内存管理入门 110
3.1.1 内部的虚拟内存——虚拟地址空间 110
3.1.2 外部虚拟内存 113
3.1.3 内部物理内存 113
3.1.4 外部物理内存 114
3.1.5 内存压力 115
3.1.6 NUMA支持 117
3.2 SQLOS和SQL Server的内存管理 118
3.2.1 内存结点 118
3.2.2 内存clerk 119
3.2.3 内存对象 119
3.2.4 内存缓存 120
3.2.5 缓冲池 123
3.2.6 故障排查 127
第4章 过程缓存 143
4.1 过程缓存的架构 143
4.1.1 缓存对象的类型 144
4.1.2 过程缓存的结构 147
4.1.3 过程缓存和内存 148
4.1.4 非缓存计划和零成本计划 150
4.1.5 计划的共享 151
4.1.6 重编译 151
4.1.7 参数化 152
4.1.8 缓存查找如何工作 156
4.1.9 缓存计划复用 157
4.1.10 刷新过程缓存 158
4.2 常见缓存相关问题及解决方案 158
4.2.1 使用过程缓存来确定代价昂贵的查询 158
4.2.2 参数截取 160
4.2.3 较差的计划复用造成较高的编译时间 169
4.2.4 由于过度的缓存查找时间导致的高CPU问题 173
4.2.5 由过程缓存所引起的内存压力 173
4.3 小结 175
第5章 查询处理器 176
5.1 查询处理器基础 176
5.1.1 编译—执行序列 176
5.1.2 执行计划 178
5.1.3 查询编译和计划选择 180
5.1.4 特殊的优化方法及场景 182
5.2 常见问题 185
5.2.1 编译时间和参数化 185
5.2.2 索引化 189
5.2.3 基数和开销估算 191
5.3 故障排查 192
5.3.1 诊断 192
5.3.2 控制 198
5.4 最佳实践 208
5.4.1 使用面向集合的编程模型 209
5.4.2 提供约束和统计的信息 209
5.4.3 注意复杂的构造 209
5.4.4 尽可能地避免动态语言特性 210
5.5 进阶阅读 210
第6章 服务器崩溃和其他致命故障 212
6.1 基础知识 212
6.1.1 SQL Server 2005服务器恢复内幕 212
6.1.2 SQL Server 2005的增强特性 218
6.2 致命错误与服务器恢复故障排查 221
6.2.1 服务器启动故障排查 221
6.2.2 对服务器致命错误进行故障排查 227
6.2.3 服务器挂起问题的故障排查 255
第7章 Service Broker相关问题 259
7.1 Broker总览 260
7.1.1 为什么要使用Service Broker 260
7.1.2 Service Broker的对象和术语 260
7.1.3 内部架构 261
7.2 主要的诊断工具和方法 261
7.2.1 传输队列视图 261
7.2.2 SQL Profiler——Service Broker跟踪事件 262
7.2.3 错误日志和NT事件日志 264
7.3 Broker故障排查实践 265
7.4 其他Service Broker诊断工具 272
7.4.1 视图 272
7.4.2 Perfmon 283
7.4.3 DBCC CHECKDB 285
7.5 进阶阅读 286
第8章 SQLOS和调度问题 287
8.1 SQLOS架构 288
8.1.1 内存和CPU结点 289
8.1.2 调度器 290
8.1.3 任务和worker 291
8.1.4 SQL Server和SQLOS 291
8.2 配置和故障排查 291
8.2.1 结点配置 291
8.2.2 网络连接关联 292
8.2.3 调度器 294
8.2.4 任务与worker 296
8.2.5 调度器之间的负载均衡任务 297
8.2.6 Max Worker Threads配置 298
8.2.7 Lightweight Pooling配置 299
8.2.8 Affinity Mask配置 300
8.2.9 磁盘I/O完成处理 301
8.2.10 抢占式I/O完成处理 302
8.2.11 调度器监视器 303
8.2.12 硬件配置 314
8.2.13 专用管理员连接 316
8.3 进阶阅读 318
第9章 tempdb相关问题 319
9.1 SQL Server 2005中有何改进 320
9.1.1 tempdb日志文件的IO动作少了 321
9.1.2 tempdb数据文件自动增长更快 321
9.1.3 改进tempdb的并行访问的可扩展性 321
9.1.4 改进tempdb中多个文件的可扩展性 322
9.2 tempdb空间是如何使用的 322
9.2.1 什么是用户对象 323
9.2.2 什么是内部对象 323
9.2.3 什么是版本存储对象 324
9.3 故障排查实践 325
9.3.1 如果tempdb空间不足，你该怎么办 325
9.3.2 什么是tempdb页面闩锁竞争 327
9.4 小结 328
第10章 群集问题 329
10.1 示例 329
10.2 工具 331
10.3 将性能调整到可接受的水平上 333
10.3.1 添加结点 334
10.3.2 为什么群集SQL Server实例发生故障转移 337
10.3.3 为什么故障转移要花这么长时间 338
10.3.4 故障转移之后没人可以连接 338
10.3.5 添加磁盘 339
10.3.6 替换磁盘 339
10.3.7 转移数据库 339
10.4 小结 339
前言
原本我想在本书中让微软技术支持工程师撰写多年来在SQL Server的技术支持工作中所学到的知识。当我加入微软后，令我惊奇的是，技术支持工程师们并没有把关于产品支持的实践知识（在认识论中叫作“领域知识”）记录下来。这些知识仅仅停留在口口相传的状态。.
当然，这导致了一个问题：人们并不知道如何做好工作，除非有热心人来向他们展示该如何做。这也是一种非常容易犯错误的方式，会导致一些最重要的产品支持知识集中在少数人手中——这些经验被他们充分利用，但其他的支持团队却不了解这些知识。
加入微软之前，我做全职软件开发工程师已经20多年了。令我十分惊讶的是，原来支持部门的高端人群都是些曾经做过开发的人。通常，在成为技术支持工程师之前，他们都有3～5年的开发或相关工作经验。作为一名职业开发人员，我很难想象技术支持也可以做长工。对于我来说，支持工作似乎与软件开发世界中的看门人类似。他们不得不帮那些编写乱糟糟代码的开发者“擦屁股”的人。虽然我知道这很重要，但是私下里还是觉得把技术支持工作作为职业并不是一件开心的事。尽管如此，确实有好几个程序员前辈呆在技术支持部门，这让我感到迷惑。
于是，我开始思考如何创造人人机会均等的局面，让原本只有技术支持的上层梯队才能拥有的知识可以传达给每个人。奥林匹斯山上的家伙们对拥有产品支持的全面知识和领域知识引以为豪，对于我来说，这些知识应该分享给组织中的每个人。每一个做产品支持的人都应该有相同的权限来了解它们。
我最初打算在我写的The Guru’s Guide to SQL Server Architecture and Internals一书中加入如何对产品进行故障排查的内容。然而，我很快意识到，开发软件或从开发人员的角度理解软件与故障排查有本质上的不同。可以说，它们是两种完全不同的领域知识。虽然有些部分是重叠的，但对产品故障排查而言，肯定有一些属于它自己特有的东西。
在我最终完成那本关于架构的书后，开始回过头来思考这个问题——如何把支持组在多年里学到的关于产品故障排查的许多低层次的细节和洞察记录下来，并不会有很多关于产品如何运行的详细信息，而是如何解决与产品有关的问题的详细信息。于是我开始与一些支持工程师探讨这个想法，并试探他们对此的兴趣。我建议做一个多作者的项目，在该项目中他们可以把一些难得的故障排查经验发表出来——这不仅仅是为了那些做技术支持的同事们，也为了客户。许多东西还从未被出版过，我感到，如果他们可以看到自己的文字出现在出版物中，最终会激励他们投身于写一些可能只有微软内部的少数人知道的东西。..
什么样的回应都有，从不太热情到很热情。在翻遍了关于哪些人感兴趣和哪些人不感兴趣的花名册之后，我发现，很明显，我需要更多的作者加入到本书的写作队伍中来。在支持部门中，愿意并能够投身到该项目中的人寥寥无几。
我本可以抛开支持组，而跑到微软咨询服务部门，或干脆去找那些最有价值专家（MVP）和类似的人选，但其实我很想把作者队伍限制在那些看过SQL Server源代码的人之中。访问过源代码并一步一步调试过，这种经历是不可替代的。通过研究产品代码，可以更深地理解SQL Server技术，从一定意义上讲，其他方法是做不到这一点的。
因此，我们还需要多引入一些作者，我决定向产品组的一些顶级开发人员发出邀请。虽然微软的产品组与支持组截然不同，他们关注的是开发产品，而不是提供技术支持，但我私下认识他们中的许多人，并知道他们已经花了大量的时间来调试和解决产品中的一些复杂问题，特别是对他们自己所创建的那部分。如果你从不调试代码，是写不出复杂代码的。我相信他们肯定会觉得新颖且有趣，愿意为本书增加一些实际的故障排查知识。
产品组的同事给我的答复都很热情，有好几个来自SQL Server组的顶级开发人员同意参加这个写作项目。我终于成功邀请到了真正写代码的人来探讨如何进行复杂且常见的问题的故障排查。在其他书中，你是找不到这些的，作为参与者，能够让你看到这些内容让我感到激动。
我那本讲架构的书告诉你SQL Server是怎样运转的，这本书则告诉你SQL Server要是不转了怎么办。前一本书，不管你要处理SQL Server的哪一块，都用得上。而现在这本，按说只用于极端情形（因为SQL Server这个产品并不会经常挂掉），然而你的SQL Server应用是一直能让用户满意呢，还是会随时引起用户的怒火，有没有本书差别可就大喽。当然我希望你不会在使用SQL Server时遇到问题。如果遇到了，本书将是你开始故障排查征程的起点。
在此，我要感谢SQL Server产品组中那些做开发的同事们，他们为本书提供了不少内容，分别是：August Hill, Cesar Galindo-Legaria, Sameer Tejani, Santeri (Santtu)Voutilainen, Slava Oks和Wei Xiao；我也要感谢几位技术支持工程师，是他们为这个项目提出了宝贵意见：Bart Duncan, Bob Ward和Cindy Gross。他们都有自己独特的思考（和写作！）方式，但帮助你处理SQL Server故障排查中的一些实际问题，这帮人再合适不过了。...
Ken Henderson
媒体评论
“本书的内容是其他任何博客、网站和图书都没有的。系统出问题时，它将成为你的救命稻草。”.
——Pinal Dave，微软MVP
“此书写得非常好，涵盖了对大量复杂问题进行故障排查的详细解析。我认为每一位优秀的MSSQL DBA都应该拥有。”...
——Amazon．com评论
