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

核心提示： 另外一个需要事先协商SLA的原因就是避免范围的蔓延，如果蔓延了的话，一步步教你合并你的SQL Server数据库(2)，你的合并团队就不得不解决那些意料之外的性能问题以及增强的功能性，你的团队在实行SLA的时候必须考虑各种各样的场景，测试脚本的创建目的应该是帮助测量现有的SQL Serve

另外一个需要事先协商SLA的原因就是避免范围的蔓延，如果蔓延了的话，你的合并团队就不得不解决那些意料之外的性能问题以及增强的功能性。

你的团队在实行SLA的时候必须考虑各种各样的场景。例如，一些人可能发现在识别数据库的时候，应用程序性能很糟糕，而这些数据库对于合并来说是个不错的选择。理想的客户应该应要求把这些应用程序回炉进行优化。如果你的团队选择了优化，那么你就需要负担起未来事件里面出现的任何性能问题或者bug。英名的选择就是仅仅识别并返回这些数据库给业务拥有者，并且在SLA里面详细说明这个行为。

如果业务单元是不愿意，或者不能被要求回炉和优化这些SQL Server们，那么把它们移动到你的数据中心，并且尽可能地加强标准，但是不要用另外一个SQL Server合并这些数据库。合并一个性能糟糕的用户数据库可能会降低SQL Server上所有其它用户数据库的性能。

一旦SLA商议妥当，你的合并团队就应该创建一个日程表，把整个企业范围内的计划划分为多个阶段。

第一阶段应该包括哪些具有最不复杂的用户数据库的部分。这样就给了团队成员一个在遇到更加困难的合并情况之前的实践机会。这个阶段方式还应该教会他们，在数据库负载随着时间发生变化的时候，能够更加游刃有余的在SQL Server之间处理用户数据库。例如，当某一个特定的用户数据库增长的时候，他可能会使得合并的SQL Server上所有的用户数据库的性能都下降。另一方面，当某个应用程序的生命周期到达末尾的时候，那个用户数据库需要的资源也会衰落，然后使移动到一个较低马力的服务器上是可行的。

测试脚本的创建目的应该是帮助测量现有的SQL Server应用程序。它可以让团队成员熟悉性能监控和SQL Server Profiler来捕捉和重现代表性的负载，并监控合并解决方案。