毫无疑问，许多电子商务网站都经历过假期的高访问量。例如，1-800-Flowers.com公司(1-800-Flowers.com网站)就在情人节、母亲节、圣诞节、复活节、感恩节、秘书节，以及团队感谢周那一天遇到了剧增的订单。还有其他大多数的在线零售商也都经历过从感恩节一直持续到12月26日的订货高峰期。

　　那么你从这些公司身上可以了解到，他们需要保持高可用性，快速运行的数据库。下面我将按照以下的总体概念和清单，讨论几种你可以应对高峰来临的方式。

可用性方法

　　集群

　　高可用性通常包含了集群。当你需要较高级别的正常运转时间的时候，你需要对SQL Server进行集群，由以下几部分组成，有几个节点集合在一起形成的一个单个实例的集群，他们在面对客户的时候表现为一个单个的节点。如果集群中的一个节点掉线了(由于SQL Server错误，硬件错误或者维护)，其他的节点将会自动接过它的工作负载。客户根本不需要重新连接到其他的节点上，因为这些节点都连接到一个虚拟的服务器上，它漂浮在所有活动节点之上。

　　集权提供了对硬件和软件错误的自动错误容忍，但是它通常不会提供对本地错误的容忍(例如，放置集群的大厦或者房间内的电源坏了)。注意力应该放在消除单个点的失败，例如冗余电源供应或者备用的发电机能源。

　　地理集群和负载均衡

　　其他的高可用性方法包括地理集群，集群节点分布在不同的位置上;或者地理负载均衡，IP地址客户可以在主要的数据中心和灾难恢复网站之间交换。

　　EMC公司，日立数据系统公司，还有现在的收购了赛门铁克的Veritas软件公司都提供了硬件的数据镜像，它可以提供持续的复制，这样灾难恢复网站就可以保证拥有你的数据的实时拷贝。硬件数据镜像工具可以用于连接地理IP解决方案，为灾难恢复网站提供自动化的错误恢复。

　　缩小规模

　　你还可以利用缩小规模的方法来将你的数据分散到多个工作机器上。不再让1000个用户都连接到一个SQL Server上，而是让10个SQL Server上分别连接100个用户。你的数据访问模式必须要与此相匹配，客户连接到哪个SQL Server都没关系，或者你必须要激活粘性会话。通过这种方式，每个客户在其会话长度内都连接到一个单个的SQL Server上。

　　例如，如果你的联盟中有10个SQL Server提供分类信息，并且在这10个SQL Server之间的数据也是相同的，那么客户连接到哪个SQL Server上，然后又重新连接到哪个SQL Server上，这都没有关系。SQL Server 2005中的点对点应用程序就被恰好是为这种类型的缩小规模设计的。

　　注意，SQL Server不能自动将负载分散给其他的SQL Server。你需要均衡网络负载，一边将负载分布到多个网络服务器上，并且联盟中的每个网络服务器上都安装一个或者多个SQL Server。

　　理解工作流

　　电子商务公司整年都在准备他们的旺季销售高峰。系统架构师研究工作流，以便于理解事务中的哪一个处理是必需的，哪一个可以是批量处理的，哪一个是可以从其他机器的并行处理中受益的。

　　考虑一下一般的下订单的操作。输入信用卡并且在网页上经过验证，确保数字以某个序列开始，并且满足一定的长度。这个步骤可以在浏览器上进行，这样就可以不用占用网络服务器的处理器周期。信用卡交费通常是没有经过授权的，因为网络服务呼叫会在这一点上慢下来，导致整体的可测量性解决方案等级下降。如果不需要网络服务呼叫认证每一个信用卡事务，那么电子商务网站就可以支持好几千个，甚至更多的页面。信用卡将会在稍后大批处理过程中进行处理。

　　正如上面的例子所演示等，通过仔细查看工作流，系统架构师辨认出可以异步执行的处理，那么整体的可测量性方案等级将会上升。

　　负载测试

