【IT168 服务器学院】步骤指南：如何合并SQL Server
计划执行SQL Server的合并是一项巨大的任务。你可以通过将其分解成独立的组件来简化这个项目，如下面的步骤指南所示：
这篇信息是从我们最初的专家电子书《Planning your SQL Server consolidation》中的第二章“Consolidate SQL Servers for availability, scalability and cost savings”中摘录出来的。这章内容解释了有关合并的5个步骤，以及其它关键的合并考虑。
|
|
Hilary Cotter
Hilary Cotter在IT这一行业已经超过了20年，他是一名网络和数据库顾问。微软在2001年首先授予了Cotter微软SQL Server MVP荣誉。Cotter在多伦多大学得到了机械工程专业的应用科学学士学位，然后在卡尔加里大学学习经济，以及伯克利学院学习计算机科学。他编写了一本有关SQL Server事务复制的书籍，现在正在撰写的是一本有关合并复制和微软搜索技术的书籍。
步骤1：创建SQL Server合并方法学
要进行一次成功的企业范围内的SQL Server合并，你必须首先为你的合并团队和客户,以及用户数据库的业务拥有者定义合并目标。这些目标根据你的合并方式是互不相同的：在一个虚拟的机器上进行合并，堆砌SQL Server环境，和使用存储区域网络（SAN），等。
合并团队要在事先与客户探讨实际的服务级别协议（SLA）是至关重要的。这些SLA不仅仅会为可用性、支持、更改控制，以及监控，还有性能都提供期望值。一个设置了可支持的期望值的SLA在构建合并努力信心方面还有很长的一段路需要走。
任务关键的应用程序应该被标识出来。他们的SLA将会比其它的SLA更严厉，要么要求这些应用程序不被合并和，要么进行仔细的计划来确保SLA能够在合并的环境中满足或者超越。标准应该被应用，那些应用程序也应该在合并团队的所有和控制之下拿出来。
另外一个需要事先协商SLA的原因就是避免范围的蔓延，如果蔓延了的话，你的合并团队就不得不解决那些意料之外的性能问题以及增强的功能性。
你的团队在实行SLA的时候必须考虑各种各样的场景。例如，一些人可能发现在识别数据库的时候，应用程序性能很糟糕，而这些数据库对于合并来说是个不错的选择。理想的客户应该应要求把这些应用程序回炉进行优化。如果你的团队选择了优化，那么你就需要负担起未来事件里面出现的任何性能问题或者bug。英名的选择就是仅仅识别并返回这些数据库给业务拥有者，并且在SLA里面详细说明这个行为。
如果业务单元是不愿意，或者不能被要求回炉和优化这些SQL Server们，那么把它们移动到你的数据中心，并且尽可能地加强标准，但是不要用另外一个SQL Server合并这些数据库。合并一个性能糟糕的用户数据库可能会降低SQL Server上所有其它用户数据库的性能。
一旦SLA商议妥当，你的合并团队就应该创建一个日程表，把整个企业范围内的计划划分为多个阶段。
第一阶段应该包括哪些具有最不复杂的用户数据库的部分。这样就给了团队成员一个在遇到更加困难的合并情况之前的实践机会。这个阶段方式还应该教会他们，在数据库负载随着时间发生变化的时候，能够更加游刃有余的在SQL Server之间处理用户数据库。例如，当某一个特定的用户数据库增长的时候，他可能会使得合并的SQL Server上所有的用户数据库的性能都下降。另一方面，当某个应用程序的生命周期到达末尾的时候，那个用户数据库需要的资源也会衰落，然后使移动到一个较低马力的服务器上是可行的。
测试脚本的创建目的应该是帮助测量现有的SQL Server应用程序。它可以让团队成员熟悉性能监控和SQL Server Profiler来捕捉和重现代表性的负载，并监控合并解决方案。
合并团队还应该划分特定的组，以简化监控合并解决方案。
一旦合并团队的成员理解了他们每个任务，并且为合并做好了准备，那么下一个步骤就是分析。
步骤2：分析合并备选数据库和服务器
在分析阶段，合并团队应该观察每个SQL Server和他的用户数据库来决定他们各自的性能特点，资源需求，依赖性，以及如何移植它们。在合并环境中，多用户数据库应该根据性能特点、内部和外部的依赖性，SLA，以及版本，被分组或者堆叠在一起。他们将会划分为单个的SQL Server，也被叫做SQL Server堆。要针对合并来分析候选的SQL Server和他们的用户数据库，有三个部分。
1、分析数据访问和利用模式，然后分析用户数据库安装的SQL Server环境
2、在合并环境中复制这些模式，那么用户感觉就会一致，即使不会更好的话。
3、调查其它任何用户数据库之外的合并机会。你能将多个SQL Server合并到一个簇中去吗？你能合并存储(磁盘阵列和存储区域网络)吗？要合并例如SharePoint Team Services和 Windows SharePoint Services这样的应用程序有意义吗，哪一个倾向于快速增长？
让我们看一下分析阶段中的某个详细方面吧。
你必须对于考虑进行合并的用户数据库的利用和访问模式有一个很好的理解。例如，一些利用和访问模式是周期性的。一些数据库是24*7小时的提供访问，而其它的一些有可能旨在周一到周五的早上9点到晚上5点。基于每小时、每天、每周、每月、每季度，或者每年的数据库体验峰值时间。
在业务时间内，SharePoint数据库通常具有一致的使用方法，然而薪资数据库却在每周、每两周，或者每俩月一次的发薪周期经历更高的负载。记账数据库也可能会每季度或者每年经历一次负载的高峰。要理解每个负载的周期性本质是非常重要的，这样的话你就可以捕捉具有代表性的负载。然后，你可以在你的测试环境中使用这个负载，并根据高峰负载时间来进行计划，而不需要破坏你的经过合并的SQL Server堆中的其它用户数据库。
在判断数据访问和数据使用模式的过程中，对客户的交流还有一段很长的道路。他们不仅需要辨别使用峰值时间，还需要负载峰值时间（例如，当批处理任务将极端的负载加载到SQL Server上），以及帮助估计可预期的增长。
运行基本的正常检查，例如DBCC CheckAlloc，还有检查SQL Server的错误日至，调试堆的逻辑目录，以及异常的应用程序日至，其中的任何一点都可能会指向问题或者存在问题的使用模式。有了这个认识之后，你的合并团队就能够使用SQL Profiler捕捉有代表性的负载，并且在合并解决方案中作为测试来重现它。然后，他们可以在测试解决方案中，从多个不同的SQL Server上同步在重现负载。在原始的系统中捕捉性能参数，然后与在测试的合并SQL Server上获得的参数相比较，来量化性能的改善情况。第三章将会详细讨论那些需要收集的特定的性能计数器。
许多的依赖性斗可能会使得用户数据库成为合并的糟糕的候选人。这些依赖性要在事先进行辨认出是至关重要的，这样你就可以为它们进行计划，或者甚至是在它们上面工作。
步骤3：测试你的SQL Server合并
一旦你完成了对用户数据库的分析，你必须仔细决定要把哪个用户数据库放在堆栈中。
以下的几种情况将会强制你在不同的实例中进行合并：
- 用户数据库具有不一致的名字冲突。
- 用户数据库中的tempdb使用频繁。
- 来自没有进过标准整理的SQL Server的用户数据库。
我将在本章稍后的内容中给出更加详细的清单列表，表名为“在单个实例及多个实例中合并的对比”
有些情况下，你被强迫在运行以前版本的SQL Server上进行合并，通常称为版本堆(version stack)。其中包括版本依赖性或者SQL 全文本搜索的过量使用等情况。
一旦你决定了将哪个数据库放置在堆中，要仔细的检查数据访问和数据使用模式。这些将会帮助你将用户数据库在合并的SQL Server上进行分组，以提供优化的性能。例如，将具有较高负载的单个的用户数据库放在不同的堆中，然后将负载较低的用户数据库添加到这些堆中，并且观察整体的性能。通过这种方式调整之后，你就会在硬件资源有限的情况下收到较优的吞吐量。
仔细地对你在默认的SQL Server和数据库设置上进行的任何更改记录文档。
步骤4：在产品环境中部署合并数据库
在你决定了用户数据库在合并的SQL Server堆上的最优位置之后，将用户数据库从他们当前的产品环境中一个接着一个地移动到新的合并拓扑中去。在你移动了每个用户数据库之后，监控对性能产生的影响来确保合并系统仍然保持了引入这些新的用户数据库之前的稳定性。
这里有很多种方式将用户数据库移动到合并环境中去。一种比较流行的方法就是将每个数据库从它当前的环境中分离出来，拷贝到合并环境中去，然后把它们附加上去。
然而，复制将会妨碍你将发布的数据库分离开来。如果你的数据库是发布的，那么就最好不要复制，移动数据库，然后重新构建发布和订阅。在全文本分类的SQL Server 2000数据库上， 你不得不手工拷贝数据库和全文本的分类到合并环境中，正如微软技术支持描述的一样。也有可能使用拷贝数据库想到，但是它对于不是小型数据库的任何东西都无法升级。
在向业务拥有者开放合并数据库之前，运行预热脚本来确保第一个用户在新的合并环境中的体验不会是一个迟缓的感觉。
步骤5：监控并保持合并SQL Server 数据库的稳定
即使是经过了最仔细的分析、测试和基准测量，你还是可能会在合并环境中发现惊喜。在合并过程的早期阶段，项目团队就对于通过监控和调整合并的SQL Server上面的用户数据库提供优化的性能很熟悉了。
一旦合并SQL Server成为产品，这些监控和调整技巧就会变得毫无价值。此时要调整一些较大的用户数据库，特别是当它们拥有外部依赖（例如复制或者全文本搜索）的时候，就会困难重重了，一些较小的可以轻松移动的用户数据库需要具有正当的理由，你还需要一个维护窗口。
监控应该允许你在很大程度上具有管理每个合并SQL Server方面的前摄性，特别是在寻找储运损耗和性能问题的时候。许多商业的监控程序在这一点上都很理想，例如BMC 软件公司的Patrol,微软的 MOM ，以及Quest软件公司的Spotlight等。
监控的目标不仅仅是对于问题具有前摄性，还要交付一个稳定的，统一的SQL Server解决方案，能够为所有的用户数据库，还有更重要的是，能够满足或者查阅SLA协商内容的解决方案提供性能和高可用性。一个稳定的环境被定义为一个能够充分服务所有负载，而不会带来一丁点的性能下降的环境；从监控的角度来说，它就是一个安静的服务器，不会产生任何性能警报。
一旦合并SQL Server的第一个阶段是稳定的，移动第二阶段的数据库到下一个合并群中去。在第一阶段接受的教训在随后的各个阶段里面还会具有促进作用。
以上的贴士摘自我们最初的专家电子书《Planning your SQL Server consolidation》中的第二章“Consolidate SQL Servers for availability, scalability and cost savings”。本章内容解释了合并的6个步骤，以及其它有关合并的关键考虑。
