在现在的IT界里，整合(Consolidation)是一个很大的话题，它已经成为IT界少花钱多办事的代名词。在SQL Server里，有一些不同的方法可以处理整合。

• 　　从多个实例移动多个数据库(无论是在同一个服务器还是多个服务器上)到一个单一服务器的单一实例上。
  　　
• 从多个实例移动多个数据库到单一的物理服务器，但是每一个实例保持不变。
  　　
• 移动多个物理服务器到单一的物理服务器上，通过Microsoft Hyper-V和VMware vSphere管理程序虚拟物理服务器。
  　　

    但是整合并不总是正确的解决方案，有些时候，整合不仅关乎到你何时想去尝试，关键是你对想使用的每一种情况的掌握程度以及如何作出这个决定。

　　最常见的整合操作是移动你的SQL Server数据库，到具有代表性的在一个新的、大的和更强劲的SQL Server实例上来，。这种方法的开销最低，因为你只要运行一个单一的SQL Server。但是因为你有且仅有一个SQL Server，所有的数据库都运行在一个总的共享环境,他们也不得不共享物理资源诸如内存和CPU。

　　当你确定共享这些资源没有问题时你就可以计划去整合数据库了。当你将所有的数据库放到一个单一的SQL Server实例中时，你必须控制缓存大小和CPU可用性，因为如果一个数据库开始使用所有这些资源，它将会使这个实例上的其他数据库因这些资源匮乏而运行困难。

　　过程缓存：当你的所有数据库运行在同一个SQL Server实例上时，它们不得不共享资源，比如说过程缓存，因为在实例上还没有办法控制一个单一的数据库过程缓存的多少。如果你有一个都是动态SQL的应用程序和有几万或几十万的对象在过程缓存里，数据库整合就不是好的选择，因为这将会造成其他数据库不得不执行大量的重新编译。

　　一种方法是检查你是否有计划缓存问题，看看你计划缓存一段时间的大小和它们能达到多大程度。看一下你编译和重新编译的数量。举个例子，考虑整合两个SQL Server 2008服务器时，该计划缓存的数据显示在表1.1。

　　表1.1: 过程缓存

　　从上面这些数据我们可以看到，在整合这两个服务器时你将需要有至少9.1GB的过程缓存。但是基于这个方法，一台配有64GB的SQL Server 2008来计算可用的过程高速缓存的数量，其中60GB分配给SQL Server 2008，仅有8.6GB的过程高速缓存。这样的话，过程缓存大小不合适，SQL编译的数量将会增大到一定的程度，但是系统的整体CPU负载是足够的低，能够应付SQL Server生成的重新编译所增加的CPU的负载。

　　CPU负载：你应该确保的下一件事情是新的SQL Server能够处理两个实例承担的CPU负载，在表1.1中，在SQL1上CPU负载是25%，同时SQL2的是3%。结合这些数字，你需要有一个28%负荷的CPU负载，是一个可以接受的CPU负载。

　　缓冲区高速缓存：你需要检查的下一个指标是缓冲区高速缓存。像过程告诉缓存一样，你也无法控制每一个数据库所使用的缓冲区缓存的大小。SQL Server管理着单一的大的缓冲区缓存并为每一个需要使用的对象分配空间。在图1.2中，SQL2服务器的缓冲区高速缓存小到只有51.6MB。当整合这两个服务器到SQL1时没有问题，SQL1服务器整合SQL2在缓冲区缓存命中率和页面寿命几乎没有减少。

　　表1.2: 合并SQL Server

　　如果你审视一下想要整合的SQL Server的这些指标，你会找到这些数值，不能孤立这些彼此相关的数据库，接着你就可以准备进行整合这些数据库到单一的SQL Server实例上来。但是如果你想在每一个能控制的实例上有更多的缓冲区缓存和过程缓存大小的控制权，那么在同一个SQL Server服务器上整合多个实例可能是你的最佳选择。