一步步教你合并你的SQL Server数据库(2)

　　要进行一次成功的企业范围内的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来捕捉和重现代表性的负载，并监控合并解决方案。

　　合并团队还应该划分特定的组，以简化监控合并解决方案。

　　一旦合并团队的成员理解了他们每个任务，并且为合并做好了准备，那么下一个步骤就是分析。