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

核心提示： 在判断数据访问和数据使用模式的过程中，对客户的交流还有一段很长的道路，一步步教你合并你的SQL Server数据库(4)，他们不仅需要辨别使用峰值时间，还需要负载峰值时间（例如，你被强迫在运行以前版本的SQL Server上进行合并，通常称为版本堆(version stack)，当批处理任

在判断数据访问和数据使用模式的过程中，对客户的交流还有一段很长的道路。他们不仅需要辨别使用峰值时间，还需要负载峰值时间（例如，当批处理任务将极端的负载加载到SQL Server上），以及帮助估计可预期的增长。

运行基本的正常检查，例如DBCC CheckAlloc，还有检查SQL Server的错误日至，调试堆的逻辑目录，以及异常的应用程序日至，其中的任何一点都可能会指向问题或者存在问题的使用模式。有了这个认识之后，你的合并团队就能够使用SQL Profiler捕捉有代表性的负载，并且在合并解决方案中作为测试来重现它。然后，他们可以在测试解决方案中，从多个不同的SQL Server上同步在重现负载。在原始的系统中捕捉性能参数，然后与在测试的合并SQL Server上获得的参数相比较，来量化性能的改善情况。第三章将会详细讨论那些需要收集的特定的性能计数器。

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

步骤3：测试你的SQL Server合并

一旦你完成了对用户数据库的分析，你必须仔细决定要把哪个用户数据库放在堆栈中。

以下的几种情况将会强制你在不同的实例中进行合并：

用户数据库具有不一致的名字冲突。

用户数据库中的tempdb使用频繁。

来自没有进过标准整理的SQL Server的用户数据库。

我将在本章稍后的内容中给出更加详细的清单列表，表名为“在单个实例及多个实例中合并的对比”

有些情况下，你被强迫在运行以前版本的SQL Server上进行合并，通常称为版本堆(version stack)。其中包括版本依赖性或者SQL 全文本搜索的过量使用等情况。