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

　　步骤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上获得的参数相比较，来量化性能的改善情况。第三章将会详细讨论那些需要收集的特定的性能计数器。

　　许多的依赖性斗可能会使得用户数据库成为合并的糟糕的候选人。这些依赖性要在事先进行辨认出是至关重要的，这样你就可以为它们进行计划，或者甚至是在它们上面工作。