SQL Server 2012实施与管理实战指南

作者简介

《SQL Server 2012实施与管理实战指南》主要面向对Microsoft SQL Server有一定基础的数据库系统管理人员和开发人员，针对他们在日常工作中可能遇到的种种困扰提出解决方案。《SQL Server 2012实施与管理实战指南》讨论的主题是面向实践，解决用户开发和使用SQL Server过程中常见的经典问题。在每个章节里，都会基于这个主题从经常遇到的问题入手，描述其表现形式，介绍其背后的运行机理与基本理论知识，介绍搜集和分析问题日志的方法，以及解决实际问题的可选手段。《SQL Server 2012实施与管理实战指南》所包含的案例分析都来源于真实案例。

书籍目录

第1部分  数据库系统的选型和部署

第1章  SQL Server的安装和升级
2

1.1  数据库安装过程介绍
3

1.1.1  setup.exe执行过程
3

1.1.2  重要的数据库的安装日志文件
5

1.2  单机版本的数据库安装和打补丁
13

1.2.1  安装注意事项
13

1.2.2  用SlipStream方式进行安装
14

1.2.3  用Product Update方式进行安装
15

1.2.4  常见安装问题
16

1.3  特殊版本的数据库安装
18

1.4  群集环境下数据库的安装和升级
20

1.5  数据库的升级
27

1.6  小结
30

第2章  选择必要的高可用性和灾难恢复技术
31

2.1  什么是SQL Server的“高可用性”与“灾难恢复”
31

2.2  SQL Server故障转移群集
33

2.2.1  Windows故障转移群集
33

2.2.2  SQL Server故障转移群集
36

2.2.3  SQL Server群集什么时候会发生“故障转移”
40

2.2.4  SQL Server群集的拓扑结构
43

2.2.5  SQL 2012对故障转移群集的改进
44

2.2.6  故障转移群集的故障排查
55

2.3  日志传送
58

2.3.1  日志传送的结构
59

2.3.2  日志传送的工作机制
60

2.3.3  日志传送作业的执行间隔
64

2.3.4  日志传送的故障转移
65

2.3.5  日志传送的监控和故障排查
68

2.4  数据库镜像
71

2.4.1  数据库镜像的基本概念
71

2.4.2  数据库镜像操作模式
74

2.4.3  客户端连接重定向及超时控制
78

2.4.4  数据库镜像的监控和故障排查
81

2.5  复制
84

2.5.1  复制的基本概念
84

2.5.2  复制的类型
86

2.5.3  灾难恢复和复制
90

2.6  高可用和灾难恢复技术的选择
91

2.6.1  高可用和灾难恢复技术的比较
91

2.6.2  高可用和灾难恢复技术的组合
97

2.7  小结
100

第3章  新一代的高可用技术AlwaysOn
101

3.1  AlwaysOn的基本架构
102

3.2  AlwaysOn的数据同步原理
106

3.3  AlwaysOn的可用性模式
107

3.4  AlwaysOn的故障转移形式
111

3.5  创建一个AlwaysOn可用性组
118

3.6  可读的辅助数据库
127

3.7  监视AlwaysOn可用性组的运行状态
133

3.8  小结
138

第4章  数据库连接组件编程机理
140

4.1  数据库应用编程方法概述和组件架构
141

4.1.1  WDAC编程
141

4.1.2  SNAC编程
162

4.1.3  ADO.NET编程
163

4.2  连接字符串
166

4.3  连接池
169

4.4  Connection Timeout和Command Timeout
173

4.5  使用BID Tracing来跟踪检查应用程序的执行
181

4.6  小结
185

第2部分  SQL Server日常管理

第5章  启动SQL Server服务和数据库
188

5.1  SQL Server服务启动步骤
189

5.1.1  从注册表读取SQL Server启动信息
190

5.1.2  检测硬件，配置内存与CPU
193

5.1.3  数据库启动
195

5.1.4  准备网络连接
195

5.2  数据库状态切换
198

5.3  数据库长时间处于RECOVERING状态
201

5.4  数据库不能启动的常见原因和解决办法
206

5.4.1  master数据库不能启动
206

5.4.2  资源数据库
208

5.4.3  model数据库
210

5.4.4  tempdb数据库
212

5.4.5  用户数据库
214