　　具有广泛代表意义的负载测试是在负责复制产品机器的机器上完成的。这些负载测试都是经过严格分析的，能够标识并消除瓶颈。当瓶颈消除之后，负载测试将会重复进行，以标识并消除新的瓶颈。只要资源允许，这个迭代的过程将会持续下去。

　　预备

　　通常，所有的开发都会在电子商务网站迎接新的销售旺季之前几个星期结束，然后进入预备模式，不会再对产品机器进行任何的更改。自动的批处理管理也暂停了，只有在定位真正的攻击的时候才会使用批处理。在确定成为产品之前，这些紧急批处理的影响会在QA环境中进行评估。

清单“准备工作负载高峰”

　　作为数据库管理员，你会采取什么行动来让SQL Server做好对负载高峰的准备?以下是一些可遵循的步骤。

　　清单:让SQL Server为工作负载高峰做好准备

　　维护

　　如果你根本没有任何维护窗口:

　　?为尽可能多的不必要数据进行存档

　　?运行dbreindex来更新你的索引，并重新建立填充因子。

　　在朝大型的数据库上，你也许不能这么奢侈。如果情况确实如此，那么采取以下步骤:

　　关闭自动更新统计

　　当表被修改的内容达到20%的极限时，SQL Server在默认情况下自动为表更新统计数据。要关闭自动更新/创建统计，输入以下命令:

　　sp_dboption ,'auto create statistics', off

　　sp_dboption ,'auto update statistics', off

　　关闭自动压缩

　　事务日志或者数据库文件的压缩都会引起性能的下降。请按照SQL Server MVP Tibor Karaszi 在《压缩数据库或者事务日志文件所产生的后果》中给出的建议。

　　关闭自动增长

　　关闭自动增长，限制数据库数据文件的最大尺寸。如果让你的数据库必须增加数据库文件或者事务日志文件的尺寸，那么势必会降低性能并使事务串行化。请参考微软相关文章获取更多有关自动增长所产生后果的信息。

　　关闭索引碎片整理和索引优化

　　索引碎片整理是一项在线操作(即，在不锁定表的情况下进行的操作)，它可能引起相当可观的对表和索引的锁，它会降低你的SQL Server整体性能。具有碎片的索引的影响将会在虚拟数据库中最小化;只有当你执行索引扫描的时候才会对索引查找产生负面影响。请参考这篇白皮书来获得更多信息:索引维护操作.

　　维护你的事务日志

　　一个被忽视的事务日志将会拥有大量的虚拟日志文件(VLF)。你可以通过减少虚拟日志文件的数量来获得更好的性能。你可以通过经常的清空事务日志来达到这个目标(例如，每五分钟)。

　　采用快速数据库备份解决方案

　　通过使用第三方的SQL备份产品，减少你的备份对数据库性能的影响。

　　重新编译存储过程

　　重新编译你的存储过程，以确保选择了优化的执行计划。

　　运行预热脚本

　　在你的数据库上运行预热脚本，确保你的查询可以从缓冲中获得最大收益。

　　警惕性能监控

　　你可以通过使用标准模板运行SQL Server Profiler，以此最小化对系统性能的影响。其他供应商提供的各种工具，例如, Imdeca Software Inc. 和 Idera，都可以为你的SQL Server提供窗口来评估你系统的健康程度和性能。许多这样的工具都具有针对你的SQL Server的记忆和处理器印记。Performance Monitor也同样具有，并且它还可以为你的数据库提供一个可替换的窗口。

　　定时批处理任务

　　为你的批处理任务或者DTS包定时，让它们在低负载的时间运行，或者把它们推迟，直到假期的高峰时期过后。

　　总结

　　这里是我们对于你可以提前采用的提高SQL Server解决方案在负载高峰时期的性能的全部预备措施。除了仔细地计划和测试之外，别无他法。我们回顾了一系列的有关可能会导致产品系统在高负载情况下的性能下降的设置的贴士。判断一下哪些贴士可能会为你所用，最有代表性的环境中对它进行测试。