专家教你优化你的SQL Server硬件性能

核心提示：优化SQL Server硬件性能 对SQL Server的性能调整有很多种方式，就像建造一所房子，专家教你优化你的SQL Server硬件性能，你必须找到一个合适的地点，拥有肥沃的土壤、构建一个结实的地基，Jeremy撰写了大量的文章，并且在最初的SQL Server用户群和本地的SQL PASS上频繁发表文章，支持2

优化SQL Server硬件性能

对SQL Server的性能调整有很多种方式，就像建造一所房子。你必须找到一个合适的地点，拥有肥沃的土壤、构建一个结实的地基，支持2到3层的小楼，安装电气和插座，对墙壁刷油漆并进行装饰，最后进行不断的维护。

调整SQL Server的性能也具有类似的项目，其中包括:

硬件

Windows服务器

SQL Server

数据库设计

索引设计

T-SQL 开发

网络基础设施

前端代码

平台维护

虽然在获得高性能方面，没有哪个单个的组件比其他的具有更大的重要性，但是要争取的开始是必要的。如果你没有建造一个坚固的地基，那么应用程序的其他部分也会被较早的组件中的不足所困扰。更进一步的说，虽然也有可能在部署之后重新构建硬件，或者只是简单地移植到其他的硬件平台上，但是对整体平台的合适的计划，将会支持应用程序在很长的一段时间之内都避免极其消耗时间的升级。

硬件计划

合适的硬件计划是获得高性能的第一步。要根据需求来判断使用什么硬件是非常重要的，这些需求可以通过CPU、内存、驱动器、网络接口卡(NIC)等的容量计算得出。有时候，这些决策非常简单;你可以使用共同的标准来简化硬件的支持。如果标准不存在，那么抓住机遇并开始构建能够简化整体管理的标准。

由于标准化对于支持大量的服务器非常关键，因此它应该可以被后来的技术所兼容，所以你可以继续以较低的成本获得较高的性能。当前两种需要短期和长期考虑的硬件技术就是64位技术和数据库加速器。

64位体系结构

由于硬件提供商发布了64位的成本合理的服务器，Windows Server 2003 和 SQL Server 2000就可以用来平衡额外的资源来从扩大规模的角度改善整体的性能。在64位的世界里，64个CPU和 1TB的内存都可以直接定位，远远超过32位的世界中通常的4个CPU和3GB的内存——比两倍的资源还要多。

当前，64位的平台在工具和所有应用程序支持方面还有一些限制，但是这些情况都会随着时间而改变。现在要时刻关注64位的体系结构是至关重要的，因为他们成熟完善并且获得软件供应商更大的支持，这一点通过在一些已经相当大的服务器上提高规模选项来支持。

基于硬件的加速器

由于SQL Server，数据库加速器近来获得相当大的关注。在概念层上，数据库加速器是拥有CPU和内存的硬件设备。他们存储整个数据库，或者内存中的一部分表，用以处理需要回写到SQL Server的用户事务，这些事务最终需要存储数据。好处就是这些设备有时候可以支持整个数据库或者专用内存中的核心表，这样比访问磁盘上的数据要好。这种方式可以分别支持规模扩大和规模缩小，因为单个的数据库加速器可以减少硬件瓶颈，而不会对现有的SQL Server带来改变。

有一家提供这种类型解决方案的公司，名为XPrime。如果在升级可以被测试和完成之前，没有进一步的软件优化可以决定，并且正常运行时间不能受到危害，那么考虑一下这个选择。

理想的硬驱动层

针对SQL Server的数据库加速器最近获得了极大的关注。从概念的层次上说，数据库加速器就是一个带有CPU和内存的硬件设备。他们存储整个数据库或者是内存中的一部分表来处理那些需要回写到SQL Server的用户事务，这些事务最终将会存储数据。优点就是这些设备有时候可以支持整个数据库或者专用内存中的核心表，这比从磁盘中访问数据要优越得多。因为单个的数据库加速器可以减少硬件瓶颈，并且不需要给现有的SQL Server带来改变，从规模扩大或者缩小的角度具有优势。

有一家提供这种类型解决方案的公司，名为XPrime。如果在升级可以被测试和完成之前，没有进一步的软件优化可以决定，并且正常运行时间不能受到危害，那么考虑一下这个选择。

磁盘	磁盘组	驱动大小	控制器	RAID	尺寸	盘符	目的
0	2	72 GB	1 - 1	1	72	C:	Windows, SQL Server 程序组和系统数据库 (Master, Model, MSDB) (随机)
1	2	72 GB	1 - 1	1	72	D:	Tempdb (随机)
2	2	72 GB	1 - 2	1	72	E:	数据库事务日志 (串行)
3	5	72 GB	2 - 1	5	288	F:	数据库 (随机)
4	3	72 GB	2 - 2	5	144	G:	备份和批处理 (串行)
-	14	-	-	-	648	-	-

本地存储或者存储区域网络(SAN)

对许多企业来说，如何在一个服务器上支持非常高数量的驱动器，是一个大问题。首先，他们必须考虑如何管理超过设计存储容量的数据库，或者是不得不将某些特殊的数据库放在不同的服务器上。

这里有三个基本选项:第一个就是用很多个内部磁盘来支持存储，以此来平衡服务器。第二个就是服务器内部只有几个磁盘，然后补充本地附加的磁盘阵列。第三个就是一个服务器具有很少几个内部磁盘，然后连接到存储区域网络(SAN)。

对于本地附加存储的管理要复杂得多，因为它是分布的，与SAN不同的是，SAN是一个集中式的存储，添加新的存储到服务器上是一个简单的图形化的点击式的过程。然而，本地存储的性能会好一点，因为只有一个服务器来平衡这些磁盘驱动，而SAN有5到10个服务器来访问同一个驱动器，可能会引起冲突。SAN针对这个性能问题的答案是用大量的缓存，而不是从磁盘访问数据。

然后，这里就是一个鸡蛋和篮子的比喻:一个服务器，具有专用的存储，一个I/O问题只会影响到一个服务器，但是在SAN上同样的一个问题就会潜在地影响许多个服务器。当SAN需要升级的时候，这也是向前的一步;所有用来平衡SAN的存储的服务器都需要被关闭。当升级单个的本地存储的服务器的时候，暂停服务时间只会影响到那些需要升级的服务器，而不是所有的服务器。管理和性能之间需要有个平衡点。

结论

硬件是SQL Server获得高性能的基础，这不是一个秘密，但是平台仍然需要进行正确的后续设计和开发，来获得很长一端时间所需要的性能。虽然很多硬件革新唾手可得，但是时刻记住在开发阶段的松懈不是其中的一个选择。你必须安装正确的SQL Server硬件，并且在应用程序的生命周期中随手保持优化到最佳的实践方案以获得高性能。祝你好运!

作者简介:Jeremy Kadlec 是Edgewood Solutions公司的首席数据库工程师。Edgewood Solutions是一家提供针对微软的SQL Server的专业服务和产品解决方案的技术服务公司。Jeremy撰写了大量的文章，并且在最初的SQL Server用户群和本地的SQL PASS上频繁发表文章。Jeremy还是SearchSQLServer.com的性能调整专家。