5.5  群集环境下，数据库资源不能ONLINE的常见原因
220

5.5.1  由于单机原因导致数据库服务无法启动
222

5.5.2  由于SQL Server所依赖的资源失败所导致
223

5.5.3  由于群集服务无法连接导致数据库资源失败
224

5.6  小结
228

第6章  连接的建立和问题排查
229

6.1  协议的选择与别名
230

6.1.1  服务器网络配置
231

6.1.2  SQL Server Browser的作用
233

6.1.3  客户端网络配置
235

6.1.4  客户端网络连接选择机制
239

6.2  连接失败检测步骤——命名管道
241

6.2.1  SQL Server命名管道工作原理
242

6.2.2  客户端的命名管道配置
243

6.2.3  命名管道连接问题的解决步骤
245

6.2.4  一些常见的连接问题
246

6.3  连接失败检测步骤——TCP/IP
247

6.3.1  SQL Server监听的TCP/IP端口号
248

6.3.2  客户端的TCP/IP协议配置
249

6.3.3  TCP/IP连接的keepalive机制
251

6.3.4  配置SQL Server的keepalive配置
252

6.3.5  配置客户端的keepalive配置
253

6.3.6  TCP/IP连接问题的解决步骤
254

6.4  一般性网络错误
258

6.5  利用Ring Buffer排查连接问题
266

6.6  小结
271

第7章  身份认证与连接加密
272

7.1  SQL Server的认证方式
273

7.1.1  SQL Server认证模式和密码管理
273

7.1.2  Windows认证模式
274

7.1.3  常见认证问题
286

7.1.4  Delegation的配置要求
288

7.2  包含数据库认证
295

7.2.1  创建包含数据库
296

7.2.2  使用包含数据库认证
299

7.2.3  包含数据库认证的安全须知
303

7.3  连接加密和证书
305

7.3.1  SQL Server的连接加密
306

7.3.2  使用证书来加密SQL Server连接
313

7.4  小结
319

第8章  数据库空间管理
320

8.1  数据文件的空间使用和管理
321

8.1.1  数据文件存储结构
321

8.1.2  表存储结构
323

8.1.3  比较存储结构对空间使用的影响
332

8.2  日志文件的空间使用和管理
337

8.3  空间使用计算方法
341

8.4  tempdb的空间使用
346

8.5  数据文件的收缩
353

8.6  日志文件不停地增长
362

8.7  文件自动增长和自动收缩
367

8.8  小结
370

第9章  数据库备份与恢复
371

9.1  备份概述
372

9.2  选择备份策略和恢复模式
375

9.2.1  简单恢复模式下的备份
376

9.2.2  完整恢复模式下的备份
377

9.2.3  文件或文件组备份
381

9.3  选择数据库还原方案
382

9.3.1  数据库完整还原
384

9.3.2  文件还原
386

9.3.3  页面还原
387

9.3.4  段落还原
390

9.3.5  还原方案小结
393

9.3.6  孤立用户故障排除
394

9.4  系统数据库备份与恢复
395

9.4.1  master数据库
396

9.4.2  model数据库
397

9.4.3  msdb数据库
397

9.4.4  tempdb和资源数据库
398

9.5  带有FILESTREAM功能的数据库备份和恢复
399

9.6  应对由于备份损坏导致的还原错误
401

9.7  实例：将数据库系统在一台新服务器上恢复
403

9.8  小结
408

第10章  数据库损坏修复
409

10.1  常见错误解读
409

10.1.1  823
409

10.1.2  824
410

10.1.3  605
412

10.1.4  其他
413

10.2  DBCC CHECKDB
414

10.2.1  DBCC CHECKDB在做什么
414

10.2.2  DBCC CHECKDB提供的修复方法
418

10.2.3  如何在超大数据库上运行DBCC CHECKDB
420

10.3  不同部位损坏的应对
423

10.3.1  备份文件损坏
424

10.3.2  日志文件损坏
426

10.3.3  用户数据文件损坏
427

10.3.4  系统数据库损坏
431

10.4  如何从损坏的数据库导出数据
432

10.5  如何使用TableDiff工具发现哪些数据有丢失或改变
439

10.6  数据库反复损坏问题应对
440

10.6.1  SQL I/O 管理操作方法
441

