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

一步步教你合并你的SQL Server数据库2008-03-14计划执行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、在合并环境中复制这些模式，那么用户感觉就会一致，即使不会更好的话。