sql server - tup.com.cn · 术相关的问题。除了他的日常工作，他还为sql nexus、sql...

SQL Server 数据库经典译丛

SQL Server 2012 深入解析与性能优化

(第 3 版)

[美]

Christian Bolton Justin Langford Glenn Berry Gavin Payne Amit Banerjee Rob Farley

著

胡克宁译

北京

Christian Bolton, Justin Langford, Glenn Berry, Gavin Payne, Amit Banerjee, Rob Farley Professional SQL Server 2012 Internals and Troubleshooting EISBN：978-1-118-17765-5 Copyright © 2013 by John Wiley & Sons, Inc., Indianapolis, Indiana. All Rights Reserved. This translation published under license.

本书中文简体字版由 Wiley Publishing, Inc. 授权清华大学出版社出版。未经出版者书面许可，不得以任何方式

复制或抄袭本书内容。

北京市版权局著作权合同登记号图字：01-2013-2512

Copies of this book sold without a Wiley sticker on the cover are unauthorized and illegal.

本书封面贴有 Wiley 公司防伪标签，无标签者不得销售。

版权所有，侵权必究。侵权举报电话：010-62782989 13701121933

图书在版编目(CIP)数据 SQL Server 2012 深入解析与性能优化(第 3 版)/(美) 波尔顿(Bolton, C.) 等著；胡克宁译. —北京：清

华大学出版社，2013.11 (SQL Server 数据库经典译丛) 书名原文：Professional SQL Server 2012 Internals and Troubleshooting ISBN 978-7-302-34231-1

.Ⅰ S① … .Ⅱ ①波… ②胡… .Ⅲ ①关系数据库系统 .Ⅳ TP311.138① 中国版本图书馆 CIP 数据核字(2013)第 249706 号

责任编辑：王军韩宏志装帧设计：牛静敏

责任校对：成凤进

责任印制：

出版发行：清华大学出版社

网址：http://www.tup.com.cn，http://www.wqbook.com 地址：北京清华大学学研大厦 A 座邮编：100084 社总机：010-62770175 邮购：010-62786544 投稿与读者服务：010-62776969, [email protected] 质量反馈：010-62772015, [email protected]

印刷者：装订者：经销：全国新华书店开本：185mm×260mm 印张：32.25 字数：785 千字版次：2013 年 11 月第 1 版印次：2013 年 11 月第 1 次印刷印数：1~3000 定价：68.00 元 —————————————————————————————————————————————— 产品编号：

译者序

多年来我一直从事SQL Server DBA工作。前段时间从SQL Server MVP宋沄剑那边得知

有一个翻译本书的机会，于是大致浏览了一下原版的英文书，发现确实是一本深入浅出、

条理分明的好书。本书非常适合专业的SQL Server DBA阅读，与一般的SQL Server书籍不同，除了介绍

SQL Server的体系结构、内存和锁等数据库内核知识外，本书还占用了较多篇幅介绍了硬

件、存储、故障排除方法论和虚拟化等DBA较少接触到的一些知识，而这些知识对于做好

DBA工作有很大的帮助。另外，书中还详细介绍了SQL Server之外的一些十分有用的工具，

比如性能监视器、PAL、SQLdiag、SQL Nexus、PowerShell和SCOM等。这些工具很好地

扩展了DBA对SQL Server进行故障排除时可以使用的方法。针对2012版本，本书用专门一

章的篇幅介绍了在SQL Server 2012中得到极大改进的扩展事件，还提供了一系列的数据库

健康检查的脚本，脚本中使用了大量动态管理视图查询，其中也包括了SQL Server 2012中新增的一些功能。本书侧重于采用真实世界的操作经验，提供成熟的案例经验而不只是泛

泛的“如何操作”，对于DBA的实际工作提出很中肯的指导意见。总之，本书涵盖的知识

面较为广泛，适用于有一定经验的DBA进阶学习。如果读者想要了解SQL Server的内部体

系结构或者学习使用一些性能分析和故障排除的工具，本书堪称上佳之选。翻译完这本书后，从这些世界顶尖SQL Server专家那里我学到了不少东西。用广为流

传的那个比喻最为恰当不过了：知识就是一个无边无际的平面，而我们自己所掌握的不过

是其中的一个小圆，知道的信息越多，与外面未知区域相邻的部分就越多，才知道有越多

的“无知”。正如多年前看到的一句话：人前进的动力乃是不安。吾生有涯，而知识无涯。

在我们面对这些无知与不安时，不必慌张，这正是我们自我提升的契机。最后，我想要感谢这一路走来鼓励和支持我的各位编辑，十分有幸能够与你们相识，

你们的细致与耐心值得我毕生学习，感谢你们对文档的严格把关，帮忙控制翻译质量。本

书全部章节由胡克宁翻译，参与翻译活动的还有王晏、倪波雷、宋沄剑、孔祥亮、陈跃华、

杜思明、熊晓磊、曹汉鸣、陶晓云和王通等，我要感谢各位在翻译过程中给我提供的一些

文档和宝贵意见。最后，我要感谢妻子和父母在我翻译期间给予的支持和鼓励。虽然我本着严谨的态度，字斟句酌，将大量心血和汗水投注到本书的翻译中，力求为

读者献上一本经典译作，但由于水平有限，翻译中难免有失误和遗漏之处，敬请广大读者

提供宝贵意见和建议，可通过[email protected]与我们联系。胡克宁

作者简介

● Christian Bolton 是 Coeo 公司的技术总监，该公司是位于英国和

欧洲的提供 SQL Server 管理支持和咨询的一家领先提供商。

Christian 是微软认证架构师、微软认证大师以及 SQL Server MVP，同时是一位经验丰富的技术作家。他尤其对 SQL Server基础结构、可扩展性及高可用性技术感兴趣，还是全球技术会议

的高级发言人。Christian 是本书的主要作者和全书的技术编辑。 ● Justin Langford 领导着 Coeo 公司的管理支持团队，为关键任务

SQL Server 平台提供 7×24 的远程 DBA 服务。在加盟 Coeo 之

前，Justin 在微软的高级现场服务部工作，为微软在欧洲最大的

一些金融机构和政府部门客户提供支持和咨询。Justin 参与撰写

了 Wrox 的 Professional SQL Server 2005 Performance Tuning 和

Professional SQL Server 2008 Internals and Troubleshooting 两本

书。Justin 是一名 SQL Server MVP，他和妻子 Claire 居住在伦敦。

业余时间，他爱好航海运动并热衷于古典英国跑车。 ● Glenn Berry 是 SQLskills 的首席顾问。他作为一名 SQL Server

专家已在各种岗位上工作多年，最近他作为一名数据库架构师在

位于科罗拉多州 Parker 的 Avalara 公司工作。Glenn 自从 2007 年

开始就已经是 SQL Server MVP 了，他还获得了很多微软认证，

包括 MCITP、MCDBA、MCSE、MCSD、MCAD 和 MCTS。他

擅长的领域包括动态管理视图、高可用性、硬件选择及配置以及

性能调优。Glenn 活跃在 SQL Server 社区，是一位在用户组、

SQLSaturdays 和 PASS 社区峰会频繁活动的发言人。他是 SQL Server Hardware 一书的作者，还在 SQL Server MVP Deep Dives 以及 SQL Server MVP Dives, Volume 2 两本书中贡献了部分章节。他还是丹佛大学的一名兼职教师，

在那里他完成了一些优秀教师项目，然后自 2000 年起开始教学。Glenn 的博客地址

为 http://sqlserverperformance.wordpress.com/，他的联系邮箱是 [email protected]，

Twitter 上的用户名是@GlennAlanBerry。

SQL Server 2012 深入解析与性能优化(第 3 版)

IV

● Gavin Payne 是 Coeo 公司的一名高级顾问，是 SQL Server 的微

软认证大师。作为一名技术架构师和数据库技术顾问，他重点关

注 SQL Server 数据库平台的范围、设计和实施，以及优化和改进

现有环境。他也组织地区性 SQL Server 社区活动，并出席欧洲区

的一些活动，如 SQLBits 和 SQLSaturdays。在加盟 Coeo 之前，

Gavin 是一名为托管服务提供商工作的解决方案架构师。在外包

关系的售前及售后阶段，他担当的是技术权威这样的角色。他出

生在历史悠久的 Cotswolds 地区，现居住在英格兰南部。他工作以外的兴趣是阅读

关于战后政策及电子情报收集历史的资料，以及旅游。可以通过 [email protected]与他联系。

● Amit Banerjee 现在是微软的一名高级现场工程师，专门从事

SQL Server 环境的积极咨询协助。过去，他是微软 SQL Server升级服务团队的一员，这个团队的工作涉及在各种环境中与 SQL Server 相关的故障排除和复杂问题处理。他的工作是在 SQL Server 环境中，为各种业务领域的领先公司提供帮助，帮助他们

为任务关键和业务关键的应用程序确定和纠正与 SQL Server 技

术相关的问题。除了他的日常工作，他还为 SQL Nexus、SQL Server Backup Simulator和 SQL diag/PSSDiag Configuration Manager 等工具的开发做出了贡献。

● Rob Farley 经营着 LobsterPot Solutions 公司，这是一家位于澳大

利亚阿德莱德的微软金牌合作者 SQL Server 及商业智能咨询公

司。Rob 经常出席 PASS 峰会以及各种会议，如 TechEd Australia、 SQL PASS 和 SQLBits (UK)，同时还是阿德莱德 SQL Server User Group 的领导人。从 2006 年开始，他就已经是 SQL Server MVP了，还是一名微软认证培训师，帮助建立一些 MCP 的考试。他

也是 PASS 组织的一名主管。他的博客网址是 http://sqlblog.com/ blogs/rob_farley。Rob 工作勤奋，也深爱着他的妻子、三个孩子、他的教堂和阿森

纳足球俱乐部。

贡献者简介

● Michael Anderson 是位于华盛顿州雷德蒙市的微软 IT 部门的一名高级系统工程

师。作为存储架构师以及数据库系统设计者，他已经工作超过 15 年了，他从 6.5版本就开始优化微软的 SQL Server 系统。他的行业经验包括在微软信息技术和在

线服务部门工作超过了 10 年。他是 Bing 的广告引擎、微软 adCenter 的早期成员之

一，将 Bing 服务从刚起步发展成为互联网上的第二大广告引擎。他具有设计 SQL Server 数据仓库及商业智能系统的经验。Michael 现在专职于设计微软 IT 的

Hyper-V 私人云系统。他是许多微软和 EMC 白皮书的作者及贡献者，他的 SQL I/O 性能博客的地址是 http://sqlvelocity.typepad.com.

● James Boother 是 Coeo 公司的高级顾问，一家微软的金牌合作者公司。James 作

为一位数据库开发人员开始了他的职业生涯，拥有在开发和 IT 部门内工作超过 10年的广泛 IT 经验，进行包括数据库管理、系统管理和部门管理的开发工作。他目

前负责设计关键任务的 SQL Server 环境的架构，并负责实施和故障排除。他是一

个充满激情的.NET、PowerShell 和 SQL 开发人员，并定期提出有关这些的主题。

他与妻子和三个孩子居住在伦敦北部。工作之余，James 喜欢赛车运动，并且经常

可以发现他在电视和赛道上观看一级方程式比赛。可通过 [email protected] 与 James联系。

● Steven Wort 自从 1993 年以来，从运行在 OS2 上的 4.2 版本开始，就已经从事与

SQL Server 相关的工作。他在各种行业中工作，拥有在 IT 行业开发应用程序超过

30 年的经验。Steven 于 2000 年作为系统集成工程(Systems Integration Engineering，SIE)团队中的一名专家级工程师加入微软，在那里与他人共同撰写了多个关于调试

Windows 和.NET 的研讨文档。2004 年，他转移到 SQL Server 团队从事 SQL Server 2005 的可扩展性工作。在 Windows 组中致力于缩放大型的数据库系统之后，他现

在已经回到了 SQL Server 团队，正从事于构建一系列基于 SQL Server 的应用。

Steven 曾参与撰写了多本关于 SQL Server 管理、故障排除和性能调优的书籍。

技术编辑简介

● Robert L. Davis 是一名高级产品顾问，并且是 Idera 软件主要的 SQL Server 的传播

者，他与他们的开发团队密切合作来帮助创建更好的 SQL Server 工具。此前，他

曾在 Microsoft Learning 担任 SQL Server 认证大师课程的课程经理。他也曾是微软

的一位资深的生产 DBA，有管理 SQL Server 超过 12 年的经验。他是 Pro SQL Server 2008 Mirroring 的作者之一，SQL Server Magazine 的专栏作家，一位 SQL Server 2008的微软认证大师，以及演讲者和培训师。

● Richard Douglas 是 MCITP、MCTS、MCP，并担任 Quest 软件公司的系统顾问，

他专门研究 SQL Server，并为欧洲、中东和非洲地区的组织机构提供解决方案和系

统健康检查。Richard 最近担任社区网站 www.SQLServerPedia.com 的首席主编，这

个网站提供了 SQL Server 的文章和博客聚合服务。他还经常为美国、欧洲、中东

和非洲的观众举办在线研讨会。作为 SQL Server 社区的一位热心成员，他在英国

创办和运作一个 PASS 分会，并且是被称为 SQLRelay 的一个全国性活动的组委会

中的一员。 ● Laerte Junior 是一位技术熟练的首席数据库架构师、开发人员和管理员，专门研究

SQL Server 和 PowerShell 编程，拥有超过 8 年的实践经验。他拥有计算机科学学位，

已经获得了一些认证，并且是 SQL Server 2000、SQL Server 2005 和 SQL Server 2008技术专家。通过他的技术博客以及在 Simple-Talk 网站上发表的文章，作为一名 SQL Server 和 PowerShell 社区的活跃成员，他还组织了已经吸引数百名与会者参加的微

软社区活动，并在活动中发表演讲。 ● Jonathan Kehayias 是 SQLskills 的一名首席顾问和培训师。他也是一名 SQL Server

MVP 和微软之外少数 SQL Server 2008 微软认证大师之一。他经常发布有关 SQL Server 的博客，出席 PASS 峰会、SQLBits、SQL Connections 和本地的 SQL Saturday活动的会议，并且自从 2007 年以来一直是 MSDN 的 SQL Server 数据库引擎论坛问

题答案的一个主要贡献者。Jonathan 是一名 SQL Server 和硬件的性能优化专家，而

且作为一名开发人员、业务分析师和 DBA 已经架构了复杂的系统。他也拥有广泛