10.6.2  确保系统I/O正常
443

10.6.3  SQL层面能够做的设置
448

10.7  Database Mirroring和AlwaysOn的页面自动修复功能
449

10.8  小结
452

第3部分  SQL Server资源调度与性能调优

第11章  SQL Server内存分配理念和常见内存问题
454

11.1  从操作系统层面看SQL Server内存分配
457

11.1.1  Windows的一些内存术语
457

11.1.2  32位下Windows的地址空间及AWE
460

11.1.3  Windows层面上的内存使用检查
463

11.1.4  内存使用和其他系统资源的关系
468

11.1.5  SQL内存使用和Windows之间的关系
470

11.1.6  SQL内存使用量陡然下降现象
472

11.1.7  案例分析
474

11.1.8  如何“合理”配置SQL Server内存
476

11.2  SQL Server内部独特的内存管理模式
477

11.2.1  内存使用分类
478

11.2.2  32位下各部分内存的分布和大小限制
482

11.2.3  SQL Server在不同服务器配置下各部分内存的最高使用上限
484

11.2.4  一些内存使用错误理解
485

11.3  SQL Server内存使用状况分析方法
487

11.3.1  SQL性能计数器
488

11.3.2  内存动态管理视图（DMV）
490

11.4  数据页缓冲区压力分析
497

11.4.1  表现特征
497

11.4.2  确定压力来源和解决办法
500

11.5  Stolen Memory缓存压力分析
508

11.5.1  Stolen缓存区与数据页缓存区的相互关系
509

11.5.2  内部压力与外部压力
510

11.5.3  表现特征与解决办法
510

11.6  Multi-page缓存区压力分析
512

11.7  常见内存错误与解决办法
515

11.7.1  错误701
516

11.7.2  错误8645
520

11.7.3  SQL Server无法创建新的线程
524

11.8  SQL Server 2012 内存管理的新变化
525

11.8.1  总体变化
527

11.8.2  AWE和LockedPages的变化
528

11.8.3  内存相关的诊断工具的变化
530

11.8.4  SQL Server 2012内存相关配置的变化
533

11.8.5  其他改变
535

11.9  小结
535

第12章  SQL Server I/O问题
537

12.1  SQL Server的I/O操作
537

12.2  系统级I/O问题判断
544

12.3  数据库引擎错误833
548

12.4  I/O问题的SQL Server内部分析
550

12.5  硬盘压力测试
558

12.6  圣剑——Windows提供的新的底层监测功能
564

12.7  小结
570

第13章  任务调度与CPU问题
572

13.1  SQL Server独特的任务调度算法
573

13.1.1  SQLOS的任务调度算法
575

13.1.2  任务调度健康监测及常见问题
580

13.1.3  一个内存转储文件的分析调试过程
583

13.1.4  案例分析
588

13.2  SQL Server CPU 100%问题
592

13.3  OLTP和Data Warehouse系统差别及常用性能阈值
597

13.3.1  OLTP系统
597

13.3.2  Data Warehouse系统
604

13.4  小结
609

第14章  阻塞与死锁——知识准备
611

14.1  锁产生的背景
612

14.2  锁资源模式和兼容性
614

14.3  事务隔离级别与锁的申请和释放
618

14.4  如何监视锁的申请、持有和释放
628

14.4.1  检查一个连接当前锁持有的锁
628

14.4.2  监视语句执行过程中SQL对锁的申请和释放行为
629

14.5  锁的数量和数据库调优的关系
630

14.5.1  一个常见的SELECT动作要申请的锁
634

14.5.2  一个常见的UPDATE动作要申请的锁
639

14.5.3  一个常见的DELETE动作要申请的锁
641

14.5.4  一个常见的INSERT动作要申请的锁
643

14.6  小结
645

第15章  阻塞与死锁——问题定位与解决
646

15.1  阻塞问题定位方法及实例演示
647

15.2  如何捕捉不定时出现的阻塞信息
655

15.3  常见阻塞原因与解决方法
658

15.4  案例分析：连接池与阻塞
666

15.4.1  连接池与SQL Server
666

15.4.2  正常情况下连接池在SQL Server端的处理方式
667

15.4.3  程序端意外情况下SQL Server端可能导致的问题——应用端超时
671

15.4.4  程序端意外情况下SQL Server端可能导致的问题——应用层事物未提交
675

15.5  死锁问题定位及解决方法
680

15.5.1  死锁所在的资源和检测
680

15.5.2  问题定位
682

15.5.3  解决办法
686

15.5.4  动手实验
687

15.6  小结
698

第16章  从等待状态判断系统资源瓶颈
699

16.1  LCK_xx类型
701

16.2  PAGEIOLATCH_x与WRITELOG
702

16.3  PAGELATCH_x
704

16.4  tempdb上的PAGELATCH
708

16.5  其他资源等待
710

16.6  最后一道瓶颈：许多任务处于RUNNABLE状态
713

16.7  小结
715

第17章  语句调优——知识准备
719

17.1  索引与统计信息
723

17.1.1  索引上的数据检索方法
723

17.1.2  统计信息的含义与作用
727

17.1.3  统计信息的维护和更新
732

17.2  编译与重编译
736

17.3  读懂执行计划
750

17.3.1  连接
754

17.3.2  其他常见的运算操作
762

17.4  读懂语句运行统计信息
765

17.4.1  Set statistics time on
766

17.4.2  Set statistics io on
768

17.4.3  Set statistics profile on
770

17.5  小结
775

第18章  语句调优——问题定位与解决方法
776

18.1  是否是因为做了物理I/O而导致的性能不佳
777

18.2  是否是因为编译时间长而导致性能不佳
780

18.3  判断执行计划是否合适
784

18.3.1  预估cost的准确性
784

18.3.2  是Index Seek还是Table Scan
790

18.3.3  是Nested Loops还是Hash (Merge) Join
794

18.3.4  filter运算的位置
795

18.3.5  确认问题产生的原因
798

18.4  Parameter Sniffing
800

18.4.1  什么是“Parameter Sniffing”
801

18.4.2  本地变量的影响
802

18.4.3  Parameter Sniffing的解决方案
804

18.5  调整数据库设计来优化语句性能
814

18.5.1  调整索引
814

18.5.2  计划指南
821

18.6  调整语句设计提高性能
829

18.6.1  筛选条件与计算字段
829

18.6.2  会在运行前改变值的变量
832

18.6.3  临时表和表变量
834

18.6.4  尽可能限定语句的复杂度
836

18.7  小结
838

第4部分  SQL Server常用日志信息与推荐搜集方法

第19章  SQL Server常用日志信息与推荐搜集方法
840

19.1  Windows事件日志
841

19.2  SQL Server errorlog文件
843

19.3  性能监视器
845

19.4  SQL Trace文件
851

19.4.1  SQL Trace文件的收集方法
851

19.4.2  SQL Trace文件的分析方法
860

19.4.3  自动化分析SQL Trace
862

19.5  系统管理视图跟踪
866

19.6  SQLDIAG工具
868

19.7  强烈推荐：PSSDIAG工具
873

19.7.1  使用PSSDIAG收集信息
874

19.7.2  自动化分析PSSDIAG收集的信息
876

19.8  系统自动监视工具——Performance Dashboard
879

19.9  小结
882

编辑推荐

《SQL Server 2012实施与管理实战指南》编辑推荐：读者既可以把这本书作为一部进阶学习的参考书籍，更深入地理解SQL Server的原理和运行规律；也可以把这本书作为一本工具书，在遇到问题时查阅解决办法。

内容概要