的开发(T-SQL、C#和 ASP.NET)、硬件和虚拟化设计的专业知识，拥有 Windows专业知识，还有丰富的 Active Directory 经验和 IIS 管理经验。可通过 Twitter 上的

用户名@SQLPoolBoy或者通过博客http://sqlskills.com/blogs/jonathan联系 Jonathan。

技术编辑简介

VII

● Thomas Kejser 持有来自于丹麦 DAIMI 的计算机科学硕士学位，并具有涵盖众多

行业类别的行业经验，包括电信运营商、软件供应商、医疗保健、制造业、零售商

和投资银行。他最近的成就包括建立几个 TB 大小的数据仓库、建立超大规模的

OLTP 系统，以及调优数据传输速度的世界纪录。当他没有指导开发人员和 DBA时，他为微软出版白皮书，并将他的想法发布在 http://blog.kejser.org。Thomas 目前

居住在伦敦，他喜欢在业余时间拿着一杯上好的威士忌与朋友一起讨论哲学。 ● James Rowland-Jones 是 Big Bang Data 公司的 SQL Server 顾问和微软 MVP。他

满怀激情地全心投入到架构的研究中并提供高度可扩展的数据库系统，这些系统按

照他们的设计具备创造性、简单性和优雅性。他曾为世界上一些最大的公共机构工

作，负责欧洲、中东和非洲地区的项目交付。James 曾从事 OLTP 和 BI 与数据仓库

支持工作。最近，他花了很多时间研究 SQL Server 的参考架构和应用，尤其是 Fast Track 和 PDW。在国际和英国的 SQL Server 社区，James 是一位热心的倡导者，他

是 SQLBits 组委会的成员，目前是 PASS 董事会的一员。可通过 twitter 上的用户名

@jrowlandjones，或者邮件 [email protected] 联系他。 ● Mike Walsh 是一名 MVP，是咨询服务公司 Straight Path IT Solutions 的 SQL Server

顾问，也是 Linchpin People(一家专注于服务的 SQL Server 咨询公司)的合作伙伴。

自 SQL Server 6.5 以来，SQL Server 就贯穿他的整个职业生涯，他一直作为一个

DBA、开发人员和性能专家，从事与 SQL Server 相关的工作。最近，他一直在帮

助许多公司建立 DBA 的最佳实践，最有效地利用他们的 SQL Server 基础设施，设

计具有高度可用性和可扩展性的系统。他为客户和 DBA 团队提供指导和定制培训。

Mike 作为一名演讲者、博客使用者、用户组组长、PASS 志愿者和当地活动的组织

者，仍活跃在 SQL Server 社区。他在 twitter 上的用户名是@ mike_walsh，可以通

过他的博客 www.straightpathsql.com 或者电子邮件 [email protected] 与他

联系。

致谢

我们都已经拥有那些被认为是必备的 SQL Server 书籍，每一位认真的 SQL Server 专业

人员都将其骄傲地展示在自己的书架上，但几乎从来不去翻阅。我不喜欢我已帮助撰写的

图书只成为书架上的一个纪念品。得到有关本书 SQL Server 2008 版本的最佳反馈是在一个

客户现场，当时我看到一本被翻烂的书上布满了彩色编码的书签。无意中从一个完全陌生

人那儿得到的反馈意见对我来说意义重大，并且在本书撰写期间，在很大程度上使我保持

情绪高涨，所以我想要感谢那些匿名的 IT 专业人士和其他花费时间为我们提供反馈的所有

人—— 没有你们，本书将不可能顺利付梓。特别感谢本书所有的作者和贡献者参与到这个项目中，尤其是 Justin Langford和Steven

Wort，因为他们完全知道将面临的困难，但无论如何他们还是参与进来了。该书上一版的

创作团队相当成功，所以对于这一版，我只好全力以赴让它更成功。我从未想象过能凝聚

这样一个优秀团队，你只需看一下每个人的简历就能明白我的意思。他们都是伟大的人，

我很自豪我的名字能与他们联系在一起。每个伟大的写作团队的背后，都有一个伟大的技术编辑团队，在完成这个项目期间，

我一直很幸运，得到了同行业中最优秀的一些人来指点我们的工作。我非常感谢那些默默

无闻的支持者，是他们使得我们的工作经得起推敲。最后，我想感谢妻子 Gemma、孩子 Ava 和 Leighton，感谢他们对我的容忍，容忍我连

续地保证是“最后一次”写作项目。我虽然不会那么天真地说：“再也不会有最后一次了”，

但我能保证这次我会休息很长时间。 —— Christian Bolton

在过去 12 个月中，尤其是在写作期间，我体会到了合作的价值，而在此之前我通常

并没有这样的合作机会。首先，我必须感谢 Christian，他是我的经理和这本书的主要作

者，他为我提供了编写其中两章的机会，我以自己的风格和从自己的观点精心撰写了这

两章。其次，要感谢两位技术编辑 Jonathan Kehayias 和 Robert Davis。Jonathan 的虚拟化知

识给我提供了第 1 章所需要的质量基准，同时他的关于扩展事件的社区贡献，为另一章提

供了宝贵的研究资料，这一章的录入工作由 Robert 准确完成，在此感谢他！最后感谢 Neil和 Chris。

—— Gavin Payne

致谢

IX

我要感谢我的妻子和孩子—— 他们是我所做的几乎所有事情背后的动力。此外，当

Christian 要求我参与时，我并不知道我之后会患病数月，所以我非常感谢我从他和 Wiley与 James Roland-Jones 团队(他们参与了本书第 1 版的创作，第 1 版是本次版本的强大基础)那里所得到的支持。来自于微软 SQLCAT 团队关于闩锁的工作是非常有帮助的，尤其是

Thomes Kejser，他为我仔细审查了这一章。这些都是我应该感谢的贡献者。 —— Rob Farley

前言

如果你在排除一个很明显的 SQL Server 问题，那么不仅需要检查 SQL Server 本身，还

需要能够检查底层的操作系统和存储系统。因此，本书试图把这些部分放在一起描述，并

且简化对这些组件细节的描述，之后向你介绍成功的 SQL Server 专业人员日常使用的取得

良好效果的工具和技术。尽管现在有很多关于 Windows 和硬件内部原理的资料，但是这些资料几乎都没有精选

出适合 SQL Server 专业人员使用的信息。有用的资料要么太简单，要么太深奥，都没有很

好地填平 SQL Server 专业人员和底层原理之间的知识鸿沟。本书满足了 SQL Server 专业人员对 SQL Server 内部原理实用信息的需求，全面介绍了

来自于 SQL Server 社区和 SQL Server 自身的可用的故障排除工具，实现了以下三个目标： ● 提供了易于理解的关于 SQL Server 内部体系结构(以及它所依赖的环境)的深入

信息。 ● 展示了一些免费的和包含在 SQL Server 内的故障排除工具的实用介绍。 ● 针对以上两个目标，使用实例来帮助 SQL Server 专业人员高效准确地确定运行 SQL

Server 的系统的故障根源所在。

本书读者对象

本书的目标读者对象是那些想成为SQL Server专业人员的人士或已经涉足关系数据库

领域的 SQL Server 专业人员。这里，SQL Server 专业人员指的是那些将 SQL Server 作为主

要产品技能，并且愿意持续深入了解这个产品及其使用的人们。本书并不面向初学者，因此假定你已经具备关于 SQL Server 的一些基础知识，例如，

知道如何安装、使用及配置 SQL Server，并且能够意识到仅使用 SQL Server 提供的原生工

具进行 SQL Server 故障排除是有一定挑战性的这个事实。然而，本书为了那些对本书所提

及的一些主题信心不足的读者，竭尽全力地使用很轻松的方式描述了 SQL Server 的各个

方面。本书主要分为两大部分。第Ⅰ部分描述了底层的内部原理，帮助读者建立理解核心概

念的扎实基础，并描述了帮助理解本书第Ⅱ部分介绍的那些工具的输出和配置所需的知识。

如果你对底层内部原理的知识掌握得很扎实，那么可以直接跳过这部分内容从第Ⅱ部分开


XII

始阅读本书，在需要澄清一些概念时再返回第Ⅰ部分查阅相关内容。

本书主要内容

在描述本书结构和每章内容之前，要先了解一下本书讨论的主题最初是由哪些关键驱

动因素和假设确定的。

内部工作原理

在很多与 SQL Server 相关的工作中，并不需要对 SQL Server 内部工作原理十分了解。

你可以找到很多完善的规范指南和一个非常活跃且很有帮助的社区。可总有一天，你会发

现这些帮助都不够用了(通常都是在发生十分严重的问题时)。例如，在发生意外服务中断的时候，有两种选择，即尽快还原服务还是为了防止这种

故障再次发生而收集足够多的数据以检测问题所在。在这两种选择之间，你需要快速决策

以达到两种需求的平衡。这种情况下，不可能寻求外部帮助，因为外援可能不太及时。这

时如果对 SQL Server 的内部工作原理有足够的了解，就能快速地独立做出决策。几年前，一个微软客户在 SQL Server 上运行的大型关键业务数据库崩溃了。公司决定

必须将这个数据库下线直到修复为止，因为这个数据库保存了金融交易数据，任何错误都

会导致灾难的发生。 SQL Server 中有一个 DBCC CHECKDB 命令可用来帮助检测和解决数据库崩溃的问

题，客户首先运行了这个命令，但在 8 个小时之后将这个命令终止了，他们决定进行数据

库还原。而备份已经损坏，所以他们不得不再次运行 CHECKDB 命令，这次又花了 12 个

小时的时间才把问题解决。这是个非常耗时的灾难，由于这次故障导致这个客户在故障期

间无法向金融市场提供服务，因此这名客户为此支付了巨额罚金。从这个例子中得到的直观教训就是，在检测到崩溃时，首先要测试备份是否可用，还

要了解 CHECKDB 命令会运行多长时间(CHECKDB 在检测到崩溃时会运行更长的时间，

因为需要进行另一轮更深入的检查)。当然，如果对 SQL Server 内部工作原理有一点点的

了解，就会得到这种所谓的“最佳实践”。事实是，这里讲述这个例子是为了讲解这个故障应该如何解决。检测到这个问题的

最初错误消息包含了一个损坏页面的详细信息。有了这个数据页的页码，故障排除小组

就可以使用 DBCC PAGE 命令来检查这个页面的头信息，从中找到这个页面对应的数据

库对象。这里，这个页面属于非聚集索引(non-clustered index)，因此只要重建这个索引就

可以了，而不需要将整个数据库下线并且运行 CHECKDB 或还原整个数据库。这就是为什

么知道“内部工作原理”十分重要的原因，只有理解了内部原理，才能独立地找到最佳解

决方案。本书讲述了 Windows 和 SQL Server 的内部工作原理，通过这些，你就可以了解你的

应用程序的工作环境了。本书还讲述了如何配置服务器以达到不同需求下的最优化配置，

前言

XIII

以及在出现重大问题但尚未理清头绪的情况下如何避免盲目做决策。

故障排除以及实战经验

本书第Ⅱ部分讲解了一系列免费的故障排除工具，利用这些工具，可以帮助你构建结

构化且高效的故障排除策略。因为对于初学者来说，这些工具过于复杂且难学，这些章节

里的一些简明实用的指南可大大简化你的工作——无论是日常问题还是严重的问题。本书这部分基于真实世界的操作经验，提供坚实的案例经验而不是泛泛的“如何操作”

之类的建议。这种方法在本书此前的一些版本中，包括 SQL Server 2008，得到不少正面反

馈，所以我们沿用并进一步扩展了这种理念。

本书结构

本书第 I 部分首先对 SQL Server 的体系结构进行一个高层次的概述，其中有部分章节

讲述了对于 SQL Server 非常重要的三个核心资源：内存、存储器和 CPU。在这些章节之间

的策略部分穿插了其他一些章节的内容，这些章节讲述了对于理解高效故障排除非常重要

的一些概念，包括查询处理、查询执行、锁、并发、闩锁、自旋锁以及 tempdb 数据库。第Ⅱ部分以人性化和过程驱动方式考虑如何排除故障。然后开始介绍一些工具和技

术，这些工具和技术能够很好地独立工作，但使用 SQL Nexus 可以汇集成一种简单的用于

分析的解决方案。接下来的章节让你开始熟悉扩展事件和 SQL Server 2012 中引入的新用户界面，逐渐让

你适应使用 PowerShell 进行故障排除，使用动态管理视图(DMV)建立自己的健康检查，以

及满足管理大型 SQL Server 资产的挑战。最后，你将了解服务器虚拟化对于 SQL Server 的意义，以及如何确定迁移到虚拟环境

的最佳候选者。下面列出每章的概述，使你在本书的上下文环境中了解各章内容，以便决定从哪里开

始阅读。

第 1 章：SQL Server 体系结构

该章简述了一个查询的整个生命周期，对这个生命周期的描述既能足够深入地讲解

SQL Server 的一些基础概念和体系结构，又不会陷于单独组件复杂的细节中(其中一些组件

会在后续章节中详细描述)。不论你是开发人员，还是数据库管理员或是经验丰富的 SQL Server 老手，该章的内容

对于每一个技能层次的读者都很有价值。

第 2 章：硬件揭秘

经过筛选、大小合适的现代硬件和存储空间是决定数据库良好的性能和可扩展性的必

要基础。遗憾的是，许多数据库业内人士跟上服务器的硬件和 I/O 子系统的最新发展并不


XIV

容易，经常依赖于其他人(可能是不熟悉 SQL Server 的人)去选择硬件和 I/O 子系统。这样

可能会造成大小不恰当和不合适的硬件，从而不能很好地支持不同类型的 SQL Server 工作

负荷。该章介绍了一些工具和技术，帮你在数据库服务器的硬件和容量的选择上进行明智

决定。

第 3 章：理解内存

内存是对 SQL Server 进行故障排除的一个重要方面，因为内存出问题会导致其他任何

的地方出现故障。想成为 SQL Server 专业人员，理解内存应该是你需要掌握的第一个领域。该章介绍在 Windows 上运行的所有应用程序所共用的内存的基础概念，SQL Server 如

何通过 Windows 与内存相互作用，以及 SQL Server 如何管理内部存储。

第 4 章：存储系统

理解 I/O 一直是 DBA 的主要任务之一。不过职责分离在许多环境中是很常见的。很多

情况下，负责确保 I/O 性能和高可用性的职责分配给了 SAN 管理员。DBA 和 SAN 逐渐会

使用不同的语言去描述他们不同的需求和解决方案，这就导致了两个群体之间令人沮丧的

隔阂。不过，在存储世界中如今还是一片混战。直连式存储(DAS)依然十分流行——这主要

归功于固态硬盘(SSD)的出现。SSD 在显著减少设备数量、能源成本和数据中心占地面积

的同时，提供了指数级的性能提升，从而给存储界带来了一股清新空气。 DAS 的应对措施也很有趣，因为他们也将权力和职责返回给服务器的主人——对于数

据库平台来说就意味着是 DBA，让他们进行选择。SQL Server 2012 提供了一些非常引人

注目的以应用为中心的可用性选择，再一次给用户提供了评估 DAS 作为他们平台选择的一

个机会。该章帮助读者更好地理解 SAN 管理员和 DBA 的需求，还探究了一些 SAN 管理员所

面临的设计层面的选择以及在企业内部提供存储所需的一些平衡。你将会读到一些 SAN所能够提供的优势，以及典型的功能和特点，使你能够连接 DBA 和 SAN 管理员之间的技

术鸿沟。该章还包括了当准备存储时，为了正确决策，SAN 管理员需要从 DBA 那里得到

的信息的综述。

第 5 章：查询处理和执行

SQL Server 内部的查询处理涉及很多组成部分，在该章你将了解到查询优化的框架，

以及如何利用统计信息和成本找到执行代码的较好途径。该章也介绍了如何阅读执行计划，

以及让 SQL Server 有更多机会建立一个良好的执行计划的代码优化技术。

第 6 章：锁和并发

“事务”是关系型数据库管理系统(RDBMS)的核心。如果一个数据库每秒不能处理上

千条事务，就会被无情地淘汰。不过，缺少数据完整性保证的处理能力是没有意义的。一

前言

XV

些高端的数据库平台，比如 SQL Server，都具有复杂的机制用于提供极好的处理能力和管

理数据的完整性，从而能提供可预计的输出结果。该章展示了数据库的性能是由“处理事务”的能力决定的。因为糟糕的设计或者繁重

的事务负担会严重影响 SQL Server 的性能，该章从 SQL Server 机制中的最底层进行讲解，

通过事务、锁架构以及通过利用乐观并发模型增强性能来管理数据的完整性。

第 7 章：闩锁和自旋锁

随着数据量的持续增长，DBA 面临着更大、需求更多的系统。如今的工作负荷可以引

发 SQL Server 内部巨大的处理压力，尤其是在默认设置的情况下。其中一个能明显感觉的

这种压力的内部区域是闩锁。理想情况下，DBA 从来不必担心闩锁问题。闩锁只在保证数

据在内存中的完整性时才存在。不过，数据库资源经常等待闩锁，从而导致整个系统速度

降低。该章从闩锁结构的基础开始引导，解释了如何故障排除闩锁争用的问题，最后以最小

化和减缓任何风险为原则介绍了一些最佳实践的指导。

第 8 章：了解 tempdb 数据库

应用程序使用 tempdb 来存储临时对象，SQL Server 用它来存储处理内部查询的临时结

果。一个 SQL Server 数据库实例只有一个 tempdb。自从 SQL Server 2005 引进一些频繁使

用 tempdb 的新功能以来，比如在线索引和快照隔离级别，tempdb 变得越来越重要了。该章还将介绍哪些功能会用到 tempdb，启用这些功能会对性能有哪些影响，以及如何

监视和调整数据库以获得最佳性能和可用性。

第 9 章：故障排除方法论和实践

该章提供了对复杂问题有效的进行故障排除的框架。内容包括如何确定 SQL Server 问题，何时使用书中讨论的工具，以及如何诊断复杂问题。该章列举了一些实例来概述解决

SQL Server 问题的方法，还提供了使你能快速找到问题根源的指导。

第 10 章：通过 PerfMon 和 PAL 工具查看服务器性能

自 Windows NT4 以来，性能监视器(Performance Monitor)就是一个主要的数据收集和

报表工具，随着时间的推移，性能监视器越来越大，作用范围也越来越广。该章演示了如何使用性能监视器来优化数据收集以降低监视对被监视系统的影响，还

演示了如何将数据直接导入 SQL Server，对结果运行自己的 T-SQL 查询。该章还介绍了日

志性能分析(Performance Analysis of Logs，PAL)工具，使用 PAL 极大简化了对捕获的大量

数据进行的分析。

第 11 章：通过 SQLdiag 整合数据收集

SQLdiag 是 SQL Server 2005 中首次引入的一个用于协调性能监视器日志数据收集和


XVI

SQL 跟踪数据收集的强大工具，此外，SQLdiag 还能收集其他系统数据。该章将讲解如何配置、定制及运行 SQLdiag，还讲解了 Microsoft 的性能统计

(Performance Statistics，PerfStats)脚本，利用 PerfStats 可以向 SQLdiag 协调的数据收集器列

表中添加锁、阻塞和等待统计数据。 SQLdiag 是高效数据收集的原因所在，任何还没有大量使用过这个工具的用户都必须

阅读该章。

第 12 章：通过 SQL Nexus 整合一切

SQL Nexus 是 Microsoft 的 SQL Server 升级工程师开发的一套免费软件工具，它整合

了前面章节所描述的其他所有工具的分析和报表功能，因此 SQL Nexus 可以说是排除 SQL Server 故障的瑰宝。

利用从 PerfStats 脚本获得的整合数据集合，SQL Nexus 将载入数据库并分析性能监控

日志数据、使用 ReadTrace(已内嵌在工具中)的 SQL 跟踪文件、锁以及阻塞信息(包括实际

语句的阻塞链和执行计划的细节)以及聚合的 SQL Server 等待数据。该章讲述了如何配置和运行 SQL Nexus，以及如何从 SQL Nexus 生成的报表中得到结

论。到目前为止，SQL Nexus 是所有花时间学过这个工具的人士的故障排除工具箱中最有

用的工具。

第 13 章：使用扩展事件诊断 SQL Server 2012

该章介绍了扩展事件的结构，以及如何利用它来使你的故障排除能力提高一个等级。

扩展事件提供了一个低影响、高度灵活且功能强大的捕捉故障排除信息的方法——可让你

了解困难和间歇性的问题，这些问题使用传统方法是无法诊断出来的。

第 14 章：使用 PowerShell 增强故障排除工具集

Windows 平台上的管理活动一般在 GUI 应用程序中实现，比如 SQL Server Management Studio。PowerShell 改变了管理方式，尤其是对于故障排除和性能调优等活动。

该章展示了 Powershell 是如何整合到 Windows、WMI、注册表和文件系统中，尤其是

如何与 SQL Server 深度整合。之后你可以探寻使用 PowerShell 如何进行 SQL Server 的故

障排除，集中于确定哪些关键资源在哪里被使用，以及 PowerShell 如何帮助解决发现的

问题。该章还包含了一些主动的性能调优脚本，可用来监控和调整 SQL Server 环境。

第 15 章：提供 SQL Server 健康检查

自从动态管理视图(DMV)加入到 SQL Server 2005 中后，在每个版本的 SQL Server 中都得到了增强。动态管理视图提供了极其宝贵的丰富信息资源，不仅包括 SQL Server 的配

置、健康状况和性能等指标，还包括数据库个人用户的有用指标。

前言

XVII

该章涵盖了大量的动态管理视图查询，你可以把它用作评估 SQL Server 实例和数据库

的健康状况和性能的一个诊断工具。此外，还提供了一些有价值的背景知识，以及可用来

正确地解释每个查询的结果的具体秘诀。

第 16 章：提供可管理性和性能

该章介绍了管理一个 SQL Server 实体的一些挑战。该章涵盖了各个角度的可管理性，

比如配置管理、性能、容量计划和自动化管理。SQL Server 内的一些功能也有所介绍，包

括基于策略的管理和多服务器管理等。该章提供了关于开箱即用工具、社区解决方案(如企

业策略管理框架)和监控工具(如系统中心操作管理器)的好处和限制的实际建议。

第 17 章：在虚拟环境中运行 SQL Server

该章首先介绍了虚拟化概念以及良性争用和恶性争用之间的差异，之后介绍在构建成

功的虚拟化数据库平台之前，如何确定对于好的虚拟化候选者。这个过程聚焦于内存、存

储、CPU 和高可用性。该章最后讨论如何监控实施后的虚拟系统的性能。

阅读此书你还需要什么

本书中的示例已在SQL Server 2012 Standard版、Enterprise版和Developer版中编写并测

试。SQL Server 2012的Developer版和Evaluation版易于获得，并与Enterprise版以同样的方

式运行。书中例子的源代码可以从Wrox网站www.wrox.com/retitle.cgi?isbn=1118177657上获得。

一些约定

本书使用两种方式显示源代码： ● 大部分的源代码例子使用等宽字体显示，没有突出显示 ● 当前上下文中特别重要的例子或与此前代码有所不同之处会用粗体显示

源代码

在读者学习本书中的示例时，可以手动输入所有代码，也可以使用本书附带的源代码

文件。本书使用的所有源代码都可以从本书合作站点 http://www.wrox.com/或 http://www. tupwk.com.cn/downpage 上下载。登录到站点 http://www.wrox.com/，使用 Search 工具或

使用书名列表就可以找到本书。接着单击 Download Code 链接，就可以获得所有的源代

码。既可以选择下载一个大的包含本书所有代码的 ZIP 文件，也可以只下载某个章节中

的代码。


XVIII

在下载代码后，只需用解压缩软件对它进行解压缩即可。另外，也可以进入 http://www.

wrox.com/dynamic/books/download.aspx 上的 Wrox 代码下载主页，查看本书和其他 Wrox图书的所有代码。

勘误表

尽管我们已经尽了各种努力来保证文章或代码中不出现错误，但是错误总是难免的，

如果你在本书中找到了错误，例如拼写错误或代码错误，请告诉我们，我们将非常感激。

通过勘误表，可以让其他读者避免受挫，当然，这还有助于提供更高质量的信息。要在网站上找到本书英文版的勘误表，可以登录 http://www.wrox.com，通过 Search 工

具或书名列表查找本书，然后在本书的细目页面上，单击 Book Errata 链接。在这个页面上

可以查看到 Wrox 编辑已提交和粘贴的所有勘误项。完整的图书列表还包括每本书的勘误

表，网址是 www.wrox.com/misc-pages/booklist.shtml。如果你发现的错误在我们的勘误表里还没有出现的话，请登录 www.wrox.com/contact/

techsupport.shtml 并完成那里的表格，把你发现的错误发送给我们。我们会检查你的反馈

信息，如果正确，我们将在本书的勘误表页面张贴该错误消息，并在本书的后续版本加

以修订。

p2p. wrox.com

要与作者和同行讨论，请加入 p2p.wrox.com 上的 P2P 论坛。这个论坛是一个基于 Web的系统，便于你张贴与 Wrox 图书相关的消息和相关技术，与其他读者和技术用户交流心

得。该论坛提供了订阅功能，当论坛上有新的消息时，它可以给你传送感兴趣的论题。Wrox作者、编辑和其他业界专家和读者都会到这个论坛上来探讨问题。

在 http://p2p.wrox.com 上，有许多不同的论坛，它们不仅有助于阅读本书，还有助于

开发自己的应用程序。要加入论坛，可以遵循下面的步骤： (1) 进入 p2p.wrox.com，单击 Register 链接。 (2) 阅读使用协议，并单击 Agree 按钮。 (3) 填写加入该论坛所需要的信息和自己希望提供的其他可选信息，单击 Submit 按钮。你会收到一封电子邮件，其中的信息描述了如何验证账户，完成加入过程。

由于许多图书的标题都很类似，因此按 ISBN 搜索是最简单的，本书英文

版的 ISBN 是 978-1-118-17765-5。

前言

XIX

加入论坛后，就可以张贴新消息，响应其他用户张贴的消息。可以随时在 Web 上阅读

消息。如果要让该网站给自己发送特定论坛中的消息，可以单击论坛列表中该论坛名旁边

的 Subscribe to this Forum 图标。要想了解更多的有关论坛软件的工作情况，以及 P2P 和 Wrox 图书的许多常见问题的

解答，就一定要阅读 FAQ，只需在任意 P2P 页面上单击 FAQ 链接即可。

不加入 P2P 也可以阅读论坛上的消息，但要张贴自己的消息，就必须先

加入该论坛。

目录

第 I 部分内核

第 1 章 SQL Server 体系结构...............3 1.1 简介 ..............................................3 1.2 数据库事务 ..................................4

1.2.1 ACID 属性 ................................ 4

1.2.2 SQL Server 事务 ....................... 5

1.3 一个查询的生命周期...................5 1.3.1 关系引擎和存储引擎 ............... 6

1.3.2 缓冲池....................................... 6

1.3.3 一个基本的 Select 查询 ........... 7

1.3.4 一个简单的更新查询 .............15

1.3.5 恢复.........................................17

1.4 SQL Server 的执行模式和 SQLOS...................................21 1.4.1 执行模式.................................22

1.4.2 SQLOS ....................................24

1.5 本章小结 ....................................25

第 2 章硬件揭秘 ................................27 2.1 硬件的重要性 ............................27 2.2 工作负荷如何影响硬件及

存储考虑事项 ............................28 2.2.1 工作负荷的类型 .....................28

2.2.2 服务器选型 .............................30

2.2.3 服务器型号的演变 .................30

2.3 处理器厂商的选择.....................32 2.3.1 Intel 处理器 ............................33

2.3.2 AMD 处理器及编号...............41

2.4 为冗余选择及配置硬件.............43 2.5 硬件比较工具 ............................45

2.5.1 TPC-E 基准.............................45

2.5.2 Geekbench 基准测试 ..............47

2.6 本章小结.....................................47

第 3 章理解内存................................ 49 3.1 简介.............................................49 3.2 物理内存和虚拟内存.................50

3.2.1 物理内存 .................................50

3.2.2 最大支持的物理内存 .............51

3.2.3 虚拟内存 .................................51

3.2.4 NUMA.....................................55

3.3 SQL Server 内存.........................59 3.3.1 内存节点 .................................60

3.3.2 内存分配员、缓存和

缓冲池 .....................................60

3.4 优化 SQL Server 内存配置 ........66 3.4.1 最小服务器内存和最大

服务器内存 .............................66

3.4.2 锁定内存页 .............................68

3.4.3 即席式工作负荷优化 .............70

3.5 本章小结.....................................72

第 4 章存储系统................................ 73 4.1 简介.............................................73 4.2 SQL Server I/O ...........................74 4.3 存储技术.....................................74

4.3.1 SQL Server 和 Windows I/O

子系统 .....................................78

4.3.2 选择合适的存储网络 .............80

4.3.3 共享存储阵列 .........................82

4.3.4 容量优化 .................................82

4.3.5 分层存储 .................................84

4.3.6 数据复制 .................................85

4.3.7 远程数据复制 .........................88


XXII

4.3.8 Windows 故障转移群集.........89

4.3.9 SQL Server AlwaysOn

可用性组.................................90

4.3.10 风险缓解计划 .......................91

4.4 测量性能 ....................................91 4.4.1 存储性能计数器 .....................92

4.4.2 磁盘驱动器性能 .....................93

4.4.3 顺序磁盘访问 .........................96

4.4.4 服务器队列 .............................97

4.4.5 文件布局.................................97

4.4.6 分区对齐.................................99

4.4.7 NTFS 分配单元大小 ..............99

4.4.8 闪存...................................... 100

4.4.9 存储性能测试 ...................... 101

4.5 本章小结 ..................................105

第 5 章查询处理和执行 ...................107 5.1 简介 ..........................................107 5.2 查询处理 ..................................108

5.2.1 分析...................................... 108

5.2.2 Algebrize .............................. 108

5.3 查询优化 ..................................109 5.3.1 并行计划.............................. 110

5.3.2 Algebrizer 树........................ 111

5.3.3 sql_handle 和 plan_handle ... 111

5.3.4 理解统计信息 ...................... 111

5.3.5 计划缓存和重编译 .............. 113

5.3.6 影响优化.............................. 119

5.4 查询计划 ..................................125 5.4.1 查询计划操作符 .................. 128

5.4.2 读取查询计划 ...................... 131

5.5 执行查询 ..................................135 5.6 本章小结 ..................................143

第 6 章锁和并发 ..............................145 6.1 简介 ..........................................145 6.2 事务 ..........................................146

6.2.1 A 是原子性 .......................... 146

6.2.2 C 是一致性 .......................... 147

6.2.3 I 是隔离性 ........................... 147

6.2.4 D 是持久性 .......................... 147

6.3 数据库事务...............................147 6.3.1 原子性 .................................. 147

6.3.2 一致性 .................................. 147

6.3.3 隔离性 .................................. 148

6.3.4 持久性 .................................. 148

6.4 并发的危险...............................149 6.4.1 丢失更新 .............................. 149

6.4.2 脏读 ...................................... 151

6.4.3 不可重复读 .......................... 152

6.4.4 幻影读 .................................. 154

6.4.5 重复读 .................................. 157

6.4.6 Halloween 效应.................... 158

6.5 锁...............................................159 6.5.1 监视锁 .................................. 159

6.5.2 锁资源 .................................. 161

6.5.3 锁模式 .................................. 163

6.5.4 兼容性表 .............................. 169

6.6 锁升级.......................................170 6.7 死锁...........................................171 6.8 隔离级别...................................171

6.8.1 可序列化 .............................. 172

6.8.2 可重复读 .............................. 173

6.8.3 已提交读 .............................. 173

6.8.4 未提交读和 NOLOCK......... 174

6.8.5 快照 ...................................... 174

6.8.6 已提交读快照 ...................... 174

6.9 本章小结...................................175

第 7 章闩锁和自旋锁....................... 177 7.1 简介...........................................177 7.2 症状...........................................178

7.2.1 识别症状 .............................. 178

7.2.2 检测闩锁争用 ...................... 179

7.2.3 检测自旋锁争用 .................. 180

7.2.4 争用指示器 .......................... 181

7.3 易受影响的系统.......................182 7.4 了解闩锁和自旋锁...................182

7.4.1 定义 ...................................... 182

目录

XXIII

7.4.2 闩锁示例.............................. 183

7.5 闩锁类型 ..................................190 7.6 闩锁模式 ..................................190

7.6.1 NL........................................ 191

7.6.2 KP........................................ 191

7.6.3 SH........................................ 191

7.6.4 UP........................................ 191

7.6.5 EX........................................ 191

7.6.6 DT........................................ 191

7.6.7 闩锁兼容性 ......................... 192

7.6.8 授权顺序 ............................. 192

7.6.9 闩锁等待 ............................. 193

7.7 超闩锁和子闩锁 ......................194 7.8 监控闩锁和自旋锁...................195

7.8.1 动态管理视图 ..................... 195

7.8.2 性能监视器 ......................... 196

7.8.3 扩展事件 ............................. 198

7.9 闩锁争用示例 ..........................199 7.9.1 当聚集索引键是 ID 字段

时的插入操作 ...................... 199

7.9.2 队列 ..................................... 200

7.9.3 tempdb 中的更新闩锁 ........ 203

7.9.4 名称解析中的自旋锁争用 ... 204

7.10 本章小结 ................................205

第 8 章了解 tempdb 数据库 .............207 8.1 简介 ..........................................207 8.2 概述和使用 ..............................208

8.2.1 用户临时对象 ..................... 208

8.2.2 内部临时对象 ..................... 213

8.2.3 版本存储区 ......................... 213

8.3 常见故障排除 ..........................217 8.3.1 闩锁争用 ............................. 217

8.3.2 监视 tempdb 的 I/O 性能 .... 226

8.3.3 空间问题故障排除 ............. 228

8.4 配置最佳实践 ..........................229 8.4.1 tempdb 的文件布局 ............ 229

8.4.2 tempdb 的初始大小和

自动增长.............................. 231

8.4.3 配置多个 tempdb 数据

文件 ...................................... 234

8.5 本章小结...................................234

第Ⅱ部分故障排除工具和实战经验

第 9 章故障排除方法论和实践 ........ 239 9.1 简介...........................................239 9.2 处理问题...................................240

9.2.1 成功排除故障的十个步骤 ... 240

9.2.2 行为和态度.......................... 242

9.2.3 成功标准.............................. 242

9.2.4 与利益相关者打交道 .......... 243

9.2.5 服务水平协议...................... 244

9.2.6 聘请外界帮助...................... 244

9.3 定义问题...................................245 9.3.1 识别问题的指导方针 .......... 245

9.3.2 隔离问题.............................. 246

9.3.3 性能瓶颈.............................. 247

9.4 数据收集...................................249 9.4.1 关注数据收集...................... 250

9.4.2 了解数据收集过程 .............. 250

9.4.3 工具和实用工具.................. 251

9.5 数据分析...................................252 9.6 验证和实施解决方案...............253

9.6.1 验证变更.............................. 253

9.6.2 孤立地测试变更.................. 254

9.6.3 实施解决方案...................... 254

9.7 本章小结...................................254

第 10 章通过 PerfMon 和 PAL 工具查看服务器性能 ................. 255

10.1 简介.........................................255 10.2 性能监视器概述.....................256

10.2.1 可靠性和性能监视器 ...... 257

10.2.2 SQL Server 2012 在 PerfMon

中新添的计数器 .............. 259

10.2.3 PerfMon 入门................... 262

10.3 性能监视器使用进阶.............271 10.3.1 瓶颈和 SQL Server .......... 272


XXIV

10.3.2 规范性指南...................... 273

10.3.3 等待统计信息分析 .......... 278

10.3.4 获得性能基准.................. 278

10.4 日志性能分析 ........................278 10.5 其他 PerfMon 日志分析工具 ...282

10.5.1 通过 SQL Server 分析

PerfMon 日志................... 282

10.5.2 结合 PerfMon 日志和

SQL Profiler 跟踪 ............ 282

10.5.3 使用 Relog ....................... 283

10.5.4 使用 LogMan ................... 284

10.5.5 使用 LogParser ................ 285

10.6 本章小结 ................................285

第 11 章通过 SQLdiag 整合数据收集 ...................................287

11.1 数据收集的困境.....................287 11.2 数据收集的方法.....................288 11.3 熟悉 SQLdiag .........................289

11.3.1 在快照模式下使用

SQLdiag ........................... 290

11.3.2 作为一个命令行工具

使用 SQLdiag .................. 291

11.3.3 作为一个服务使用

SQLdiag ........................... 294

11.4 使用 SQLdiag 配置管理器 ....297 11.4.1 用 Diag 管理器配置

SQLdiag 数据收集 .......... 298

11.4.2 为 SQLdiag 配置添加

跟踪过滤器...................... 301

11.5 使用最佳实践.........................310 11.5.1 更好地收集长期数据 ...... 310

11.5.2 过滤噪音.......................... 311

11.5.3 用 SQLdiag 进行警报

驱动的数据收集 .............. 314

11.6 本章小结.................................314

第 12 章通过 SQL Nexus 整合一切 ...315 12.1 介绍 SQL Nexus.....................315 12.2 熟悉 SQL Nexus.....................316

12.2.1 先决条件 .......................... 316

12.2.2 将数据加载到 Nexus

数据库中 .......................... 318

12.2.3 分析聚合数据 .................. 321

12.3 自定义 SQL Nexus .................329 12.3.1 使用 ReadTrace.exe ......... 330

12.3.2 为 SQL Nexus 建立

自定义报表 ...................... 331

12.3.3 使用命令提示符运行

SQL Nexus ....................... 331

12.3.4 在 SQL Nexus 数据库中

创建自己的表格 .............. 331

12.3.5 编写自己的查询 .............. 333

12.3.6 OSTRESS 可执行文件 .... 334

12.4 解决常见问题.........................335 12.4.1 问题 1............................... 335

12.4.2 问题 2............................... 335

12.4.3 问题 3............................... 336

12.4.4 问题 4............................... 336

12.5 本章小结.................................337

第 13 章使用扩展事件诊断 SQL Server 2012 ...................... 339

13.1 介绍扩展事件.........................339 13.2 熟悉扩展事件.........................340 13.3 使用扩展事件的原因.............340

13.3.1 SQL Server 路线图 .......... 341

13.3.2 图形工具 .......................... 341

13.3.3 低影响 .............................. 341

13.3.4 使用扩展事件的时机 ...... 342 13.4 扩展事件的含义.....................342

13.4.1 扩展事件名称的来源 ...... 343

13.4.2 扩展事件术语 .................. 343

13.5 在 SQL Server 2012 中创建扩展事件.................................352 13.5.1 介绍新会话窗体 .............. 352

13.5.2 监控服务器登录 .............. 356

13.5.3 用扩展事件监控页拆分 .. 357

13.5.4 计算每个对象获得锁的

次数 .................................. 358

目录

XXV

13.5.5 用 T-SQL 创建会话.......... 360

13.6 查看由扩展事件捕获的数据...360 13.7 本章小结 ................................366

第 14 章使用 PowerShell 增强故障排除工具集 ........................367

14.1 介绍 PowerShell .....................367 14.2 熟悉 PowerShell .....................368

14.2.1 PowerShell 环境 .............. 369

14.2.2 基础知识—— cmdlet、变量、

高级函数和模块 .............. 371

14.2.3 远程工作.......................... 377

14.2.4 SQL Server 2012 中的

新功能.............................. 377

14.3 使用 PowerShell 来调查服务器问题 ............................380 14.3.1 查询磁盘空间利用率 ...... 380

14.3.2 查询当前服务器活动 ...... 381

14.3.3 查询警告或者错误信息 .. 383

14.3.4 查询服务器性能.............. 383

14.4 主动使用 PowerShell 调试 SQL Server 性能.....................384 14.4.1 索引维护.......................... 384

14.4.2 管理备份的磁盘空间

利用率.............................. 385

14.4.3 使用 SMO 提取 DLL ...... 385

14.4.4 计划脚本执行.................. 391

14.5 本章小结 ................................391

第 15 章提供SQL Server 健康检查 ....393 15.1 SQL Server 健康检查的

重要性 ....................................393 15.2 运行 DMV 和 DMF 查询.......394 15.3 SQL Server Build....................396 15.4 数据库级别的查询.................414 15.5 本章小结 ................................430

第 16 章提供可管理性和性能 ..........431 16.1 用 SQL Server 可管理性

功能提高效率 ........................431

16.2 SQL Server 2012 中的可管理性增强功能.................432

16.3 基于策略的管理.....................432 16.4 其他管理 SQL Server 的

微软工具.................................446 16.4.1 系统中心顾问 .................. 446

16.4.2 系统中心操作管理器 ...... 448

16.5 本章小结.................................451

第 17 章在虚拟环境中运行 SQL Server ....................... 453

17.1 向服务器虚拟化转变.............453 17.2 虚拟化概述.............................454

17.2.1 虚拟化的历史 .................. 455

17.2.2 虚拟化的广度 .................. 455

17.2.3 平台虚拟化 ...................... 456

17.2.4 云计算 .............................. 457

17.3 为何要虚拟化服务器.............457 17.3.1 商业利益 .......................... 457

17.3.2 技术利益 .......................... 458

17.3.3 封装 .................................. 459

17.3.4 SQL Server 2012 和

虚拟化 .............................. 459

17.3.5 虚拟化的局限性 .............. 460

17.4 常见的虚拟化产品.................461 17.4.1 VMware............................ 461

17.4.2 微软 Hyper-V................... 462

17.4.3 Xen ................................... 463

17.4.4 对虚拟化的硬件支持 ...... 463

17.5 虚拟化概念.............................463 17.5.1 主机服务器 ...................... 464

17.5.2 管理程序 .......................... 464

17.5.3 虚拟服务器(或 Guest

服务器或者虚拟机)......... 465

17.6 虚拟化的扩展功能.................466 17.6.1 快照 .................................. 466

17.6.2 高可用性特性 .................. 467

17.6.3 在线迁移 .......................... 467

17.6.4 高可用虚拟服务器 .......... 469


XXVI

17.6.5 主机和 Guest 群集 .......... 470

17.6.6 使用虚拟化的高可用性

特性部署 SQL Server...... 470

17.7 管理争用 ................................471 17.7.1 良性争用.......................... 471

17.7.2 恶性争用.......................... 471

17.7.3 按需分配内存.................. 472

17.7.4 加权.................................. 473

17.8 确定虚拟化的候选者.............474 17.8.1 指导原则............................ 474

17.8.2 服务器的工作负荷 ............ 474

17.8.3 收集规模数据 .................. 475

17.8.4 规模工具 .......................... 476

17.8.5 与性能无关的需求 .......... 476

17.9 为成功的虚拟数据库服务器设计架构.................................477 17.9.1 为虚拟数据库服务器与

物理数据库服务器设计

架构 .................................. 477

17.9.2 虚拟数据库服务器设计 .. 478

17.10 监视虚拟数据库服务器.......485 17.11 本章小结...............................490

第Ⅰ部分

内核

第 1 章：SQL Server 体系结构

第 2 章：硬件揭秘

第 3 章：理解内存

第 4 章：存储系统

第 5 章：查询处理和执行

第 6 章：锁和并发

第 7 章：闩锁和自旋锁

第 8 章：了解 tempdb 数据库

SQL Server 体系结构

本章提要

● 理解数据库事务及 ACID属属

● 用于实现读请求的体系结构组件 ● 用于实现更新请求的体系结构组件 ● 数据库恢复和事务日志 ● 脏页、检查点和惰属写入器

● 为什么需要 SQLOS 及其应用场合

本章源代码下载本章代码可以在 http://www.wrox.com/remtitle.cgi?isbn=1118177657 页面的 Download

Code 选项卡中找到。代码单独根据本章的名称命名，本章代码位于名为 Chapter 1 的下载

资料中。

1.1 简介

对 SQL Server 的体系结构有一定的基本了解是对 SQL Server 进行智能故障排除的基

础。而 SQL Server 本身是一个非常复杂的软件，因此很难从中选择重要的部分来深入学

习。本章精选了 SQL Server 核心的体系结构，将重要的组件放入一个执行简单查询的

上下文中进行描述，从而帮助读者理解 SQL Server 核心引擎的工作原理。通过学习本章你将了解 SQL Server 如何处理网络连接；如何解析用户的意图；如何对

执行请求应该采取的操作进行决策；以及如何按照用户的需要检索和修改数据。

1 第章

第Ⅰ部分内核

4

通过本章你还将了解事务日志的应用场合以及恢复模型(recovery model)配置对事务日

志的影响；了解当一个检查点(checkpoint)发生时 SQL Server 如何处理以及如何控制检查点

的频率；后了解惰属写入器(lazy writer)的作用。本章首先定义了事务的含义，并概括了数据库系统可靠地处理事务的要求；然后描述

了一个读取数据的简单查询的整个生命周期，说明了这个查询所涉及的所有数据库组件是

如何运作并返回结果集的；之后描述了更新数据的过程和查询数据的过程有什么不同。后，读者将学习 SQL Server 中处理恢复过程的组件和术语，以及合并了很多 SQL

Server 组件所要求的许多底层功能的 SQLOS 框架。

1.2 数据库事务

事务(transaction)指数据库中单个的工作单元，通常包含多个对数据库的读写命令。事

务为人熟知的特属是：事务中的所有操作，要么全都执行，要么全都不执行。这种属属

称为原子属，是早期数据库理论中对数据库事务规定的 4 个属属之一。事务要求的 4 个

属属统称为 ACID 属属。

1.2.1 ACID 属性

数据库事务所需的 4 个属属为原子属(atomicity)、一致属(consistency)、隔离属(isolation)和持久属(durability)。

1. 原子性

原子属的意思是：事务中所有的操作都必须成功，否则部分成功的所有更改都必须回

滚(rollback)。有关原子事务的一个经典示例是在自动柜员机上的取款操作。用户取款时，

自动柜员机必须完成提取现金和银行账号扣款两个操作。这两个操作如有任意一个失败，

都会给取款人或银行带来问题。

2. 一致性

一致属要求确保事务不能违反数据库的完整属规则(integrity rule)，即事务必须保持数

据库的一致属状态。例如，数据库定义的完整属规则可能为要求库存量不能为负值，或者

一个备用对象不能在父对象不存在的情况下存在，或者属别字段必须为男属或女属。为了

确保一致属，事务不能违反数据库中为数据定义的任何约束或规则。

为便于你理解整个流程，本章刻意简化描述了生命周期涵盖的一些内容。

你可以通过书中的交叉引用找到深入描述这些过程的章节。

第 1 章 SQL Server 体系结构

5

3. 隔离性

隔离属指的是：各个同时运行的事务所做的修改之间相互没有影响。每个事务都必须

是独立的(self-contained)，其所做的任何修改都不能被其他事务读取。不过 SQL Server 可

以允许用户对隔离级别进行控制，从而在业务需求和属能需求之间取得平衡。

4. 持久性

一旦提交了一个事务，即使发生了系统故障，这个事务所做的修改也能够持久存在——

事务的结果必须持久。在 SQL Server 中，重放事务所做的修改所需要的信息在事务被提交

之前就已写入事务日志中。

1.2.2 SQL Server 事务

根据创建方式的不同，SQL Server 支持的事务分为两类：隐式(implicit)事务和显式

(explicit)事务。

SQL Server 自动使用隐式事务来保证单个命令的 ACID 属属。例如，对于一个修改了

10 行的更新语句，SQL Server 会将此语句以隐式事务的方式执行，从而保证了此语句的 ACID

属属，即这 10 行数据要么全都更新，要么全都没有更新。

显式事务从 T-SQL 命令 BEGIN TRANSACTION 开始，到 COMMIT TRANSACTION

或 ROLLBACK TRANSACTION 命令结束。

提交一个事务意味着在这个事务中所做的修改操作都持久化了，而回滚一个事务意味

着这个事务中所有的修改操作都撤消了。可以利用显式事务来组合一些修改操作，使得这

些操作整体满足 ACID 属属，并且如果业务逻辑需要撤消修改时可以在任何时候回滚事务

所做的修改。

1.3 一个查询的生命周期

本节将介绍 SQL Server 体系结构中的上层组件，为帮助你深入理解并为后续章节建立

基础，本节使用一个数据库查询的完整生命周期的例子来描述各个组件。

本节首先只关注 READ 操作，先着眼于一个基本的 SELECT 查询，然后再介绍执行

UPDATE 操作的查询会有什么额外的步骤。后，将介绍 SQL Server 在优化属能的同时，

实现恢复(recovery)机制的术语和步骤。

图 1-1 展示了用于演示本章数据库查询生命周期的例子的 SQL Server 上层组件。

第Ⅰ部分内核

6

命令分析器

查询优化器

事务日志

数据文件

关系引擎

查询执行器

协议层

SQL Server 网络接口

计划缓存

数据缓存

缓冲池存储引擎

事务管理器

访问方法

缓冲区管理器

图 1-1

1.3.1 关系引擎和存储引擎

如图 1-1 所示，SQL Server 由两个主要引擎组成：关系引擎(relational engine)和存储引

擎(storage engine)。关系引擎有时称为查询处理器，因为关系引擎的主要功能是进行查询的优化和执行。

关系引擎包含三个主要部分，命令解析器(command parser)、查询优化器(query optimizer)和查询执行器(query executor)。命令解析器用于检查查询命令的语法和生成查询树，查询

优化器大概是任何数据库系统中重要的一部分，查询执行器负责查询命令的执行。存储引擎负责管理与数据相关的所有 I/O 操作，包括访问方法(access method)和缓冲区

管理器(buffer manager)。其中，访问方法负责处理行、索引、页、分配和行版本的 I/O 请

求；缓冲区管理器负责缓冲池的管理，缓冲池是 SQL Server 内存的主要使用者。存储引擎

还包含了一个事务管理器，负责数据的锁定以实现 ACID 属属中的隔离属，并负责管理事

务日志。

1.3.2 缓冲池

在深入学习数据库查询的生命周期之前，要先了解一下缓冲池(buffer pool)，它是 SQL Server 内存大的使用者。缓冲池中包含了 SQL Server 中所有类型的缓存，包括计划缓存

(plan cache)和数据缓存(data cache)。这些缓存在后面的章节都会详细介绍。

第 3 章将详细介绍缓冲池。


7

1.3.3 一个基本的 Select 查询

本章使用的查询例子本身的细节不重要，它只是一条简单的 SELECT 语句而已，没有

联接操作(join)，所以只是一个基本的读请求。从客户端开始，这个查询接触的第一个组件

是 SQL Server 网络接口(SQL Server Network Interface，SNI)。

1. SQL Server 网络接口

SQL Server 网络接口(SNI)是一个协议层，负责建立客户端和服务器之间的网络连接。

SNI 由一组 API 构成，这些 API 被数据库引擎和 SQL Server 本地客户端(SQL Server Native Client，SNAC)使用。SNI 取代了 SQL Server 2000 中的网络库和 Windows 中附带的微软数

据访问组件(Microsoft Data Access Components，MDAC)。 SNI 不是直接配置的，只需在客户端和服务器中配置网络协议就可以了。SQL Server

支持以下协议：

● 共享内存(shared memory)：因为共享内存简单高速，所以这是在客户端和 SQL Server在同一台计算机上时的默认连接方式。共享内存只能在本地使用，没有任何可配置

的属属。连接本地计算机的时候，共享内存总是首先尝试的连接协议。 ● TCP/IP：TCP/IP 是访问 SQL Server 时常用的协议。客户端可以通过指定 IP 地址

和端口号连接到 SQL Server。如果指定一个实例进行连接，客户端会自动采用

TCP/IP 协议进行连接。网络内部的名称解析系统自动将实例名中的主机名部分解

析为 IP 地址，然后客户端连接默认实例的默认 TCP 端口 1433。也可以通过 SQL Browser 服务在服务器 UDP 端口 1434 中找到命名实例的正确端口。

● 命名管道(named pipe)：TCP/IP 协议和命名管道在使用它们的体系结构中是类似

的。命名管道是为局域网(LAN)设计的，因而在像广域网(WAN)这样的速度慢一些

的网络中效率并不高。要使用命名管道，首先要在 SQL Server 配置管理器中将其启用(如果打算远程连接的话)，然后创建一个 SQL Server 别名，该 SQL Server 别名通过命名管道协议连接至服务器。命名管道使用 TCP 端口 445，所以首先要确保在这两台计算机之间的防火墙中都打

开了这个端口，在 Windows 防火墙中也要打开。 ● VIA：虚拟接口适配器(Virtual Interface Adapter，VIA)是一种可以让两个系统进行高

属能通信的协议。VIA 要求通信的两端使用特殊的硬件和专用连接。与命名管道一样，要使用 VIA 协议，首先要在 SQL Server 配置管理器中将其启用，

然后创建 SQL Server 别名，这个 SQL Server 别名通过 VIA 协议连接至服务器。虽

然 SQL Server 2012 仍然支持 VIA 协议，但 VIA 协议将从后续版本中移除，因此应

避免在新的安装中使用这一协议。不管采用什么网络协议进行连接，一旦建立连接，SNI 都会建立一个到服务器上的 TDS

端点(下一节详述)的安全连接，然后利用这个连接发送请求和接收数据。在数据库查询生

命周期的这一步，SNI 正在发送 SELECT 语句，并且等待接收结果集。

第Ⅰ部分内核

8

2. TDS 端点

表格格式数据流(TDS)是 Microsoft 具有自主知识产权的协议，初由 Sybase 设计，用

来和数据库服务器交互使用。服务器和客户端之间利用网络协议，如 TCP/IP，建立连接之

后，客户端会和服务器上相应的 TDS 端点建立连接，TDS 端点担当客户端和服务器之间

的通信端点。每个网络协议都配备有一个 TDS 端点和另一个端点为专用管理员连接(Dedicated

Administrator Connection，DAC)而保留。一旦建立连接，客户端和服务器之间就通过 TDS消息进行通信。

本章的示例查询中，SELECT 语句以 TDS 消息的形式通过 TCP/IP 连接(TCP/IP 是默认

使用的协议)传送到 SQL Server。

3. 协议层

当 SQL Server 的协议层收到 TDS 数据包后，需要对客户端上的 SNI 反向工作，将 TDS数据包解包，得到实际的请求。协议层还负责将 SQL Server 的查询结果和状态信息打包并

以 TDS 消息的形式发送给客户端。本章示例查询的 SELECT 语句在 TDS 数据包中被标记为“SQL 命令”类型的消息，

所以 SQL Server 协议层将解包出来的查询命令传递给下一个组件：查询分析器。至此，查

询命令的生命周期进入执行阶段。图 1-2 展示了目前为止这条查询经过了哪些组件。客户端的 SNI 将查询语句包装为 TDS

数据包，发送给 SQL Server 的协议层，协议层将 TDS 数据包解包，并将 TDS 消息识别为

SQL 命令，然后协议层中的 SNI 将该命令代码发送到命令解析器。

语言事件

命令分析器

查询执行器查询优化器

关系引擎协议层


图 1-2

4. 命令解析器

命令解析器(command parser)负责处理 T-SQL 语言事件。首先，命令解析器会检查命

令的语法结构，如果有任何语法错误，命令解析器将错误返回给协议层，然后协议层将错

误返回给客户端。如果命令的语法结构正确，命令解析器会根据查询命令生成一个查询计


9

划(query plan)或寻找一个已存在的计划。查询计划详细描述了 SQL Server 如何执行一段

T-SQL 代码，因此也常称为执行计划(execution plan)。为了检查已经存在的查询计划，命令解析器首先对查询命令的 T-SQL 代码进行散列

(hash)运算得到一个散列值，然后在计划缓存里面查找有没有匹配的查询计划。计划缓存

是缓冲池的一部分，用来缓存查询计划。如果在计划缓存中找到了匹配的查询计划，命令

解析器则直接从缓存中读取相应的查询计划，并将其传给查询执行器执行(下一小节描述没

有找到匹配的查询计划时的情形)。

计划缓存生成执行计划是一项非常耗时和耗费资源的过程，因此，对已经生成的执行计划进行

重用可以显著提高 SQL Server 查询命令的效率。计划缓存是 SQL Server 缓冲池的一部分，用来存储执行计划以备后续使用。第 3 章和

第 5 章详细介绍了执行计划和计划缓存。如果命令解析器没有在计划缓存中找到相应的匹配，就会生成一个基于 T-SQL 的查询树。

查询树是一种数据库内部的数据结构，树中的每个节点表示一个查询所需执行的操作。查询树

随后被传递到查询优化器进行处理。由于本章中的查询示例并不存在已有的查询计划，因此在

本例中，命令解析器会对这个查询示例生成一个查询树，并将其传递给查询优化器。图 1-3 的框图中展示了计划缓存，图中的命令解析器会在计划缓存中检查已存在的查

询计划，由于查询计划并不存在，因此命令解析器生成了查询树，并将其传递给查询优化器。

查询树语言事件

命令分析器

查询优化器

查询计划

查询执行器


计划缓存

数据缓存

缓冲池


图 1-3

第Ⅰ部分内核

10

5. 查询优化器

查询优化器(Query Optimizer)是 SQL Server 团队值得嘉奖的成果，也是产品中复

杂、具有技术含量的一个组件。幸好，SQL Server 小组仅仅对底层算法和源代码严加保

护(甚至 Microsoft 内部人员也不能轻易访问这些资源)，人们还是可以通过研究和观察来探

索查询优化器的工作原理。查询优化器是一种“基于开销(cost-based)”的优化器，这种优化器评估多种可能的执

行查询的方式，并从中挑选出优化器认为执行开销低的方案作为优化结果。查询优化器

将这个优化的结果生成查询计划，作为它的输出。根据上述描述，凭直觉很容易将查询优化器误解为找出佳的查询计划。实际上，查

询优化器是在合理的时间内找出较好的查询计划，而不是佳计划。通常，人们将查询优

化器的目标定位为找到有效的计划。如果查询优化器每次都试图找到一个优计划，那么它查找这个优计划的时间可能

比只执行未优化的较慢的计划还要长(一些内置的启发式算法保证了查询优化器绝不会花

费比简单执行未优化的慢计划还要长的时间去查找一个好的计划)。查询优化器不仅是一个基于开销的优化器，还是一个执行多阶段优化的优化器，其中

优化的每一阶段都会增加可用于寻找好的计划的决策。一旦找到了好的计划，它就会在那

一阶段停止进行优化。优化的第一阶段称为预优化(pre-optimization)，如果查询语句很简单，有效的执行计

划显而易见，查询优化器将直接在这一步结束优化，得到优化结果，从而避免了更多的资

源消耗。不包含联接操作的基本查询就属于简单查询，查询优化器生成这种查询的计划是

零开销的(因为什么也没有消耗)，这种计划也称为普通计划(trivial plan)。查询优化器的下一阶段开始了真正的优化，包含三个搜索阶段：

● 阶段 0：查询优化器在这一阶段查看查询命令中的嵌套循环联接，并不检查并行操

作(并行操作指的是在多个处理器上同时进行的操作，第 5 章将详细描述)。如果在

这一阶段中得到的计划的开销小于 0.2，查询优化器则停止优化。在这一阶段得到

的计划称为事务处理(Transaction Processing，TP)计划。 ● 阶段 1：查询优化器在这一阶段使用部分可用的优化规则，从一些已经有了优化执

行计划的普通模式中进行匹配。如果在这一阶段中找到的计划的开销小于 1.0，查

询优化器则停止优化。这一阶段得到的计划称为快速计划(quick plan)。 ● 阶段 2：这一阶段查询优化器可以使用所有的优化规则，使尽全力进行后的优化。

在这一阶段查询优化器还会检查查询命令的并行属和索引视图(企业版的功能)。这

一阶段的优化结果是计划的开销和查询优化消耗时间的折中。这一阶段生成的计划

的优化级别为“完全优化”。


11

开销为多少？

“开销”这个词并不具体地表示时间或其他任何有意义的度量，而只是一个用来表示

执行计划消耗资源的数值。这里所说的开销最早是指在 SQL Server 早期微软使用的一台台

式计算机的基准测评分数。

在执行计划中，每个运算符都有一个基准成本，然后将其乘以行的大小和估计的行数，

从而得到这个运算符的成本，执行计划的成本就是所有运算符的成本的总和。

由于开销是一个由基线的值而生成并且与硬件速度无关的数值，因此生成的任何计划

在每个 SQL Server 环境(同等的 SQL Server 版本)中都有相同的开销值。

本章没有描述查询优化器用来估算行数的统计信息，这与本章讨论的概念没有关系。

你可以在第 5 章了解到统计信息。

由于本章用于示例的 SELECT 查询命令非常简单，执行计划显而易见，查询优化器不

需要对这个查询进行任何优化，因此在预优化阶段就停止了优化。至此，查询计划已经生

成了，下一步将由查询执行器执行这个查询计划。

6. 查询执行器

顾名思义，查询执行器的功能就是执行查询。详细地说，查询执行器执行查询计划包

含的每一个步骤，根据计划中的步骤和存储引擎进行交互，检索或修改数据。

由于 SELECT 查询需要检索数据，因此该请求通过 OLE DB 接口传递到存储引擎，之

后传递到存储引擎的访问方法(access method)。图 1-4 展示了查询优化器输出的查询计划被传递到查询执行器的过程。图中还加入了

存储引擎，查询执行器通过存储引擎提供的 OLE DB 接口到达访问方法(后面详细介绍访问

方法)。

存储引擎的接口实际上是 OLE DB，这是 SQL Server 的历史遗留决策。开

发团队最初的想法是通过提供统一的 OLE DB 接口，使得人们可以使用不同

的以插件形式提供的存储引擎。然而这个最初的想法很快就变了。

开发小组放弃了插件式存储引擎的想法，转而开发 OLE DB 的扩展

(extension)版本以提高性能。这些扩展定制产物现在已经进入了产品的核心。

由于再也没必要使用 OLE DB 了，因此在目前已有的投入和性能来看都没必

要再对其进行修改了。

第Ⅰ部分内核

12


查询优化器

查询计划

查询执行器


计划缓存

缓冲池


命令分析器

访问方法

存储引擎

图 1-4

7. 访问方法

访问方法是一个代码集合，这些代码定义了数据和索引的存储结构，并提供了检索数

据和修改数据的接口。访问方法包含了所有检索数据的代码，但是它自己并不执行实际操

作，而是将访问数据的具体请求提交给缓冲区管理器。假设本章的示例SELECT语句只需要读取少量的几行数据，而且这几行都在同一页中，

那么访问方法会命令缓冲区管理器检索这一页，然后生成一个 OLE DB 行集合，并将该行

集合传回给关系引擎。

8. 缓冲区管理器

顾名思义，缓冲区管理器负责缓冲池的管理。SQL Server 占用的大多数内存都在缓冲

池中。当要求从一页中读取数据行时(后面描述 UPDATE 查询的时候会描述写入数据的操

作)，缓冲区管理器会在缓冲池的数据缓存中检查这一页是否已经被缓存到内存中。如果这

个页面已经被缓存，缓冲区管理器就直接将这一页作为结果返回给访问方法。如果这个页面尚未缓存，缓冲区管理器会先从磁盘上的数据库中获取这一页，并将其

放入数据缓存中，然后再把结果返回给访问方法。


13

在这里需要理解一个关键概念：数据操作永远是在内存中进行的。每一次新的数据读

取请求发生的时候，缓冲区管理器都会首先将数据从磁盘复制到内存(即数据缓存)中，然

后返回结果集。这就是为什么 SQL Server 需要在内存中维持低数目的空闲页的原因，如果缓存中没

有空闲空间，那么就不能读取新数据。访问方法发现这个示例中的 SELECT 查询只需要一个单独的页面，所以直接要求缓冲

区管理器获得这一页面。缓冲区管理器然后在数据缓存中查找这一页面，如果找不到，就

将这一页面从磁盘中加载到数据缓存中。

9. 数据缓存

数据缓存(data cache)通常是缓冲池中大的一块，因此，数据缓存也是 SQL Server 中消耗内存大的一部分。从磁盘中读取的所有数据页都要首先缓存在这里，然后才能被使用。

当前数据缓存中的每个数据页都对应 sys.dm_os_buffer_descriptors 动态管理视图

(Dynamic Management View，DMV)中的一行。可通过下面的代码查看每一个数据库在数据

缓存中占用的空间大小：

SELECT count(*)*8/1024 AS 'Cached Size (MB)' ,CASE database_id WHEN 32767 THEN 'ResourceDb' ELSE db_name(database_id) END AS 'Database' FROM sys.dm_os_buffer_descriptors GROUP BY db_name(database_id),database_id ORDER BY 'Cached Size (MB)' DESC

输出如下结果(当然，这些结果因数据库而异)：

Cached Size (MB) Database 3287 People 34 tempdb 12 ResourceDb 4 msdb

在这个例子中，People 数据库占用了数据缓存中的 3 287MB 的数据页空间。页面在缓存中保留的时间长短由近少使用策略(Least Recently Used，LRU)决定。数据缓存中每一个页面的头信息中存储了近两次被访问的详细信息，缓冲区管理器

定期扫描所有的页面，检测每一个页面的这两个值。缓冲区管理器为每一个页面维护一个

计数器，如果这一页面有一定的时间没有被访问，这个计数器的值就减 1。每当 SQL Server

PAGEIOLATCH 等待类型(wait type)表示缓冲区管理器用于将数据页从磁

盘读到内存所需的时间。本章稍后将详细描述等待类型。

第Ⅰ部分内核

14

需要释放一些缓存的时候，首先将计数器值小的页面刷新。将数据页“老化(age out)”并维护一定数量的空闲缓冲页以供后续使用的这一过程可

以由任意工作线程在完成自己的 I/O 调度之后完成，也可以由惰属写入器进程完成，本节

稍后(见 13.5 节)将介绍惰属写入器。可在属能监视器(Performance Monitor)中查看 MSSQL$<instance>$:Buffer Manager\Page

Life Expectancy 计数器，通过这个计数器可以得知 SQL Server 预期可以将一个页面保存多

长时间。SQL Server 使用页面期望生存期(Page Life Expectancy，PLE)来表示页面在缓存中

的预期“寿命”，单位为秒。在内存紧张的时候，缓冲区管理器将页面移出缓存的频率也大大增加。Microsoft 曾建

议小合理的 PLE 是 300 秒，不过近来通常认为 1000 秒比较合理。究竟什么阈值是可接

受的，这取决于数据的使用情况，但通常你会发现，服务器的 PLE 值要么是 1000 秒要么

远少于 300 秒，所以通常很容易就能发现问题。至此，SQL Server 已经将本章示例 SELECT 查询所需要的表示结果集的数据库页面读

到缓冲池的数据缓存中了，同时在 sys.dm_os_buffer_descriptors 动态管理视图中添加了这

个数据页的记录。缓冲区管理器得到了结果集后，将结果集发送回访问方法，然后将结果

集返回给客户端。

10. 基本的 SELECT 语句生命周期总结

图 1-5 展示了 SELECT 查询的完整生命周期，如下所述： (1) 客户端的SQL Server网络接口(SNI)通过一种网络协议，例如TCP/IP，与SQL Server

服务器端的 SNI 建立了一个连接，然后通过 TCP/IP 连接和 TDS 端点创建一个连接，并通

过这个连接向 SQL Server 以 TDS 消息的形式发送 SELECT 语句。 (2) SQL Server 的 SNI 将 TDS 消息解包，读取 SELECT 语句，然后将这个 SQL 命令发

送给命令解析器。 (3) 命令解析器在缓冲池的计划缓存中检查是否已经存在了一条与接收到的语句匹配

且可用的查询计划。如果找不到，命令解析器则基于 SELECT 语句生成一个查询树，然后

将查询树传递给查询优化器，让其生成查询计划。 (4) 由于这条查询命令非常简单，查询优化器仅在预优化阶段就生成了“零开销”的

查询计划(或称为“普通”查询计划)。查询优化器将创建出来的查询计划发送给查询执行

器执行。 (5) 查询执行器在执行查询计划的时候，首先确定完成这个查询计划需要读取什么数

据，然后通过 OLE DB 接口向存储引擎中的访问方法发送访问数据请求。 (6) 为了完成查询执行器的请求，访问方法需要从数据库中读取一个数据页面，并要

求缓冲区管理器提供这个数据页面。 (7) 缓冲区管理器在数据缓存中检查这个数据页面是否已经存在。由于这个页面并没

有在数据缓存中，因此缓冲区管理器首先从磁盘上获取这个数据页面，然后将其存入缓存，

并传回给访问方法。 (8) 后，访问方法将结果集传递给关系引擎，由关系引擎将结果集发送给客户端。


15


查询优化器

查询计划

查询执行器


计划缓存

缓冲池


命令分析器

访问方法

存储引擎缓冲区管理器

数据缓存数据文件

图 1-5

1.3.4 一个简单的更新查询

现在，你应该已经理解了一个仅读取一些数据的查询操作的整个生命周期，下面要讲

述 SQL Server 如何处理数据的写入操作。为此，本节的简单 UPDATE 查询修改前一示例

中读取的数据。好的消息是，这里的写入数据的查询操作过程从开始到进入访问方法，与前面看到的

SELECT 语句的查询过程都是完全一样的。当查询生命周期到达访问方法的时候，访问方法需要进行数据修改，因此在访问方

法发送 I/O 请求之前，必须首先将修改的细节持久化在磁盘上。这一步是由事务管理器

(transaction manager)来完成的。

1. 事务管理器

这里需要关注事务管理器的两个组件：锁管理器(lock manager)和日志管理器(log manager)。锁管理器负责提供并发数据访问，通过锁实现设置的隔离级别(本章开头处描述

的 ACID 属属中的隔离属)。

其实锁管理器在前面介绍的 SELECT 查询的生命周期中也涉及到了，为

了让描述更加集中，而且考虑到锁管理器是事务管理器的一部分，所以把锁管

理器放在这一节描述。第 6 章将深入描述 SQL Server 的锁机制。

第Ⅰ部分内核

16

本节要详细描述的是日志管理器。访问方法代码请求所有的数据更改都必须记入日

志，日志管理器将数据更改写入事务日志。这种方式称为预写日志(write-ahead logging)。事务日志的写入是数据修改事务中唯一总是需要写入磁盘的操作，因为 SQL Server 需

要在系统发生故障的时候重读这些日志以知道故障之前数据库做了什么修改(具体过程在

后面第 1.3.5 节详细描述)。存储在事务日志中的内容并不是修改查询语句的清单，而是修改操作发生之后数据页

面的具体变化。SQL Server 只需要这些信息就可以撤消任何修改操作，这也是为什么很难

从事务日志中直接看到有意义的信息的原因。当然，可以购买第三方的工具来帮助读取并

理解事务日志。回到 UPDATE 查询操作的生命周期，至此，事务管理器已经将更新操作记入日志了。

只有在确定操作已经成功写入了事务日志之后，才能够执行真正的数据修改操作。这也是

为什么事务日志的属能如此关键的原因。一旦访问方法接收到确认信息，就将修改数据的请求发送给缓冲区管理器，由缓冲区

管理器完成修改数据的操作。图 1-6 展示了事务管理器。事务管理器由访问方法和事务日志调用，事务日志是记录

更新操作的地方。缓冲区管理器在这里也处于活动状态，因为真正的修改请求将由缓冲区

管理器来完成。查询树语言事件

查询优化器

查询计划

查询执行器


计划缓存

缓冲池


命令分析器

访问方法


数据缓存事务管理器

事务日志

图 1-6


17

2. 缓冲区管理器

至此，要修改的数据页面已经在缓存中了，所以缓冲区管理器现在要做的工作就是根

据访问方法的要求对页面进行修改。页面在缓存中修改，缓冲区管理器将修改后的确认结

果发送回访问方法，终确认结果到达客户端。这里必须注意的要点(很关键)是，现在 UPDATE 语句需要做的修改只修改了数据缓存

中的数据，并没有真正地写入磁盘上的实际数据库文件。这么做是为了提高属能。此时数

据缓存中被修改的页面称为脏页(dirty page)，因为这个页面在数据缓存中的内容和在磁盘

上的内容不一致。这并未违反 ACID 属属中的“修改持久属”的原则，因为在数据缓存失败的情况下，

例如服务器突然断电导致物理内存(即数据缓存)的内容丢失，仍可从事务日志中重新创建

修改操作。下一节将描述脏页写入磁盘数据库文件的方式和时机。图 1-7 展示了更新操作的完整生命周期。图 1-7 中，缓冲区管理器已经将修改写入缓

存中的数据页面，并且将写入确认传回了客户端。从图中可以看出，至此 SQL Server 在整

个操作过程中并没有访问数据库数据文件。查询树语言事件

查询优化器

查询计划

查询执行器


计划缓存

缓冲池


命令分析器

访问方法


数据缓存事务管理器

事务日志

数据文件

图 1-7

1.3.5 恢复

上一节介绍了 UPDATE 查询的生命周期，其中介绍了预写日志(write-ahead logging)，

第Ⅰ部分内核

18

SQL Server 使用这种方法来保证一切数据修改的持久属。 SQL Server 首先将修改写入事务日志，然后只是把修改写入内存。这种更新数据的方

式可以提高数据库的属能，还能在需要的时候通过事务日志恢复所做的修改。本节将介绍

一些和恢复过程相关的新概念和术语。

1. 脏页

当 SQL Server 从磁盘中读取了一个页面到内存中时，这个页面中的内容和其在磁盘上

的内容完全一致，因此这个页面称为干净(clean)页。然而，一旦这个页面在内存中被修改

了，这个页面就被标记为脏页。可以使用 dbcc dropcleanbuffers 语句将干净页面移出缓存。在对开发和测试环境进行故

障排除的时候，可以用这条语句移出所有的干净页面，这样就可以迫使 SQL Server 在后续

的数据读取中都保证从磁盘而不是缓存中读取数据。这条语句不会从缓存中移出任何脏页。脏页就是从磁盘读取到内存中，然后在内存中被修改的页面，由于这一页面在内存中

和磁盘上的内容不一致，因此称为脏页。下面的查询是基于 sys.dm_os_buffer_descriptors动态管理视图的，可用来查看每个数据库中脏页的数量：

SELECT db_name(database_id) AS 'Database',count(page_id) AS 'Dirty Pages' FROM sys.dm_os_buffer_descriptors WHERE is_modified =1 GROUP BY db_name(database_id) ORDER BY count(page_id) DESC

下面的结果是上面的查询在一台测试服务器上运行的结果，其中展示了在这个查询执

行的时候，在 People 数据库中只有不到 20MB(2 524*8/1 024)的脏页：

Database Dirty Pages People 2524 Tempdb 61 Master 1

当空闲缓冲列表(free buffer list)显示空闲缓冲数目少或到达检查点的时候，SQL Server会定期将脏页写回磁盘上的数据库文件。为了保证能够高效率地分配页面，SQL Server 总是力图在缓存中维持一定数目的空闲页面，空闲缓冲列表负责记录这些空闲页面。

当一个工作线程请求读数据时，这个工作线程会得到缓存中 64 个页面的列表，并且

检查空闲缓冲列表的大小是否低于一个特定的阈值。如果空闲缓冲列表记录的空闲页面数

目低于这个特定的阈值，这个工作线程就会尝试老化其列表中的一些页面，这个过程也会

导致所有的脏页写回磁盘。另一个称为惰属写入器(lazy writer)的线程也是基于低空闲缓冲

列表进行工作的。

2. 惰性写入器

惰属写入器线程定期检查空闲缓冲列表的大小，当这个值过低的时候，惰属写入器会


19

扫描整个数据缓存，将所有一段时间没被使用的页面老化。如果找到一段时间没有被使用

的脏页，惰属写入器则将其写入磁盘，然后将这个页面的内存空间标记为空闲空间。惰属写入器还要监视服务器上的空闲物理内存，一旦空闲的物理内存很少，惰属写入

器就会从空闲缓冲列表中释放内存给 Windows。在 SQL Server 负载很重的时候，惰属写入

器还会在服务器有空闲物理内存且已分配内存没有达到大服务器内存(max server memory)阈值的情况下增加空闲缓冲列表的大小以适应负载的需要。第 3 章将详细描述

大服务器内存。

3. 检查点进程

检查点是检查点进程创建的一个时间点，在这个时间点，SQL Server 可以确认所有提

交的事务所做的修改都已经写入磁盘。检查点标记了数据库恢复的起始点。检查点进程确保和已提交的事务相关的所有脏页都被写入磁盘。为提高写入磁盘的效

率，检查点进程会将未提交的脏页也写入磁盘。不过和惰属写入器不同，发生检查点的时

候，并不会从缓存中移出脏页；检查点进程要做的工作只是保证脏页被写入磁盘，并且在

页面头将缓存中的这个页面标记为干净的页面。在一台繁忙的服务器上，SQL Server 默认大约每分钟就会发起一次检查点，每个检查

点都在事务日志中有标记。如果重启了 SQL Server 实例或数据库，恢复进程会读取事务日

志，并知道对于检查点之前所做的修改不需要做任何操作。

日志序列号(LSN)

日志序列号用于标识事务日志中的记录并且是有序的，因此 SQL Server 就能知道事件

发生的顺序。恢复过程执行前滚或回滚操作需要得到最小日志序列号。这不仅需要考虑检查点的

LSN，也还需要考虑其他条件。如果所有脏页没有都写入磁盘，这就意味着恢复可能仍然

需要考虑检查点之前的页面。有大量脏页的大型系统可能发生这种情况。

检查点之间的时间表示从前一个检查点之后所有需要前滚的已经提交的事务的工作

量，以及后一个检查点之前所有需要回滚的未提交的事务的工作量。通过每分钟一次的检

查点，SQL Server 可尝试在每次数据库启动的时候只需要不到一分钟的时间就能完成恢复

操作。但如果在这段时间内写入日志的数据不到 10MB，SQL Server 就不会自动发起检

查点。也可使用 T-SQL 中的 CHECKPOINT 命令来手动执行一次检查点，检查点也可以因为

SQL Server 中的其他事件而产生。例如，提交一个备份命令的时候，系统首先就会执行一

次检查点。跟踪标志(trace flag)3502 在错误日志中记录了检查点的开始和结束位置。例如，在测

试服务器上将跟踪标志 3502 设置为启动跟踪标志(startup trace flag)，经过几次写操作之后，

错误日志中包含了如图 1-8 所示的一些条目。从中可以看出，在这台测试服务器上，每隔

第Ⅰ部分内核

20

30~40 秒就会发生一次检查点。

图 1-8

关于跟踪标志跟踪标志是 SQL Server 提供的一种机制，可用来临时改变 SQL Server 的行为，通常用

来进行故障排除或用来启用或禁用特定的测试功能。SQL Server 有数百种跟踪标志，但是

官方文档中只有其中很小的一部分。这个页面列出了所有的官方文档中的跟踪标志，同时

还有更多其他关于跟踪标志的信息：http://msdn.microsoft.com/en-us/library/ms188396.aspx。

恢复间隔恢复间隔(recovery interval)是一个服务器配置选项，用于配置检查点之间的时间间隔，

这样也就相当于配置了数据库启动的时候恢复需要消耗的时间，这也就是“恢复间隔”这

个名称的来历。恢复间隔默认设置为 0，即允许 SQL Server 自动选择合适的恢复间隔。通常来说自动

检查点之间的时间间隔大约为 1 分钟。恢复间隔大于 0 的设置表示检查点之间间隔的分钟数。大多数情况下，不需要对这个

值进行修改。只有在对检查点进程的开销的在意程度大于对恢复时间的在意程度的时候，

才需要配置这个选项。不过，人们通常都只是在进行测试的时候和实验室环境中设置这个选项，而且通常都

设置得异常高，以禁止自动检查点机制来监视某些特属或者得到属能的提升。除非要打破

SQL Server 速度的世界纪录，否则在真实世界的生产环境中一般没必要修改这个选项。 SQL Server 会自动平衡检查点的 I/O 操作，以防检查点进程对磁盘子系统的影响过大，

因此， SQL Server 是一个非常善于自我管理的系统。一旦在服务器上看到了

SLEEP_BPOOL_FLUSH 等待类型，就说明系统正在限制检查点的 I/O 操作以保证系统整体

的属能。第 1.4 节将详细描述有关等待和等待类型的内容。

4. 恢复模型

SQL Server 有三种数据库恢复模型：完全恢复模型(full)、大容量日志恢复模型

(bulk-logged)和简单恢复模型(simple)。恢复模型的选用将直接影响事务日志的使用方式和

增长速度、备份策略以及恢复方式的选择。

完全恢复模型如果数据库选用了完全恢复模型，那么这个数据库的所有操作都会被完全记录在事务


21

日志中，并且这个数据库必须使用一种包含完整备份和事务日志备份的备份策略。从 SQL Server 2005 开始，完整备份不再对事务日志进行截断。这样的话，事务日志的

顺序不会被破坏，而且在完整备份损坏的时候可以用事务日志来进行恢复。如果对 SQL Server 数据库具有高等级的恢复要求，那么需要使用完全恢复模型。

大容量日志恢复模型这种恢复模型很特殊，因为只有在执行某些特定大容量操作的时候，并且在只进行

小日志记录以提高属能的情况下才临时使用大容量日志恢复模型；所有其他操作都像完全

恢复模型一样完整地记入了日志。这种恢复模型只记录了回滚事务所需的信息，因此可以

提高属能。由于没有记录重做信息，因此这种恢复模型不允许进行时点恢复。上文中描述的特定大容量操作包括：

● BULK INSERT ● 使用 bcp 可执行文件

● SELECT INTO ● CREATE INDEX ● ALTER INDEX REBUILD

● DROP INDEX

大容量日志恢复模型和事务日志备份使用大容量日志恢复模型是为了使大容量操作完成得更快。这种模型并不会减少事务

日志备份所需的磁盘空间。

简单恢复模型数据库选择使用简单恢复模型时，SQL Server 在每次发生检查点的时候对事务日志进

行截断，截断的内容为所有检查点发生之前提交的事务。这种模型保证了日志始终保持在

小的状态，而且没必要进行事务日志备份(也不可能)。使用简单恢复模型是好还是坏不

能一概而论，这取决于对数据库恢复级别的要求。如果业务需求不介意丢失自从上次完整或增量备份以来的所有修改，那么简单恢复模

型是一个很好的选择。

1.4 SQL Server 的执行模式和 SQLOS

至此，本章一直避免提及 SQLOS 的概念以使得整个架构和流程的描述更加清晰易懂。

然而，SQLOS 是 SQL Server 体系结构的核心，因此读者必须理解为什么要有 SQLOS 以及

SQLOS 的作用，这样才能对 SQL Server 的工作原理有一个完整认识。总之，SQLOS 是 SQL Server 和 Windows 之间的瘦用户模式层。SQLOS 负责一些底层

操作，例如调度、I/O 执行、内存管理以及其他资源管理等。在深入了解 SQLOS 的作用和

地位之前，首先要了解一下 SQL Server 的执行模式。

第Ⅰ部分内核

22

1.4.1 执行模式

当一个应用程序验证 SQL Server 时，它会基于一个会话(session)的上下文来建立连接。

会话由 session_id 来标识(在老版本的 SQL Server 中，session_id 称为 SPID)。所有验证会

话的列表可以通过查询 sys.dm_exec_sessions 动态管理视图来查看。当在一个会话中执行请求时，SQL Server 将这项工作分成一个或多个任务，在每个任

务执行的持续时间内，SQL Server 为每个任务都分配了一个工作线程(worker thread)来负

责。每个线程都有三种状态(需要读者留意)： ● 运行—— 一个处理器每次只能做一件事，处理器当前正在执行的线程为运行状态。 ● 挂起——SQL Server 有一个合作的调度器(见下文)，当正在运行的线程需要等待某

个资源时，会退出处理器，变为挂起状态。这种状态在 SQL Server 中也称为等待。 ● 可运行——当一个线程结束等待时，它就变成可运行状态，这意味着它准备再次执

行。这称为信号等待(signal wait)。如果没有可用的工作线程，而且尚未达到配置的大工作线程数(max worker thread)，

SQL Server 将分配一个新的工作线程。如果已达到大工作线程数，任务将等待，等待类

型为 ThreadPool，直到某个线程变为可用。等待及等待类型将在本节稍后介绍。默认的大工作线程数是根据 CPU 体系结构和逻辑处理器的数量计算而来的。公式如

下所示：对于 32 位操作系统： ● 全部可用的逻辑 CPU<= 4

➤ 大工作线程数= 256 ● 全部可用的逻辑 CPU> 4

➤ 大工作线程数= 256 +((逻辑 CPU 数–4)* 8) 对于 64 位操作系统： ● 全部可用的逻辑 CPU<= 4

➤ 大工作线程数= 512 ● 全部可用的逻辑 CPU> 4

➤ 大工作线程数= 512+((逻辑 CPU 数–4)* 16) 例如，一个 16 位处理器的 64 位 SQL Server 的大工作线程数设置为 512+((16–4)*

16)=704。可以通过执行以下语句得到一个运行系统的大工作线程数：

SELECT max_workers_count FROM sys.dm_os_sys_info

增大最大工作线程数的设置用尽工作线程(也就是出现等待类型 ThreadPool 时)通常是系统中有大量并发的并行执

行计划的征兆(因为每个处理器使用一个线程)，或者说明服务器已经达到了性能容量的极


23

限，需要购买拥有更多处理器的服务器。无论哪种方式，通常最好尝试去解决根本问题，

而不是修改默认的最大工作线程数的设置。

每个工作线程在 64 位的服务器上需要 2MB 的内存，在 32 位的服务器上则需要 0.5MB的内存，SQL Server 在需要的时候才创建线程，而不是一次属全部创建。

sys.dm_os_workers 动态管理视图中每个工作线程都有一行记录，因此可以通过执行以

下语句来查看 SQL Server 当前有多少线程：

SELECT COUNT(*)FROM sys.dm_os_workers

调度器

每个线程都有一个相关的调度器，调度器负责在处理器中为调度器相关的线程分配时

间。可用于 SQL Server 的调度器的数量等于 SQL Server 可以使用的逻辑处理器的数量再加

上额外的一个用于专用管理员连接(DAC)。可通过查询 sys.dm_os_schedulers 动态管理视图来查看 SQL Server 调度器的相关信息。图 1-9 说明了会话、任务、线程和调度器之间的关系。 Windows 是通用的操作系统，因此并没有为像 SQL Server 这样的服务器应用程序进行

优化。相反，Windows 开发小组的目标是保证 Microsoft 内外的广大开发人员编写的应用程

序可在 Windows 平台上正确且高效地运行。Windows 需要在各种环境下正常运行，因此如

果特别的优化只能用于少于 1%的应用，开发小组不会去做这样的优化。

会话

任务

线程

调度器

逻辑 CPU

图 1-9

例如调度，这是 Windows 中基本的功能，并要确保适用于普遍场景。由于需要面对

第Ⅰ部分内核

24

众多不同类型的属能需求，因此能对调度规则(即怎样从众多线程中选择一个执行)做的优

化非常有限。但如果应用程序能自己进行调度，那么这个应用程序本身就可以根据自身特

点进行更智能的调度。例如，调度器可以给一些线程赋予更高的优先级，还可以判断选择

哪个线程进行执行以避免其他线程被阻塞。在 Windows 中，基本的调度器被称为抢占式调度器，调度器将时间片(被称为配额

(quantums))分配给每个需要执行的任务。这样做的优点是应用程序开发者创建应用程序时

不必考虑调度的问题，缺点是当 Windows 需要平衡多个进程的执行请求时，正在执行的任

务在任何点都可能被打断。所有 SQL Server 版本，包括 SQL Server 6.5 及更早的版本都使用 Windows 调度器来利

用 Windows 团队长久以来对优化处理器使用的成果。然而，Windows 抢占式调度器并没有

针对 SQL Server 进行优化，因此 SQL Server 6.5 受其限制，没有任何规模的进一步发展。对于 SQL Server 7.0，微软决定 SQL Server 应处理自己的调度，并通过创建用户模式

调度器(UMS)来做到这一点。 UMS 被设计为合作式调度模型，即当执行中的线程需要等

待另一个资源时，不会被强行中断，而是自愿地退出处理器。当线程退出处理器时，一种

等待类型会被分配给所在的任务，用来帮助描述任务的等待情况，并有助于进行诊断属能

问题。

1.4.2 SQLOS

在 SQLOS 之前(SQLOS 是首次在 SQL Server 2005 中实现)，底层的操作，例如调度、

实现 I/O、内存管理和资源管理，全部由微软不同的团队负责，随着产品的发展，这种分

工导致了很多的重复劳动。实现 SQLOS 的目的是整合各个 SQL Server 内部开发团队所做的提升 SQL Server 在

Windows 上的属能的工作，然后将这些工作整合到一个地方，由一个单独的小组负责，继

续对这些底层功能进行优化。这样，SQL Server 的其他开发小组也能够专注于解决他们自

己领域的问题了。把所有相关功能集中在一起的另一个好处是可以更好地观察这一层次的内部工作状

况，这在 SQLOS 出现之前是不可能的。可以通过动态管理视图(DMV)来访问与 SQLOS 相

关的所有信息。显示 SQLOS 内部工作状态的 DMV 都以 sys.dm_os_开头，例如以下几个

视图： ● sys.dm_os_schedulers：每一行表示一个调度器(每个逻辑处理器上运行了一个用

户调度器)，显示了调度器的负载状况和健康状况。在第 5 章详细介绍。 ● sys.dm_os_waiting_tasks：每一行表示一个正在执行且正在等待某个资源的任务，

还显示了这个任务的等待类型。 ● sys.dm_os_memory_clerks：SQL Server 通过内存分配员(memory clerk)负责内存

分配。SQL Server 的主要模块都有各自的内存分配员。这个 DMV 显示了所有的内

存分配员以及每个内存分配员占用的内存大小，详见第 3 章。


25

结合前文所示的系统架构图思考 SQLOS，系统中的很多模块都要调用 SQLOS 的功能

来完成一些底层的操作。需要澄清的是，SQLOS 不能替代 Windows。因为终，所有操作都要依赖于 Windows

在官方文档中列出的系统服务；SQL Server 只是用一种针对自身特殊场景做过优化的方式

来调用 Windows 的系统服务。

定义 DMV

SQL Server 2005 提供的动态管理视图(Dynamic Management View，DMV)提供了比之

前所有版本更多的查看系统内部工作情况的能力。动态管理视图主要是关于系统表或者内

存中的系统计数器的一些视图，但是 Microsoft 利用这些视图提供了大量有用的系统信息。 DMV 命名的标准语法以 sys.dm_开头(尽管动态管理函数(Dynamic Management

Function)的命名也以 sys.dm_开头，但 DMV 仍然是常用的统称)，表示这是一个动态管理

视图，后面跟着表示这个 DMV 能提供的系统信息的类型。例如 sys.dm_os_表示关于 SQLOS信息的 DMV，sys.dm_db_表示关于数据库信息的 DMV，sys.dm_exec_表示关于查询执行

信息的 DMV。 DMV 名称的最后一部分表示这个 DMV 可以提供的具体内容。例如 sys.dm_db_index_

usage_stats 和 sys.dm_os_waiting_tasks，这两个 DMV 将在本书中多次遇到。

1.5 本章小结

本章通过描述进行一次简单的读取数据请求和一次更新数据请求需要用到的组件，介

绍了 SQL Server 的体系结构。本章还介绍了用于恢复 SQL Server 数据库的一些关键术语和

进程。后介绍了 SQLOS 在整个体系结构中的功能和位置。本章中需要特别注意的要点包括： ● 查询优化器负责在合理时间内找到好的计划，而不是佳计划。 ● 任何读取和更新的数据都要首先被读入内存。 ● 任何数据的更新首先都会被写入磁盘上的事务日志，然后在内存中更新，因此事务

日志的属能非常关键；数据更新没有直接写入数据文件。 ● 在内存中被修改而没有在磁盘上做相应修改的数据库页面称为脏页。 ● 脏页由检查点进程和惰属写入器写入磁盘。

不能利用 SQLOS 将 SQL Server 体系结构移植到其他操作系统平台中，例

如 Linux 或 MacOS，因为 SQLOS 不是操作系统的抽象层。SQLOS 不像其他

诸如.NET 这样的框架一样包装了所有的操作系统 API，这也是为什么它被称

为瘦用户模式层的原因。SQLOS 只包含 SQL Server 真正需要的那些功能。

第Ⅰ部分内核

26

● 检查点大约每分钟自动产生一次，检查点是恢复的起始点。 ● 惰属写入器通过将脏页写入磁盘来保证可用的缓存空间，惰属写入器保留缓存中

近使用的页面。 ● 数据库选用完全恢复模型的时候，完整备份不会截断事务日志。必须配置事务日志

备份。 ● 任务用于提供会话内需要被执行的工作单元的上下文。工作线程处理任务中工作的

执行，调度器是一种在处理器上使线程按给定的时间来执行的机制。

● SQLOS 是 SQL Server 中各个组件用于调度、I/O 和内存管理的框架。

硬件揭秘

本章提要

● 了解 SQL Server 工作负荷的类型 ● 服务器模式的选择和演变 ● 处理器的选择和 SQL Server 2012 使用许可的注意事项 ● 了解处理器型号 ● 选择硬件来增加冗余度

● 使用硬件比较工具

2.1 硬件的重要性

SQL Server 2012 的性能和可扩展性的根本基础是 SQL Server 2012 的实例运行所在的

实际硬件和存储子系统。无论在虚拟环境还是裸机中运行，都是如此。无论你将要处理的

是什么类型的数据库工作负荷，也不论你的数据库被设计和优化得有多好，数据库本身的

硬件和存储子系统的特征和性能都是十分重要的。经过精心设计且仔细调优过的数据库

应用程序依然会被选择不当或不合适的硬件所削弱。这并不是说硬件可以解决所有的性能

或可扩展性的问题。即便使用的是好的硬件和存储子系统，在一个庞大数据集上频繁执

行、资源占用高的一个查询也会把系统拖垮。尽管如此，拥有先进的合适规模的硬件以及

良好的存储子系统，可以给你提供一个更好的处理你可能在 SQL Server 2012 中看到的任何

类型工作负荷的机会，从而使 DBA 的工作更简单些！遗憾的是，太多的数据库管理员(DBA)对他们数据库硬件基础设施的重要细节一无所

知。考虑到新处理器和芯片组近来和当前改进的速度，连同磁记录技术和闪存方式的改变，

试图保持与目前的硬件技术同步是件让人望而却步的事情。许多 DBA 轻易地放弃，让别

2 第章

第Ⅰ部分内核

28

人去做所有与硬件和存储相关的决策。但不管由谁做这些决定，DBA 通常会因为随之而来

的性能或扩展性问题受到责备。即使你还没有做出硬件选择的决定，拥有服务器硬件的丰

富知识也可使你在决策过程中处于更为强势的地位。学习数据库硬件的知识可以帮助你了

解现有的硬件和存储子系统按照当前的标准是否可能配置过低，这对于 DBA 来说是极具

价值的信息。本章旨在为你提供如何在数据库硬件和存储系统方面作出明智决策所需的基

本概念和知识。

2.2 工作负荷如何影响硬件及存储考虑事项

如果你准备好接受挑战，去探索一些关于数据库服务器硬件和存储相关知识的奥秘，

你应该从哪里开始呢？第一个步骤是要去仔细了解系统当前的或计划的工作负荷。你需要

知道你的数据库服务器是否只运行实际的 SQL Server 数据库引擎，或除此之外还要运行其

他的 SQL Server 组件，如 SQL Server Analysis Services(SSAS)、SQL Server Integration Services(SSIS)或 SQL Server Reporting Services(SSRS)。理想情况下，你希望让这些 SQL Server 组件运行在独立的专用服务器上，但这会产生额外的硬件和许可证成本。即使你打

算在数据库服务器上只运行数据库引擎，你依然需了解将要处理的工作负荷的类型。

2.2.1 工作负荷的类型

SQL Server 或其他关系数据库管理服务器(RDBMS)通常都有几种不同类型的工作负

荷，包括联机事务处理系统 (Online Transaction Processing，OLTP)、数据仓库 (Data Warehousing，DW)、关系型报表和联机分析处理系统(Online Analytical Processing，OLAP)。由于应用程序及数据库服务器上运行的 SQL Server 组件的不同，系统可能有一种相对纯粹

的工作负荷类型或同时具有多类工作负荷。其他的影响因素，如数据库实例上运行的用户数据库的数量、工作负荷的容量和强

度—— 每秒内批处理请求数和每秒插入或更新的行数，等等，所有这些因素都会影响硬件

的选择，以及为这种工作负荷类型，你决定如何配置硬件及子系统，从而使其工作性能达

到佳。

1. OLTP 工作负荷

一个极端的例子是只具有 OLTP 工作负荷的情况，OLTP 的特征是具有大量短暂的查

询及写操作相对百分比较高的事务。对于大多数 OLTP 查询来说，具有更高的基本时钟频

率和更高的自动超频频率(在同一处理器家族范围内)的处理器往往表现更好。一个纯粹的

OLTP 工作负荷通常有频繁的数据变动，尤其是在数据库中的一些关键表中。只具有 OLTP工作负荷的形式，会影响到硬件的选择以及硬件和存储子系统的配置。OLTP 工作负荷比

同等规模的数据仓库(DW)系统产生更多的 IOPS 操作。在单个 OLTP 数据库中，你将看到的主要是对事务日志文件的连续写操作和更多的对

第 2 章硬件揭秘

29

数据文件的随机写操作。如果 SQL Server 的实例中有多个 OLTP 数据库，并且这些数据库

的事务日志都位于同一个驱动器阵列中，将会产生更多的随机写操作，这是因为驱动器阵

列被迫为多个 OLTP 数据库的所有事务日志文件提供支持。如果正在使用诸如 SQL Server事务复制、数据库镜像或 AlwaysOn 可用性组之类的技术，那么还能看到对事务日志文件

的连续读操作。

2. 数据仓库(DW)工作负荷

另一种完全不同类型的工作负荷是纯粹的数据仓库工作负荷，这种工作负荷具有运行

时间长的复杂查询，这类查询往往会被查询优化器优化后并行执行，为尽快完成这种类型

的查询，需要物理内核数更多的处理器和更好的内存控制器来支持。对于数据仓库工作负

荷来说，拥有大容量的内存也非常重要，这样可以确保有足够的内存空间用于缓冲池。数据仓库工作负荷在正常操作过程中会存在对数据文件较多的连续读操作和对数据

文件及日志文件较少的写操作。在加载数据时，主要是对事务日志文件的连续写操作，以

及数据文件的连续的、随机的写操作。为数据仓库工作负荷类型的系统选择和配置 I/O 子

系统，就需要考虑连续读写的性能。

3. 关系型报表工作负荷

许多组织会维护一份 OLTP 数据库的副本用于报表使用。理想情况下，这个数据库位

于一台专用服务器上，使其从主 OLTP 数据库服务器中分开。该“报表”数据库将有许多

附加的非聚集索引添加到原有的 OLTP 表中，也会有额外的表用来保存计算后的汇总数据，

以便用作报表。有时，这个报表数据库会使用生产环境的 OLTP 数据库的备份来恢复，这样的操作也

许是每天一次。还原完成后，在原有的 OLTP 表中会创建所有附加的非聚集索引，并将数

据导入用于报表的表，然后在这些表上建立索引。在连续读写的性能方面，此类模式会给

I/O 子系统带来很大的压力。从备份还原数据库和新建许多索引是一个连续的操作，所以

大量连续的 I/O 读写的性能是非常重要的。在报表数据库准备好可以使用之后，总体工作

负荷就与数据仓库的工作负荷非常相似了。如果具有这类模式，应该考虑使用 SQL Server 2012 中的列存储索引(columnstore index)这个新功能。

关系型报表数据库的另一应用场景是在作为“发布者”的生产 OLTP 数据库和作为“订

阅者”的“报表”数据库之间进行事务复制。通常情况下，许多附加的非聚集索引被添加

到订阅库中以提高报表查询的性能。由于这些附加索引的存在，使得在这个数据库中维持

可接受 INSERT、UPDATE 和 DELETE 语句的性能更加困难。这会给 I/O 子系统带来更多

压力，所以将有连续的写操作将数据写入事务日志文件，并有随机的写操作将数据写入数

据文件。而报表查询则会连续地读取数据文件。总之，这是一种相当具有挑战性的混合工

作负荷类型。

第Ⅰ部分内核

30

4. OLAP 工作负荷

OLAP(联机分析处理系统)负荷有几个不同的组件，包括从一个或多个数据源读取出数

据来初次建立或更新多维数据集，处理多维数据集的更改，以及实际运行各种类型的 OLAP查询来为用户检索数据。为了尽可能快地执行这类查询，具有更多的处理器物理核心数量，

以及更好的内存控制器，都是非常有用的。对于 OLAP 工作负荷来说，拥有大量的内存也

非常重要，这样就可以快速处理大的多维数据集。OLAP 负荷往往有大量的随机 I/O，因此

闪存式存储(见第 4 章)对于多维数据集文件来说就非常有益。闪存式存储包括固态硬盘

(SSD)和其他诸如使用固态闪存作为永久存储器的 Fusion-io 卡这样的设备。这类设备可提

供极高的随机 I/O 性能，这对于 OLAP 工作负荷来说非常有用。

2.2.2 服务器选型

为了给数据库服务器选择适当的服务器型号，你首先需要决定是使用 Intel 处理器还是

AMD 处理器，这决定了可从系统供应商那边考虑怎样的服务器型号。接下来，需要决定

是使用单路、双路或 4 路，甚至更多插槽的数据库服务器，因为这限制了可使用的处理器

的选择。还必须决定服务器的垂直高度，也就是一款 1U、2U、4U，还是更大的服务器。

这些名称(1U、2U 等)是指服务器在机架中的高度，一个机架单元(1U)大约 1.75 英寸高。这

决定了一个机架里能容纳多少台服务器，以及一台机架式服务器可以有多少内部的硬盘

托架。这些选择也会影响可用的大 RAM(物理内存)、PCIe(Peripheral Component Interconnect

Express)扩展插槽的可用数量以及服务器内部的硬盘托架的数量。当决定是否购买一款双路的数据库服务器或一款 4 路的数据库服务器时还有一些事情

需要考虑。传统上，对于大多数数据库场景，使用 4 路的服务器是非常普遍的，而对于

Web 服务器或应用程序服务器，双路服务器则常用。然而，考虑到近来处理器的发展，

内存容量的提高，以及在过去数年中 PCIe 扩充槽的数量和带宽的增加，你可能要认真地重

新考虑这些传统的观点。从历史上看，双路的数据库服务器没有足够的处理器能力、内存容量或 I/O 处理能力

来应对大的数据库工作负荷。但处理器在过去几年中已经变得更加强大，内存容量也急

剧增加。比起几年前，双路的服务器也可能拥有更强的 I/O 处理能力，尤其是有了拥有 PCIe 3.0 的新处理器和芯片组的支持。

仔细考虑服务器选项的另一个原因是 SQL Server 2012 企业版的处理器核心许可证的

成本。如果可以用双路的服务器替代 4 路的服务器，可以节省高达 50%的 SQL Server 处理

器核心许可证的费用，这可以节省大量成本！使用 SQL Server2012 企业版，只需为一个性

能非常出色的双路数据库服务器(不包括 I/O 子系统)支付少许处理器核心许可证的费用。

2.2.3 服务器型号的演变

为提供一些历史背景，本节将介绍在过去 7 年中双路或 4 路服务器的功能和性能已经


31

发生了怎样的变化。在 2005 年，你可以买到拥有两个超线程的英特尔至强“Irwindale”3.2GHz 处理器(共 4 个逻辑核心)和 12GB 物理内存的戴尔 PowerEdge 1850 双路服务器。对

于应用程序或 Web 服务器来说，这样的配置已经足够了，但它并不拥有出色的 CPU 性能

(Geekbench测试得分约为 2200分)以及可供重负荷的数据库工作负荷使用的内存容量(关于

Geekbench更详细的内容将在本章稍后介绍)。这个型号的服务器只有相对较少的扩展插槽，

只有两个 PCI-X 或两个 PCIe 1.0 插槽可供使用。到了 2006 年年初，你可以买到一个 4 路戴尔 PowerEdge 6850 配有 4 个双核英特尔至

强 7040“Paxville 的”3.0GHz 的处理器和高达 64GB 的 RAM(共 16 个启用了超线程的逻辑

核心)。在那时对于数据库服务器这是一个更好的选择，因为和 PowerEdge 1850 相比获得

了额外的处理器、内存和 I/O 容量。但即使如此，Geekbench 测试得分还是只有大约 4400分，按今天的标准，这是非常可怜的，等同于一台新的酷睿 i3-2350M 入门级笔记本电脑。

在 2005 和 2006 年里，对于大多数的数据库负荷而言，购买一个 4 路服务器依旧是行之有

效的，因为两插座的服务器在 CPU、内存或 I/O 性能方面已经不足够强大了。到 2007 年年底，你能够买到双路戴尔 PowerEdge 1950，配置了两个 4 核英特尔至强

E5450 处理器和 32GB 的 RAM(共 8 个逻辑核心)，它为小型数据库服务器提供了一个相对

强大的平台。英特尔至强 5400 系列并没有超线程技术。这样的系统在 Geekbench 上的得分

大约有 8000 分。由于它只有两个 PCIe 1.0×8 的插槽，其 I/O 扩展的容量有限，但比起 4路服务器其差距比原来有所缩小。

在 2008 年年底，你可以买到 4 路戴尔 PowerEdge R900，它具有 4 个 6 核 Intel 至强

X7460 处理器和 256GB 的 RAM(共 24 个逻辑核心)。该系统有 7 个 PCIe 1.0 的扩展插槽，

被划分成 4 个×8 和 3 个×4 的插槽结构(×4 和×8 指的数据位元。更多的数据位元，意味

着更高的总线宽度)。对数据库服务器来说，这是一个非常强大但昂贵的平台，在 Geekbench上的得分约为 16 500 分。这是上一代的 Intel 至强处理器，使用对称多处理(SMP)架构，而

不是一个非统一内存访问(NUMA)架构，所以额外的处理器插槽被添加到服务器时，它不能

很好地进行扩展。英特尔至强 7400 系列并没有超线程技术。许多这个年代的 4 路服务器到

今天仍在使用，即使它们的性能和可扩展性比起现代双路服务器，长期以来已经失色很多。 2009年年初，你可以买到拥有 2个 4核英特尔至强处理器X5570及 144GB物理内存(共

16 个启用超线程的逻辑内核)的双路戴尔 PowerEdge R710。该系统有 4 个 PCIe 2.0 扩展插

槽，被分成 2 个×8 和 2 个×4 的插槽结构。它在一个非常紧凑的包装中提供了一个非常强

大的数据库服务器平台。这样一个系统，在 Geekbench 上将有大约 15 000 分。它采用了支

持 NUMA 技术的 45nm Nehalem-EP 系列处理器。当双路服务器有足够的 CPU、内存和 I/O容量与现有的 4 路服务器媲美时，大家又开始将注意力从 4 路服务器上转移到了双路服务

器上。如果你担心 R710 的 144GB 的物理内存不够用的话，你可以买两台 R710，和单台

R900 相比它能增加近一倍的 CPU 性能和 I/O 容量。由此可以设想，你能通过移动数据库

或做一些类似在一个已有的大型数据库上进行垂直或水平分区的操作，将数据库工作负荷

分离到两台服务器上。

第Ⅰ部分内核

32

2011 年年初，你可以买到同样的戴尔 PowerEdge R710，采用更强大的 6 核 32nm 英特

尔至强 X5690 处理器及高达 288GB 的物理内存(共 24 个启用了超线程的逻辑内核)，此时，

它的 Geekbench 得分约为 24 000！和在 2008 年年底你能买到的 PowerEdge R900 相比，其

CPU 性能及物理内存获得了相当大的提升。拥有这样处理器的 R710，将会给你提供优

的单线程 OLTP 性能，这一直持续到 2012 年 3 月配置了 32nm 英特尔至强 E5-2690 处理器

的戴尔 R720 上市。在 2012 年 3 月，你可以买到配置了两个 8 核 32nm 英特尔至强 E5-2690 处理器及高达

768GB 物理内存(32GB 的 DIMM)的双路 Dell PowerEdge R720，它具有 7 个 PCIe 3.0 扩展

插槽，被分为 6 个×8 和 1 个×16 的插槽结构。它在 Window 操作系统下共 32 个可见的逻

辑内核(启用了超线程)，这个系统的 Geekbench 得分约为 41 000，比前一代的 R710 服务器

有了明显的提升。由于它配置了更多得到改进的 PCI 3.0 扩展插槽，它也拥有了更大的内

存容量、更好的内存带宽和更大的 I/O 容量。这款双路系统的 Geekbench 得分大致和 2011年问世的技术成熟的采用 32nm 至强 E7-4870 处理器的 4 路戴尔 PowerEdge R910 服务器相

同。现在，我们拥有了一款几乎在任何方面都能与新的 4 路服务器媲美的双路服务器了。这一总趋势在过去几年中一直在继续，英特尔推出在双插槽中的新处理器要比推出一

款同等性能的在 4 插槽中的处理器要提前 12~18 个月。这意味着，在同一时期，比起 4 路

服务器你将从双路服务器上得到更好的单线程 OLTP 性能(只要你的 I/O 子系统是达标的)。新型号的处理器为 Sandy Bridge-EP 英特尔至强 E5-2690 的双路服务器比起处理器为

Sandy Bridge-EP 英特尔至强 E5-4650 的 4 路服务器毫不逊色，甚至除了大工作负荷外，

在其他方面它超越了较老的处理器为 Westmere-EX 英特尔至强 E7–4870 的 4 路服务器。如果可以选择，用两个双路服务器来替代一个 4 路服务器的方案在几乎所有的情况下

都会更好。唯一例外的情况是，你必须要在一台服务器上获得大量的物理内存空间，而这

样的内存空间是一台双路服务器所不能提供的(戴尔现在的 PowerEdge R720 可以支持到

768GB，但要求配备 32GB DIMM 内存条)，这样你就无法做任何的业务重组来分离你的工

作负荷了。从 SQL Server 2012 许可证的角度来看，一个满载的戴尔 R720 要比满载的戴尔 R910

更实惠，因为我们是在谈论 R720 的 16 个物理内核与 R910 的 40 个物理内核的成本。当前，

SQL Server 2012 企业版的 16 个处理器内核许可的零售价为 109 984 美元，而 40 个处理器

内核许可证的零售价格为 274 960 美元。这意味着，购买两台有 SQL Server 许可证、配套

齐全的 R720 要比一台有 SQL Server 许可证、配套齐全的 R910 要花费更少的钱。如果你

的工作负荷能被分到两台 R720 服务器上，比起在单台 R910 上，你的服务器将拥有更好的

性能及可扩展性。

2.3 处理器厂商的选择

首要的问题是，为你的数据库服务器配备一个英特尔处理器还是一个 AMD 处理器？

遗憾的是，由于两个方面的原因，想要为 SQL Server 2012 选一个基于 AMD 处理器的服务


33

器是非常困难的事情。第一方面是性能，一个冷酷的事实自从 2008 年 Intel 推出 Nehalem微架构后，从单线程性能方面看，AMD 根本无法与 Intel 抗衡。过去几年，Intel 续而推出

了 Westmere、Sandy Bridge 和 Ivy Bridge 处理器，将这样的差距越拉越大。第二方面是 SQL Server 2012 企业版许可证的成本，比起 Intel，AMD 处理器在它们的处理器内有更多的物

理内核数，并且它们每个物理内核的性能却更低。这使得你需要花更多的钱去买更多的SQL Server 2012 内核许可，但却得到更差的单线程性能。因此 SQL Server 2012 和 AMD 处理器，

并不是一对好的组合。因为 SQL Server 2012 企业版是通过物理内核的数量来购买相应的许可，这使得对于

SQL Server 2012，采用相对性能较差的 AMD 处理器所需要的成本反而更多。一种支持采

用 AMD 的观点是，其高端的处理器明显要比同样高端的 Intel 处理器便宜很多。如果你考

虑的重点是如何使硬件成本降至低，且不考虑它对性能及可扩展性的影响，那么可以考

虑购买低内核数量的基于 AMD 处理器的系统。公正来说，很多典型的 SQL Server 工作负

荷能够在新款的 AMD 系统上运行得很好。所以，如果降低硬件开销是你关注的问题的

话，你可以购买低内核数量的 AMD 服务器来省钱。

2.3.1 Intel 处理器

直到 2011年 Intel至强 E7系列处理器和 2012年 Intel至强 E5系列处理器的问世，Intel提供了多种处理器系列来满足插槽数量不同的服务器。例如，Intel 至强 3xxx 系列用于单

路服务器，Intel 至强 5xxx 系列用于双路服务器，以及 Intel 至强 7xxx 系列用于 4 路(或更

多)服务器。现在，Intel 至强 E5 系列处理器可同时用于单路、双路以及 4 路服务器：至强

E5-2400 系列用于单路或双路服务器，至强 E5-2600 系列用于双路服务器，至强 E5-4600系列用于 4 路服务器。至强 E7 系列则可用于双路、4 路或 8 路服务器。至强 E7-2800 系列

用于双路服务器，至强 E7-4800 用于 4 路服务器，至强 E7-8800 系列用于 8 路(或更多)服务器。这些来自 Intel 的新选择在你去关注它的细节之前会使你感到疑惑。

在 SQL Server 2012 发布前，花更多的钱为每一路插槽配备好的处理器是选择数据库

服务器处理器的有效方式。因为 SQL Server 处理器的许可证非常昂贵(标准版也如此)，所以你通常会为所购买的昂贵的处理器插槽许可证配备尽可能高的处理器性能和可扩展的

容量。这种战略在 SQL Server 2008 及更早版本中是有效的，但 SQL Server 2012 Enterprise 版

许可的变化改变了人们一贯的思考方式。2011 年 11 月初，微软公司宣布了 SQL Server 2012较之早期的版本在许可证方面的一些根本性变化。SQL Server 2012 有三个主要的版本：

Enterprise 版、Business Intelligence 版和 Standard 版。早期的 Data Center 版和 Workgroup版被废除了，这可能没什么大的损失。现有的 Developer 版和 Express 版连同托管供应商所

用的 Web 版都还是可用的。与早期为人熟知的 SQL Server 2008 R2 及更早版本所用的基于插槽的许可方式相比，

SQL Server 2012 采用了基于内核和服务器+CAL(Client Access License，客户端访问许可)的组合授权方式。这取决于你购买的版本类型，以及为 Standard 版选择的授权方式。在

第Ⅰ部分内核

34

Standard 版上，用户可以选择基于内核的许可或者服务器+基于 CAL 的许可；在 Business Intelligence 版上，用户必须使用服务器+基于 CAL 的许可；而 Enterprise 版则需要内核的

许可。Standard 版是基础版，多能用 16 个物理处理器内核。微软公司还将 SQL Server 2012 Standard版的内存继续限制在64GB(如同SQL Server 2008 R2 Standard版的物理内存被限制

在 64GB 一样)。Business Intelligence 版包含了 Standard 版的所有基本功能，加上额外的 BI特性及功能。Enterprise 版包含 Business Intelligence 版的所有基本功能，加上额外的

Enterprise 版的特性及功能。Enterprise 版是 SQL Server 2012 的高版本，它现在包含了在

SQL Server 2008 R2 Data Center 版中可用的所有功能。作为一个 DBA，假如你能选择的话，

你肯定想要用 Enterprise 版，因为它能提供许多有用的功能，比如在线索引操作、数据压

缩和 AlwaysOn 可用性组等。假如你使用的是基于内核的授权(因为你必须使用 SQL Server Enterprise 版)，那么你的

服务器针对每一个物理插槽至少需要购买 4 个内核许可。那就意味着即使原有的处理器是

双核的，你依然需要为每一个插槽购买 4 个内核许可。这就是不能在 SQL Server 2012 上使

用古老硬件的另一个原因。任何一个只有 2 个物理内核的 Intel 至强或者 AMD 皓龙处理器，

而它们的上市时间要比 SQL Server 2012的发布早 4到 5年，所以如今它们的确应该退休了。

记住授权只与物理内核数量有关(在非虚拟服务器上)，所以从许可证的角度来看，Intel 的

超线程技术是免费的。现在针对一个物理插槽至少 4 个内核，内核许可证以 2 个内核包的方式进行销售。SQL

Server 2012 Enterprise 版所需要的每一个物理内核的零售价是 6 874 美元。这对 AMD 来说

是相当严峻的消息，因为与 Intel 相比，采用 AMD 处理器的服务器，拥有更多的物理内核

数，而且每个插槽的性能相对较低。这种情况如此明显，微软在 2012 年 4 月 1 日公布了一

份 SQL Server 2012 内核售价表，对于一些有 6 个甚至更多内核 AMD 的新型处理器，处

理器单核许可证的售价低了 25%。即便有了这样的变化，新的 AMD 处理器对于 SQL Server 2012 来说，依然不是具有成本效益的选择。表 2-1 采用详细的图表方式将这些成本

之间的差异展现出来，还包括了对于 AMD 处理器的用于许可证售价的 0.75 AMD 内核系

数(见之后的 2.3.3 节)。

表 2-1 SQL Server 2012 许可证售价比较

处理器内核数量每插槽售价槽数每台服务器的总许可证售价

Intel 至强 X5690 6 $41 244 2 $82 488

AMD 皓龙 6282SE 16 $82 488 2 $164 976

Intel 至强 E5–2690 8 $54 992 2 $109 984

Intel 至强 E5–4650 8 $54 992 4 $219 968

Intel 至强 X7560 8 $54 992 4 $219 968

Intel 至强 E7–4870 10 $68 740 4 $274 960

AMD 皓龙 6180SE 12 $61 866 4 $247 464

AMD 皓龙 6282SE 16 $82 488 4 $329 952


35

对于双路服务器上的一个 OLTP 工作负荷而言，Intel 至强 E5-2690 处理器比起 Intel至强 E7-2870 处理器会是更好的选择，因为它的单线程性能要更好。因为 E5-2679 是更新

一代的产品(Sandy Bridge-EP 同 Westmere-EX 对比)，有着更高的时钟频率、更好的内存带

宽以及支持 PCIe 3.0 技术。对决策支持系统或者数据仓库类型的工作负荷来说，E5-2690由于同样的原因仍然是更好的选择，虽然它的内核数量以及三级缓存的容量相对较小。

对于大多数 OLTP 工作负荷，从性能方面来说，选择一款较老的双路 Intel 至强 X5690服务器或双路 Intel 至强 E5-2690 服务器要比选择 4 路的 AMD 皓龙 6282SE 服务器好得多。

而两种处理器在许可证成本之间的巨大差异，也使得 Intel 成为一个更有吸引力的选择。如

表 2-2 所示，一种在一定程度上论证上述观点的方法是比较不同系统的 TPC-E 分数并除以

系统中的总物理内核数(不是按线程数量划分)。

表 2-2 总物理内核的 TPC-E 分数表

系统处理器 TPC-E 插槽数总内核数每个内核

的得分

HP Proliant DL380 G7 Intel 至强 X5690 1284.14 2 12 107.01

IBM System × 360 M4 Intel 至强 E5–2690 1863.23 2 16 116.45

HP Proliant DL385 G7 AMD 皓龙 6282SE 1232.84 2 32 38.53

HP Proliant DL585 G7 AMD 皓龙 6176SE 1400.14 4 48 29.17

IBM System × 3850 × 5 Intel 至强 E7–4870 2862.61 4 40 71.57

NEC Express 5800/A1080a Intel 至强 E7–8870 4614.22 8 80 57.68

在已有的数据库服务器上，一直给处理器升级使其拥有更好的性能是一件不可能的事

情，所以对于服务器的整个生命期你将受困于对处理器的选择。如果你有“多余的”处理

器能力，考虑通过备份压缩和数据压缩(如果你有 SQL Server 2008 Enterprise 版或更高的版

本)牺牲 CPU 利用率换来 I/O 利用率。这与笔记本电脑或者 Web 服务器不同，作为数据库

服务器的使用来说，购买一个比当前的顶级处理器要低两三代的处理器是错误的。牺牲部

分额外的 CPU 利用率换来相对较少的 I/O 利用率通常是一个不错的办法，尤其当你拥有的

是一款新型的可以随时处理额外工作的多核处理器时。当然，一款新型双路服务器的物理内存的总数要比一款新型四路服务器的少。例如，

一款双路至强 X5690 型服务器，多能有 288GB 的物理内存，这对大多数的工作负荷来

说已经足够了。一款双路服务器的总 I/O 容量也同样要比新型 4 路服务器的少，因为它的

PCIe 扩展插槽的数量要更少。尽管如此，对于一款新型的双路服务器来说它的顺序吞吐量

可轻易达到 5～6GB/sec，这对于大多数工作负荷来说是足够用了。在 2012 年年初，Intel 32nm Sandy Bridge-EP 至强 E-5-2600 系列处理器发布之后，为服务器选择一款基于 Intel的双路服务器愈发的是一种明智之举了，因为它有了更高的内存密度、更大的 I/O 带宽，

甚至比起至强 5600 系列它还拥有更好的单内核性能。

第Ⅰ部分内核

36

如果你正在寻找更低端的成本和工作负荷范围，你会有很多选择。单路 22nm Intel 至强 E3-1290 v2 处理器(基本来说这与采用 Ivy Bridge Core i7 处理器的台式机是一样的)，多能有 32GB 的物理内存，这在一定程度上限制了其对较大的数据库使用的效用。如果

32GB 的物理内存对于你的工作负荷来说不够用的话，可选用一个 Intel 至强 E5-2400 系列

处理器的单路 Dell R320 服务器，它的内存升级到了 96GB。而 SQL Server 2012 Standard版的物理内存依然被限制在 64GB，作为现代的硬件而言，这样的存储密度太低了。拥有

良好硬件的(拥有超过 128GB 物理内存)的一种可能解决办法就是在同一台物理服务器上安

装 SQL Server 2012 Standard 版的多个实例。

1. 经典的 Intel 处理器编号

为了解较早的 Intel 处理器编号，你需要知道如何解读经典的 Intel 处理器编号。说到

经典，我们指的是从 2006 年到 2011 年 4 月之间生产的 Intel 至强处理器(就在这个时期，Intel为新型的以及即将上市的处理器引入了一种新的处理器编码系统)。

了解如何解读处理器型号编码是一种非常实用的技能，通过编码可以知道一个特定处

理器的性能、相应的年代以及相对性能。如图 2-1 所示，这就是一个具体的 Intel 处理器编

码的例子。

处理器名称

Intel 至强处理器 X5482

(品牌系列) (编号) 图 2-1

Intel 至强处理器编码采用 4 位数字序列来分类，并在开头增加一个前缀来指出它是对

电源使用还是性能进行了优化。这些前缀如下： ● X，指性能 ● E，指主流 ● L，指电源优化型号编码以 3、5 还是 7 开头，这取决于它被设计用于哪类服务器。如果处理器的编

码开头是 3，它被设计用于一个单路服务器；如果开头是 5，它被设计用于双路服务器；如

果开头是 7，它被设计用于 4 路或者更多路的服务器。编码的第二位数表示第几代处理器，

或者处理器相应的年代。例如，至强 5100 系列是在 2006 年第 2 季度推出的，至强 5300系列是在 2006 年第 4 季度推出的，至强 5400 系列是 2007 年第 4 季度推出的。

再举一个更完整的例子，至强 X7560 是一款用于多处理器系统的高端性能的处理器，

至强 E5540 是用于双路处理器系统的主流处理器，而至强 L5530 是用于双路处理器系统

的电源优化处理器。编码的后三位数字表示处理器的性能及它属于哪一代产品。例如至强

X7560 处理器比起至强 X7460 处理器要更新一些，其性能也可能要更高一些。型号编码的


37

后三位数字越大，意味着该处理器在 Intel 家族里是更新一代的产品，例如 560 就比 460要新。

对 SQL Server 的使用来说，你应该始终选择带 X 型号前缀的性能优化型处理器。和 E系列相比，选择 X 系列 Xeno 处理器产生的额外的成本，和数据库服务器系统里总体硬件

和 SQL Server 许可证的成本相比是微不足道的。你还需要避免使用电源优化的 L 系列处理

器，因为每一个处理器在节约 20w~30w 电量的时候，其处理性能会被降低 20%~30%，而

节约下来的电量和一个典型的数据库服务器(有风扇、内部驱动器、电源供给系统等)所消

耗的电量相比，是微不足道的。当然，假如你需要数十台或者上百台的 Web 服务器来取代

一些数量较少的用来执行关键任务的数据库服务器的话，这就是另一回事了，因为在这种

情况下节约下来的总电量会相当多。

2. 当前 Intel 处理器编号

这一节描述了当前的 Intel 处理器编号方式，用于 2011 年 4 月 5 日上市的 Intel 至强系

列处理器。新编号方式如图 2-2 所示，用于 Intel 在那天发布的 E3 系列及 E7 系列处理器以

及在 2012 年 3 月份发布的 E5 系列处理器。在这新编号系统中，已有的旧型号的至强处理

器编码依然不变。

处理器名称

Intel 至强处理器 E3 - 1235

(品牌系列) (产品线)

L

处理器 SKU

wayness，一个节点中的大 CPU 数量插槽类型

版本

图 2-2

编号开头的两位数代表了产品线设计，根据产品整体阵容分为 E3、E5 或 E7。产品线

设计编号之后的 4 位数字提供了关于特定处理器的更多详细信息。第一位数字表示

“wayness”，它是指在一个节点上(这里指物理服务器)允许的 CPU 数量。它可以是 1、2、4 或 8。第二位数字指在物理及电气特性方面的插槽类型。后两位数字是处理器 SKU，

数字越高通常处理性能越高。后，“L”表示是高能效、低功耗的处理器。作为 SQL Server 数据库服务器的使用来说，要避免使用能耗优化的处理器，因为功耗的降低对性能的影响

是相当显著的。 E3 产品家族用于单处理器的服务器或工作站。这个家族的第一代产品(E3-1200 系列)

从根本上来说和 2011 年 1 月上市的采用 32nm Sandy Bridge 处理器的台式机是一样的。这

个家族的第二代产品是 E3-1200v2，基本上和 2012 年 3 月上市的采用 22nm Ivy Bridge 处

第Ⅰ部分内核

38

理器的台式机是一样的。这两代产品的物理内存都被限制在了 32GB。

E5 产品家族(32nm Sandy Bridge-EP)包含了在 2012 年 3 月发布的 E5-2600 系列以及在

2012 年 5 月发布的 E5-2400 系列(32nm Sandy Bridge-EN)和 E5-4600 系列。要避免使用入门

级的 Sandy Bridge-EN 系列，因为和 Sandy Bridge-EP 系列相比其内存带宽较小，时钟频率

较低。

E7 产品家族(32nm Westmere-EX)针对双路、4 路、8 路甚至更多路的服务器有不同类

型的处理器。E7-2800 系列用于双路服务器，E7-4800 系列用于 4 路服务器，E7-8800 系列

用于 8 路或更多路的服务器。在这一家族产品代号的后，“EP”(例如 Westmere-EP)代表

了高效的性能(Efficient Performance，EP)，而“EX”代表可扩展(expandable)。

3. Intel 的“Tick-Tock”发布战略

从 2006 年起，Intel 采用并实施了“Tick-Tock”(工艺年-架构年)战略用于开发和发布

新的处理器型号。每两年，他们就推出一个使用新型微架构的新处理器家族，这就是架构

年的发布。在新架构发布之后的一年，他们又会推出一个新的处理器家族，它们和上一个

架构年推出的处理器的微架构相同，但使用更小的工艺制造技术，通常还会包含一些小的

改进技术，如更大的缓存空间以及改进的内存控制器。这就是工艺年的发布。这种工艺年-

架构年的发布战略给 DBA 带来了很多好处。在主要(架构)和次要(工艺)发布何时可用方

面，它提供了更好的预见性。这将帮助你规划硬件升级来配合操作系统及 SQL Server 版

本的升级。

新发布的 Tick(工艺)通常和上一年发布的 Tock(架构)在插槽上是兼容的，这使得服务

器的生产厂商能够更容易将新发布的 Tick(工艺)处理器快速地用于既有的服务器型号中，

而不必完全重新设计系统。大多数情况下，既有的服务器系统要使用新的 Tick(工艺)处理器，

只需将 BIOS 升级即可。这也便于 DBA 维护服务器，服务器可以使用相同的型号(比如

Dell PowerEdge R710 服务器)，因为服务器型号将有更长的生产寿命范围。例如，Dell

PowerEdge R710 既可以使用原有的 45nm Nehalem-EP 至强 5500 系列处理器，也可以使

用新出的 32nm Westmere-EP 至强 5600 系列处理器，因此这款服务器可供采购超过 3 年

以上。

做为一名 DBA，你要知道一个特定的处理器位于 Intel 处理器谱系的哪一个位置

上，以便于有意义地去比较两款不同的服务器的相关性能。历来，处理器的性能几乎

在每一次新的 Tock(架构)发布之后是翻倍的，而随之发布的 Tick(工艺)又会使服务器的

性能增加大约 20%~25%。一部分当前的以及即将上市的 Intel Tick-Tock 发布情况如图

2-3 所示。


39

近几年的 Tick-Tock 模型发布情况

生产工艺技术微架构

Intel微架构代码名为

Nehalem Intel微架构代码名为

Sandy Bridge Intel 微架构代码名为

Haswell

提高性能、新增

功能、高效节能

以及尺寸上的

改进

图 2-3

生产工艺技术涉及芯片内部电路和晶体管的尺寸。Intel 4004 系列(1971 年发布)采用的

是 10 微米的工艺技术，即在处理器上的小工艺尺寸是一米的百万分之十。与之相反，Intel

至强“Ivy Bridge”E3-1200v2 系列(2012 年 5 月发布)采用的是 22nm 的工艺技术。比较而

言，一纳米等于十亿分之一米，所以 10 微米等于 10 000 纳米。这种不断缩小的生产工艺

技术从两方面来说都是非常重要的：

● 增强性能及降低功耗—— 即便在此距离上是光速传播，处理器上距离更近的更小元

器件意味着更高的性能及更低的功耗。

● 降低制造成本—— 这是可能的事情，因为大多数处理器是在一个标准的硅晶片上制

作的。这有助于在较低的成本下制造出强大且低功耗的处理器，使得每个人(尤其

是数据库管理员)从中收益。

第一个 Tock(架构)的发布是 Intel Core 微架构，这是在 2006 年发布的采用 65nm 工艺

技术的“Woodcrest”双核架构(至强 5100 系列)引入的。紧随其后的是尺寸减小的 45nm 工

艺技术的双核处理器“Wolfdale”(至强 5200 系列)和在 2007 年年末发布的 4 核处理器

“Harpertown”，这两种处理器都是 Tick(工艺)发布。接下来的 Tock(架构)发布是在 2008

年年末引入的 Intel“Nehalem”微架构(至强 5500 系列)，它采用的是 45nm 工艺技术。到

了 2010 年，Intel 进行了一次 Tick(工艺)发布，代号为“Westmere”(至强 5600 系列)的在

服务器空间缩减到了 32nm 工艺技术的处理器。到 2011 年，32nm 的“Sandy Bridge”

Tock(架构)与用于单路服务器及工作站的 E3-1200 系列处理器初次登场。接下来的 Tick(工

艺)发布是“Ivy Bridge”的 E3-1200 v2 系列，它还是用于单路服务器及工作站，而它的尺

寸已经缩小到了只有 22nm。表 2-3 列出了近期的以及即将发布的用于双路服务器的

Tick-Tock。

第Ⅰ部分内核

40

表 2-3 双路服务器用的 Intel Tick-Tock 发布年历

发布类型年份工艺系列代号

Tock 2006 65nm 5100,5300 Woodcrest、Clovertown

Tick 2007 45nm 5200,5400 Wolfdale、Harpertown

Tock 2008 45nm 5500 Nehalem-EP

Tick 2010 32nm 5600 Westmere-EP

Tock 2012 32nm E5-2400,E5-2600 Sandy Bridge-EP

Tick 2013 22nm TBA(E5-2600v2?) Ivy Bridge-EP

Tock 2014 22nm TBA Haswell

Tick 2015 14nm TBA Rockwell

Tock 2016 14nm TBA Skylake

4. Intel 超线程技术

2002 年 Intel 实施了一项称为超线程的新技术，它是基于 Northwood 的奔腾 4 处理器

的 NetBurst 微架构以及对等的至强处理器家族的一部分。超线程用于解决当一个系统的中

央处理器在等待来自主内存的数据时出现的频繁浪费处理器周期问题。这项技术是在一个

物理内核内设计了两个逻辑处理器，当其中一个逻辑处理器在等待主内存数据时，另一个

逻辑处理器能独立完成一些其他的工作，而不是在等待期间内浪费处理器周期。超线程技术是 Intel 公司的销售术语，这种同步的多线程微架构即是其中的每个物理处

理器内核被划分成了两个逻辑内核。“同步”在这里有一些误导，实际上你不可能在同一个

物理处理器的单个物理内核里让两个不同的线程同时运行在两个逻辑内核上。真实的情况

是两个不同的线程交替执行，当其中一个在执行时，另一个是空闲的。对台式机应用程序而言，超线程技术的运行效果非常好。一个典型例子就是当正在运

行一个完整的杀毒扫描程序时，操作者依然能在前台交互运行另一个应用程序。遗憾的是，

在奔腾 4 的 NetBurst 架构上，超线程的初期实施在很多服务器工作负荷(如 SQL Server)下表现不佳。因为每个物理内核的二级缓存会被两个逻辑内核共享，由于二级缓存必须不断

地刷新内容，以完成它在两个逻辑处理器间的应用程序上下文切换，这会导致性能问题。

这种行为称作高速缓存抖动，它通常会导致 SQL Server 工作负荷的总体性能下降。更糟的

是，奔腾 4 架构中有一些非常深的处理器管道，当逻辑处理器所需的数据在其中而不在二

级缓存区时，会消耗更多资源。由于这些因素，数据库管理员通常会为了适用于各种 SQL Server 工作负荷而将超线程

禁用，这是个错误的做法。在启用超线程时，不同类型的 SQL Server 工作负荷对其响应的

方式是不同的，启用超线程通常会使 OLTP 工作负荷的性能更佳，有时又会使数据仓库工

作负荷的性能变差。所以，决定启用或禁止超线程之前，用实际工作负荷测试一下这两种

方式。


41

现代的 Intel 处理器(Nehalem、Westmere、Sandy Bridge 和 Ivy Bridge)有了更大的二级

和三级缓存容量，有了更新的处理器架构以及更快速的主内存访问，采用超线程能更好地

工作了。因为如此，我会建议你启用 SQL Server 的超线程，尤其是在 OLTP 工作负荷的情

况下，除非你已经做了实际的测试，能证实超线程在实际工作负荷下会降低处理器的性能。

在数据库服务器上针对这些新型的 Intel 处理器提交的每一个 OLTP 工作负荷的 TPC-E 基

准测试，都会有意将超线程启用，这样做是有重大意义的。

2.3.2 AMD 处理器及编号

这一节讨论 AMD 皓龙处理器的编号。超微半导体公司(Advanced Micro Devices，AMD)提供给服务器使用的皓龙系列产品种类繁多。在评估 AMD 处理器时，明白其编号的含义

是非常有用的。当今的 AMD 皓龙处理器是通过 4 位字符的型号来识别，其格式为 ZYXX，

Z 表示产品的系列： ● 1000 系列=单路服务器 ● 2000 系列=可达双路的服务器和工作站 ● 4000 系列=可达双路的服务器 ● 6000 系列=高性能的双路及 4 路服务器 ● 8000 系列=可达 8 路的服务器及工作站 Y 用来区分同一个系列的不同产品： ● Z2XX=双核 ● Z3XX=4 核 ● Z4XX=6 核 ● 第一代 AMD 皓龙 6000 系列处理器记为 61XX ● 第二代 AMD 皓龙 6000 系列处理器记为 62XX 后两位的 XX 表示同一系列里产品特性的变化(比如，8200 系列的双核处理器，有

相应的 8214、8216、8218 等产品)，并且它们不表征性能指标。在 XX 产品编号后，你还

可能找到带两个字符后缀的产品，如下： ● 无后缀—— 表示一款标准供电的 AMD 皓龙处理器 ● SE—— 性能优化，高功耗 ● HE—— 低功耗 ● EE—— 低功耗的 AMD 皓龙处理器例如，皓龙 6282SE 是一款 6000 系列，针对性能优化的 16 核处理器；皓龙 8439 SE

是一款 8000 系列，性能优化的 6 核处理器；而皓龙 2419EE 是 2000 系列的低功耗 6 核处

理器。对于执行关键任务的数据库服务器，假如处理器对于你的服务器型号可供使用，我

们建议选用带 SE 后缀的处理器系列。由于带 SE 后缀的处理器功耗较大，因此它们不能用

于每一台服务器。需要注意的是 AMD 新推出的皓龙(包括 4100、4200、6100 以及 6200 系列)处理器打

第Ⅰ部分内核

42

破了原有的编号规则，它们并不遵循刚才介绍的标准的编号方式。近年来已发布和即将发布的 AMD 皓龙处理器在表 2-4 中列出。从 2011 年起，16 核

的 Interlagos 处理器成为 AMD 推出的性能好的处理器，尽管它的发布没有达到期望值。

表 2-4 近年 AMD 处理器的发布

年份工艺系列名称

2006 90nm 1200，2200，8200 Santa Ana，Santa Rosa

2007-8 65nm 1300，2300，8300 Budapest，Barcelona

2009 45nm 2400，8400 Shanghai，Istanbul

2010 45nm 4100，6100 Lisbon，Magny-Cours

2011 32nm 4200，6200 Valencia，Interlagos

2013 32nm 4300，6300 Seoul，Abu Dhabi

2014 28nm TBA TBA

SQL Server 2012 内核系数表

我们来看一下近提交的关于 AMD 和 Intel 处理器的 TPC-E 基准测试报告，很容易就

能发现那些少量进行过测试的 AMD 系统比起 Intel 系统相形见绌。例如，在 2012 年 1 月

一份新提交的关于 32 个物理内核的双路 AMD 系统的惠普的 TPC-E 测试报告，显示其 tpsE得分为 1232.84，与之相比，只有 12 个物理内核的双路 Intel 系统的 tpsE 得分为 1284.14。这两种测试都是在 SQL Server 2008 R2 上完成的。结果表明在得分差不多的前提下，为 SQL Server 2012 Enterprise 版选择 AMD 系统的许可证开销是 Intel 系统的 2.66 倍(32 个物理内核

与 12 个物理内核相比)。这对于 AMD 来说，是个悲惨的消息，因为与 Intel 相比，它们的

系统需要更多的物理内核，且单核的 OLTP 性能更低。大概是为了对这种情况做出回应，在 2012 年 4 月 1 日，微软发布了一个新的 AMD 处

理器的 SQL Server 2012 内核系数表，见表 2-5。需要注意的是表中并未包含所有的处理器。

表 2-5 AMD 处理器的 SQL Server 2012 内核系数表

处理器类型内核系数

其他类型的 AMD 处理器 1

有 6 核或更多内核的 AMD 31XX、32XX、41XX、61XX、62XX 系列处理器 0.75

单核处理器 4

双核处理器 2

表中重要的部分指出了较新的有 6 核或更多内核的 AMD 处理器—— 31XX、32XX、

41XX、42XX、61XX 及 62XX 系列的内核系数为 0.75。内核系数为 0.75 的含义是指用实

际的物理内核数量与内核系数相乘后得到的值，表示你需要为 SQL Server 系统购买的许可


43

证的内核数量。例如，假设你的服务器是 4 槽的，每一槽位上插一个 AMD 皓龙 6284 SE处理器。这款处理器是 16 核的，所以你的 SQL Server 2012 需要 16×４＝64 个物理内核的

许可证(在内核系数表发布之前)。根据内核系数表使用新的许可证规则，你将只需购买 64×0.75=48 个内核许可证就满足 SQL Server 2012 服务器的需求了(在内核系数表发布之后)。这意味着对于一部分 AMD 处理器，在有了内核系数表后，对于 SQL Server 2012 比起之前

没有内核系数的计算，在一定程度上能支付得起了。基于SQL Server 2012的内核系数表，为SQL Server 2012 Enterprise版购买32核的AMD

系统，比起 12 核的 Intel 系统(32×0.75 和 12)只需要支付其 2 倍的价钱。这对 AMD 来说

稍有改观，但他们的产品依然很难卖出去。根据 TPC-E 基准测试的结果，较老款的 Intel 至强 X5600 Westmere-EP 系列以及新款

的 Intel 至强 E5-2600 Sandy Bridge-EP 系列在 OLTP 工作负荷上的单核性能都要优于新

款 AMD 皓龙 6200 系列处理器。这些 Intel 处理器从根本上来说有显著的更好的单线程性

能，这对 OLTP 工作负荷来说是非常重要的。有了新内核系数表后，针对那些拥有超过 6 个物理内核的 AMD 处理器，SQL Server

2012 处理器内核许可证比以前要稍微便宜了一些，但从总体上来说它们依然要比一个性能

更优的 Intel 解决方案贵很多。较低的 AMD 处理器硬件成本与 Intel 处理器硬件成本的差

异，比起两者许可证成本的差异是微乎其微的。期待 AMD 在 2013 年发布的基于 Piledriver 内核的皓龙系列处理器能做得更好一些。

2.4 为冗余选择及配置硬件

本节介绍了当你正试图增加单个数据库服务器的基本弹性和可用性时，从硬件的角度

你应该考虑的重要项目。它们是在为你的数据层设计一个高可用性解决方案的一部分时

你将采取的第一步。这里的基本目标是尽可能多地消除硬件及配置层面的单点故障。因此，

当为数据库服务器选择组件并且将它们列入服务器配置的一部分(例如，与 Web 服务器相

反)时，你需要从这些方面进行考虑，无论你决定使用其他任何高可用性技术。你必须总是为操作系统及 SQL Server 二进制文件用两个内部的驱动器配置一个 RAID

1(镜像)。这些驱动器必须使用对大多数的新的机架式服务器可用的集成的硬件 RAID 控制

器。采用一个集成的硬件 RAID 控制器(通常有 256MB～512MB 的缓存)能获得比通过

Windows 操作系统使用软件 RAID 更好的性能。拥有在 RAID 1 中的两个驱动器能够为操

作系统及 SQL Server 二进制文件提供一个基本的冗余级别，所以当其中一个驱动器失效

时，服务器不会停止工作。要做到这一点，至少需要 146GB、15K、2.5 英寸的驱动器。使用 15K 转速的驱动器

能够使服务器 Windows 操作系统的启动以及当第一次启动时 SQL Server 的加载速度稍微

快一点。使用 146GB(或更大)的驱动器能提供更多的空间来容纳信息，如 Windows 页面文

件、SQL Server 错误日志文件和转储文件等等，而且不必担心驱动器容量不足的问题。随

第Ⅰ部分内核

44

着 SSD 价格的走低，你可以考虑用两个 SSD 来做成镜像的启动驱动器。使用 SSD 有助于

缩短系统启动时间以及 SQL Server 的加载时间，并能帮助你达成恢复时间目标(RTO)。确保你的数据库服务器有两套电源供给系统，并且在你的机房或者数据中心中，它们

要分别接入不同的隔离电路。你还要给每个电路接入一个不间断电源(Uninterruptable Power Supply，UPS)，而且理想情况下还要准备一个备用电源，例如为数据中心配备一台柴油发

电机。这么做是针对内部电源供电失败进行保护，如电源插头被拔掉、断路器跳闸或者电

网停电。再增加一路供电相对来说是一种不算贵的保障方法，通常来说开销小于 300 美元。

即便如此，多年来我们仍看到很多商家在这个领域的激烈竞争。由于会出现供电失效、插

头接触不良或断路器跳闸，因此一定要为数据库服务器配备双套的电源供电。在服务器上

需要配备多种网络接口，而且通过以太网接口需要和至少 2 台不同的网络交换机相连。在

数据中心中，这些网络交换机(同样需要双电源供电)需要被接入到不同的电路中。大部分

的新型机架式服务器在其主板上至少配备了 4 路千兆以太网接口。这些设计方法都是为了

防止由单路网络端口中断或单路交换机故障造成的系统停运。还需要配置多个 RAID 控制卡(如果你使用直连式存储或内部存储)；多个主机总线适

配器(Host Bus Adapter，HBA)(如果你使用光纤通道 SAN)；或多个千兆位的 PCIe 接口，或

具有 iSCSI SAN 功能的更好以太网卡。根据你对它们的配置，它们将带给你更好的冗余以

及更高的吞吐量。同样，这里的方法也是尝试防止单个模块的失效导致系统停运。无论你的 SQL Server 数据文件、日志文件、tempdb 文件以及 SQL Server 备份文件放

在哪里，它们都需要一个适当级别的 RAID 保护，具体取决于你的预算和性能要求。你想

要避免单个驱动盘故障导致的数据库性能下降。记住 RAID 不是一个恰当的 SQL Server 备份和存储策略的替代品。绝不要让任何人(无论是 SAN 供应商、运营团队的服务器管理员

还是你的老板)说服你不去进行 SQL Server 备份来达成合适的恢复点目标(RPO)及恢复时

间目标(RTO)。这一点怎么强调都不过分!虽然在整个职业生涯里，在 SQL Server 数据库备

份这件事情上你将会受到来自不同的人的压力，但 SQL Server 备份文件绝对是不可替代

的。坚定你的立场。有一句老话是真理：“如果你没有备份，你就没有数据库。” 为了减少数据库服务器启动及 SQL Server 的启动时间，注意下列所述的 BIOS 的配置

设置。对一台独立服务器来说，减少总体的重启时间会直接影响系统的高可用性。因此，

进入到服务器的BIOS设置界面，然后禁用内存检测(通常发生在一系列的上电自检<POST>期间)，将会为启动(通常是几分钟，这取决于你装了多少 RAM)节省大量时间，因此服务

器上电速度会变快。这样做的风险也很小，因为内存检测只发生在上电自检期间，等到服

务器运行起来后它并不去检查内存问题，而对硬件的检查，则是通过系统监视软件来完

成的。当你正在进行 BIOS 设置时，同样，需要进入 Power Management 一栏，然后将电源管

理设置为 disable 或将它们设置成 OS control。默认情况下，Windows Server 2008 和 Windows Server 2008 R2 采用了 Windows Balanced Power Plan。它通过减少处理器的倍频设置(当系

统不处于高负荷的情况下，自动降低处理器的时钟频率)来降低功耗。这看起来像一个好主


45

意，但是实际上它会对系统性能产生很大的负面影响，因为一些处理器不能足够快地响应

工作负荷的增加。如果你用的是 Intel Nehalem 或 Westmere 系列的处理器，这一点尤为重

要。新的 Intel Sandy Bridge 和 Ivy Bridge 系列处理器对电源状态变化的响应要比 Nehalem或 Westmere 快很多，因而从性能角度看，新的处理器使得系统对工作负荷变化的敏感度

降低了很多。无论用的是哪种处理器，电源管理依旧会对你的服务器产生其他方面的负面影响。一

个例子就是当你在服务器里使用 Fusion-io 卡。某些形式的硬件管理会影响到服务器中的

PCIe 插槽，所以 Fusion-io 尤其推荐你在 BIOS 设置中或 Windows 系统中将电源管理选项

禁用。简单的解决办法就是确保在系统中采用 High Performance Power Plan 并在 BIOS设置中禁用电源管理设置。

后，在确认你已经遵循了上述的指导方针后，你依旧没有做完这件事情。根据你的

RPO 和 RTO 需求，你需要计划和执行一些总体的高可用性及灾备(HA/DR)策略来为你提

供一个能处理尽可能多种类的问题及“灾难”的更强健系统。这个策略包含了诸如 Windows故障转移群集、数据库镜像、日志传送、事务复制和 SQL Server 2012 AlwaysOn 可用性组

这些技术，以及一个规划成功处理灾难所需的策略及步骤的实际计划。

2.5 硬件比较工具

我们坚决支持将现成的基准工具、常识和分析结果作为比较不同硬件类型和配置的手

段，而不是简单地猜测不同系统的相对和绝对性能，你可以使用标准化数据库基准测试和

特定组件基准测试结果，以更准确地评估和比较不同的系统和部件。本节将讨论两个这样

的基准工具：TPC-E OLTP 基准以及 Geekbench 处理器和内存性能基准。

2.5.1 TPC-E 基准

TPC Benchmark E (TPC-E)基准是一个在 2007 年初期推出的 OLTP 性能基准。TPC-E不能替代以前的 TPC-C 基准，它是一个全新的 OLTP 基准。即使这个更新的基准已经被使

用了超过 5 年时间，但除了 SQL Server，没有公布任何 RDBMS 测试结果。幸运的是，因

为大部分公布的结果都是针对 SQL Server 的，所以在评估 SQL Server 的硬件的时候，这是

一个非常有用的基准工具。在撰写本书时，已经发布了 54 份关于 SQL Server 2005、2008、2008 R2 及 2012 的 TPC-E 报告。这些数据为你提供了很多不同的系统及配置的情况，你可

以从中选择一种与你想要评估的系统类似的报告。 TPC-E 基准是一个以数据库为中心的 OLTP 工作负荷，与更早的 TPC-C 基准测试相比，

TPC-E 基准降低了成本和运行基准的复杂性。与 TPC-C 不同，TPC-E 的存储介质必须是容

错的(这意味着不能是 RAID 0 阵列)。总之，TPC-E 基准的设计与原先的 TPC-C 相比降低

了对 I/O 的要求，这使得它既节省了开支又容易实施，因为提供 TPC-E 支持的硬件供货商

将不再由于用极其巨大的昂贵的磁盘子系统来装配测试系统以获得好的测试结果而备感

第Ⅰ部分内核

46

压力了。TPC-E 基准与 TPC-C 相比，CPU 的活动更为密集，这意味着只要 I/O 子系统能够

有效地驱动工作负荷，测试趋向与 CPU 性能相关的结果会相当好。它模拟了经纪公司的 OLTP 工作负荷，它使用同步事务响应顾客及使用异步事务响应

金融市场。TPC-E 数据库由虚拟的真实数据填充，包括 2000 年美国人口普查的用户姓名

和来自纽约证券交易所及纳斯达克的上市公司名单。拥有的仿真数据引入了数据倾斜并且

使数据变得可压缩。经纪公司的商业模型由顾客、账目、有价证券组成。这种 TPC-E 的数

据模型比起拥有 33 个数据表以及许多不同的数据类型的 TPC-C 来说，明显更复杂且更加

逼真。而且 TPC-E 的数据模型也强制执行引用完整性，这一点与更早的 TPC-C 也不同。 TPC-E 的执行通过网络被分为一个驱动器和一个在测系统(System Under Test，SUT)。

驱动器代表了各种采用 N-层主从系统的客户端设备，即抽象成一个负荷的生成系统。SUT有多个与数据库服务器及其相关的存储子系统(层 B)通信的应用服务器(层 A)。TPC 提供

了一个事务工具组件在层 A 运行，同时测试赞助商提供在 SUT 上的其他组件。TPC-E 的

性能指标是每秒的事务数量，即 tpsE。实际 tpsE 得分代表了平均一秒内执行的交易记录的

事务数量。为完全符合 TPC-E 标准，所有与 tpsE 结果相关的数据都必须包含 tpsE 费率，

即每个 tpsE 的相关价格，以及价格配置的有效日期。目前公布的 TPC-E 分数范围从低

的 144.88 到高的 4614.22。这其中涵盖了双路、4 路、8 路到 16 路采用了各种不同 Intel或 AMD 处理器的系统的得分。在总的 54 份提交的测试报告中，只有 4 份是 AMD 处理器

的报告，这明显反映出了近 AMD 处理器性能的不足。当采用不同家族和型号的处理器评价不同服务器平台的 OLTP 性能时，你想要找到一

份与你想购买的系统具有相同型号处理器的 TPC-E 测试报告。如果你找不到一份完全匹配

的报告，可从一份接近的系统的报告来入手，然后使用组件的基准数据和常识来向上或

向下来调整结果。例如，比方说你正在考虑一个新的采用 2.6GHz Intel 至强 E5-2670 处理器的双路系统

的潜在性能。在查找已发布的 TPC-E 的报告之后，你找到了接近的报告是关于一个双路

的 2.9GHz Intel 至强 E5-2690 处理器的系统，它的 tpsE 得分是 1863.23。在查找完其他组件

级别的 CPU 及内存性能的基准数据后，考虑到两个采用同代同系列处理器(有相同数量的

内核、缓存容量以及内存带宽)系统的时钟速率差异，你可以保守地将得分降低 10%，在评

估后你得到了调整后的得分，约为 1676 tpsE。假设你想要评估一个较老的采用 2.66GHz Intel至强X7460处理器的 4路系统的潜在性

能，你找到了一个相似系统的 TPC-E 报告，其得分为 671.35 tpsE。思考这些还未经修订的

得分，你可能考虑将老的 4 路系统更换为新的双路系统，以获得更多的拥有更多可扩展性

净空间的更优性能。同时，你也需要深入了解实际的 TPC-E 报告，以更好地理解每一个被

测试的系统。对于每一个被测的系统，你想要知道的一些情况，比如操作系统的版本、SQL Server 版本、数据库服务器的内存数量、内部的数据库大小、存储类型以及主轴数量。这

些数据能使你更好地理解如何比较两个系统的有效性。当评估不同处理器的相对 OLTP 性能时，找出一个使用这个处理器的系统的 TPC-E


47

tpsE 原始分数，并除以系统内的物理内核数，就得到了相对的“每个物理内核的性能”。

使用先前的例子，提议的新的至强 E5-2670 双路服务器有 16 个物理内核。应用你评估得

到的分数 1676，然后用它除以 16 得到 104.75。较老的至强 X7460 4 路系统有 24 个物理内

核，采用实际的原始分数 671.35，然后将它除以 24，得到 27.97，由此看出了两款处理器

的单线程 OLTP 性能的巨大差异。

2.5.2 Geekbench 基准测试

Geekbench 是一种跨平台的综合性基准测试工具，它是由 Primate Labs 公司推出的。

它提供了一套相当全面的基准测试用于衡量系统的处理器和内存性能，这个系统可以是一

台笔记本电脑，也可以是一台多处理器的数据库服务器。在这个基准测试中，没有 I/O 性

能的测量。使用 Geekbench 的一个方便之处在于不需要考虑任何设置选项，你只需安装并

运行它即可，然后在三分钟内你就会看到所测试系统的得分。得分被细分为总的 Geekbench得分以及一些关于处理器和内存的分数。这对于比较可以多种方式配置的不同型号处理器

和不同型号服务器的相对处理器及内存性能相当有用。这个测试可能是一个非常可靠和有用的指标来衡量处理器和内存的性能。在线的

Geekbench 数据库中已经发布了数千份 Geekbench 得分报告，从网址为

http://browser.primatelabs.com 的网站上可以获取。你很可能可以从他们的数据库里找到几

乎任意一种你想要比较的处理器或服务器的 Geekbench 得分报告。这是非常便利的，当你

缺少一个大型的具有不同服务器及处理器的专用测试实验室时尤其如此。例如，假设你有一个较老的采用了两个 Intel 至强 E5440 处理器及 32GB 内存的 Dell

PowerEdge 2950 服务器。得到的结果是与其相似的系统的 Geekbench 得分约为 7950。你想

要给出采购一台新的配备两个 Intel 至强 E5-2690 处理器及 128GB 内存的 Dell PowerEdge R720 服务器的合理解释，并且从在线的数据库里找到了它的 Geekbench 得分约为 41 000。与 7950 分相比，得分显著提升了。将 Geekbench 得分与 TPC-E 的分数结合起来应用，是

一种非常可靠的办法来比较相对的处理器和内存性能，尤其对 OLTP 工作负荷有用。将这

两种基准测试结合使用是一个非常有用的技术，可为你提供良好服务。

2.6 本章小结

你正处于对你的数据库硬件和存储子系统进行评估、选择、改变规模以及配置的过程

中，熟悉系统将要处理的工作负荷的类型及特征是一件尤为重要的事情。不同类型的工作

负荷和混合式的工作负荷对你的服务器硬件及存储子系统的要求是不同的。你需要在此过

程中尽早考虑它，因为它会在很多方面影响你的选择。在考虑了工作负荷后，你需要决定是使用一个基于 Intel 处理器的数据库服务器还是一

个基于 AMD 处理器的数据库服务器，因为它能指导你在选好的系统供应商手里选择合适

型号的服务器。遗憾的是，由于上两代 AMD 皓龙处理器的单线程性能相对较差和处理器

第Ⅰ部分内核

48

的物理内核数量较多，即使是考虑了 SQL Server 2012 的内核系数表许可证的折扣以后，它

也很难用于 SQL Server 2012 Enterprise 版。如果 AMD 继续无法竞争高端市场，它会降低

Intel 用于维持其积极产品发布周期的激励机制，并且减缓创新的步伐，这从长远来看对 IT行业是个坏消息。

在选择你的处理器供应商后，你需要根据你的工作负荷和容量需求来决定使用单路、

双路、4 路或 8 路的数据库服务器。随着新一代的处理器以及内存和存储密度的改进，

许多较小的 SQL Server 工作负荷也许能在单路数据库服务器上运行得相当好。由于处理器已经变得越来越强大，而且内存及存储密度在过去几年内也不断改进，为

数据库使用配置双路服务器成为越来越可行的方法。Intel 更加迅速地不断发布用于双路服

务器的新一代处理器，且同一代的双路服务器有着比 4 路服务器更优越的单线程性能。这

意味着比起 4 路服务器，双路服务器能运行的 SQL Server 工作负荷比例要高很多，并且在

SQL Server 许可开销上能省很多钱。尽管在双路服务器方面有这样一些进步，一些类型的

工作负荷依然需要更多资源，这是双路服务器所不能提供的。假如你需要双路服务器所达

不到的更多内存、PCIe 扩展插槽或总处理器内核数，你不得不提高你的选择水平去看一看

4 路或更高级的服务器。随着 SQL Server 2012 Enterprise 版的新的基于内核的授权方式，你需要更密切地关注

服务器的物理内核数量和你可以从每一个物理内核获得的相对性能及可扩展性。在为服务

器的生命周期(可能是很多年)选择处理器时，你可能会被难住，所以明智地选择吧。明智

选择是指服务器的处理器在低物理内核总数的前提下能获得优的性能及可扩展性。不

明智的选择即是为了购买服务器的许可花了同样多甚至更多的钱，但得到的性能和可扩展

性却相对较低。在选择处理器时需要严肃谨慎的思想，可以采用基准测试报告来帮助你评

估自己的选择。由于服务器内存相对低廉，成本也持续下降，在受到 SQL Server 许可限制的情况，选

择大容量的内存是很有意义的事情。SQL Server 2008 R2 Standard 版和 SQL Server 2012 Standard 版都有一个被限制在 64GB 的许可。物理内存是一种廉价的 I/O 容量的部分替代

品。如果你有足够的物理内存将你的整个数据库装入内存中，这是一个理想的情况。许多

情况下，你可能不会有这种奢侈，但你还是应该在你能负担得起或尽可能匹配你服务器的

前提下，尝试获得更多内存。后，充分利用现成组件和应用程序级别的基准测试来比较和评估不同的系统和组

件，而不只是猜测。这种方法会向你提供关于不同系统更加精确的评估；不管你做什么，

都要努力学习更多的硬件知识以及随时间推移要一直站在新发展的前沿。这方面的知识对

于你作为一个数据库专业人员的职业生涯是至关重要的。

sql server - tup.com.cn · 术相关的问题。除了他的日常工作，他还为sql nexus、sql...

Documents