徐海蔚，于2000年加入微软亚太区全球技术支持中心企业支持部数据库开发支持组。十多年来一直从事SQL Server的高端技术支持，曾先后担任支持工程师、技术主管和部门经理。服务的客户包括亚太区的大型企业、微软合作伙伴和开发人员。接触的企业级客户遍布中国、新加坡、马来西亚、澳大利亚、新西兰、印度等。擅长处理SQL Server企业应用实施、性能调优和日常管理中的棘手问题，经验丰富。 王佳毅，微软亚太区全球技术支持中心企业支持部数据库开发支持组资深支持专家。负责SQL Server 2000／2005／2008／2008R2／2012的技术支持工作。专注于SQL Server的高可用性方案部署、系统的稳定性维护及性能调优等。曾为中国、东南亚地区及澳大利亚的多家大型企业、政府和金融机构提供现场或远程的部署支持及性能调优服务。在微软公司专注于技术支持工作8年，是实践经验丰富的专家级工程师。 朱桦，曾任微软SQL Server技术支持工程师，现任微软数据库技术支持组技术主管。在加入微软的6年中，一直致力于为全球客户与合作伙伴提供SOL Server的技术支持、咨询和培训服务。在SQL Server的高可用性解决方案、连接认证、安全保护和性能调优等领域，有非常丰富的经验。作为微软SQL Server 2012内部讲师，对于SQL Server 2012也有着非常前沿的认知和了解。 俞榕刚，微软亚太区全球技术支持中心数据库开发支持组技术支持专家。在微软Server产品研发组和技术支持部门都工作过，所以对SQL Server产品了解比较透彻，并且熟悉客户的实际需求。擅长SQL Server客户端编程、性能瓶颈和语句调优、安装和升级、群集、镜像、日志传输。曾为上千个客户提供技术支持，获得很好的评价。

章节摘录

版权页：   插图：   2.3.3 日志传送作业的执行间隔 日志传送是利用SQL Server Agent来执行备份还原的作业，从而达到主副数据库同步的目的。由于作业是每隔一定的时间间隔才被SQL Server Agent触发的，因此主副数据库的同步也不是实时的。它们之间会有一定程度的延迟。这是日志传送技术的一个重要特征。如果发生灾难，这部分延迟可能会带来数据丢失。 日志传送的主副数据库同步的延迟到底会有多长呢？这是由备份作业、复制作业和还原作业的运行间隔决定的。不过，用户所关心的最大数据损失量仅是由备份作业运行的间隔所决定的。例如，上述3个作业的执行间隔都被设置为15分钟，那么主副数据库之前同步的延迟会在15～45分钟之间。但是，只要日志被成功备份下来，无论之后复制和还原操作会延迟多长时间，日志备份始终在那里，最终都会被还原到辅助数据库中。最大的数据丢失是从最后一次成功的日志备份开始到数据库发生异常这段时间范围内的所有数据变化。因此，对于备份间隔是15分钟日志传配置，最坏情况下就是损失15分钟内的数据。 你可以根据所能接受的最大数据损失量来指定备份作业的执行间隔。对于非常繁忙的OLTP系统，建议适当地缩短备份间隔。这样除了可以减小数据库发生异常后的数据的损失量，还可以有效地控制主数据库的日志文件大小，防止由于没有及时截断日志而导致日志文件太大的问题。 但是，无论怎么减小备份作业执行的间隔，日志传送是永远无法保证两个数据库是完全同步的。SQL Server允许的作业执行最小间隔是10秒，因此理论上你至少会有10秒的数据损失。此外，将备份间隔设置的太小也会给主服务器带毒额外的负担，一定程度上影响数据库的性能。如果你追求的是零数据损失的灾备方案，日志传送并不适合你。 在给定的辅助服务器上，用户可以让复制作业和还原作业使用和主服务器的备份作业一样的执行间隔，并且控制复制作业和还原作业开始执行的时间，让复制作业尽可能紧随着备份作业完成后执行，让还原作业紧随着复制作业完成后执行。这样，每个日志备份被创建后可以立即将其复制和还原。这有助于减少在主服务器出现故障之后使辅助服务器上线所需的修复时间。 相反，用户也可以有意地延迟复制作业和还原作业，或者把复制作业和还原作业的执行间隔设置为远大于备份作业的执行间隔。这样做可以延迟将事务日志备份恢复到辅助数据库。该延迟提供了一个时间间隔。在这个时间间隔内，用户可以响应主服务器上发生的异常或故障。这对于处理严重的用户错误是很有用的。比如说，如果用户错误地删除了某张表或表中的某些行，并且管理员知道误操作的时间，他就可以立刻暂停复制和还原作业，不让误操作被同步到辅助数据库上。然后，手动地将包含错误操作的日志备份复制到辅助服务器上，并使用restore database命令中的stop at参数将数据库在辅助服务器上还原到误操发生前的状态。此后，管理员可以选择切换数据库的角色，让辅助数据库上线运行，或者选择导出主数据库上已经丢失的数据将其导回主数据库。

---

 SQL Server 2012实施与管理实战指南下载

---