SQL Server 有很多方法可以实现负载分配。下面列出了一些最常见的方法：

　　复制（Replication）

　　日志传送（Log shipping）

　　数据库镜像（Database mirroring）

　　SSRS（SQL Server Reporting Services）n-tier部署

　　SSAS（SQL Server Analysis Services）服务器部署

　　下面我们详细了解一下每一种方法。

　　复制

　　合并复制

　　合并复制可以更好地利用地域导向资源。换句话说，例如你是供应链系统的一个小卖部，你可能想给某个区域的SQL Server分配负载。你可以利用合并复制，让它每晚上执行一次（间隔几小时最佳）更好来同步中心供应系统服务器上的变更。

　　这类配置是理想状态下的，因为区域系统会整天大量查询或更新，而供应信息可能在更新传递到中心系统之前被更新成百上千次。像这样一个系统会保持网络反应时间最小化，并且降低功能系统的网络负载需求。这个情景中的响应时间是良好的。

　　要记住合并复制对数据库的设计有特殊要求，所以要想成功地合并复制，需要时刻考虑合并复制架构或者对象修改。

　　请同时参考“事务复制”中关于分配数据库或者服务器最优化事项的内容，因为这些内容对合并复制也是同样有意义的。

　　事务复制

　　事务复制可以用来把事务推向二级报表服务器或者分析服务器。这里可以启用双向通信，使得跨SQL Server数据库系统的更新保持低延时。值得注意的是，与使用合并复制相比，使用这种方法更能明显加强网络和相关服务器的能力，因为在进行同步时，所有的DML（Data Manipulation Language ，数据操纵语言）操作都被复制，而不是只复制当前状态。

　　如果采用了这种方法，你可以进一步分配负载量。事务复制要求安装的是分布式数据库（或者服务器），这样它可以控制所有要从发布者向众多订阅者执行复制事务的分配。直到事务被传递到分布式数据库（或者服务器）上，并且事务日志备份之后它才会从发布数据库的事务日志中清除。在大部分事务复制的部署中，分布式数据库（或者服务器）实际上就是发布服务器的一部分。这样会增加发布服务器上的CPU占用，I/O竞争等。

　　一个最佳实践是给分布式数据库创建独立的服务器。在这种配置中，发布者会把需要复制的事务传递到位于分布服务器上的数据库中。一旦传递事务完成了，下一次事务日志dump就可以清理这些事务了。这种做法降低了处理延时引起发布数据库事务日志涨满的风险。它也可以降低发布者服务器上的CPU使用率，I/O占用率和内存加载量——在存在多个订阅者时尤为明显。

　　在事务备份完成时，这里存在事务日志没有被清理的风险。时间长了，发布者的事务日志容易涨满，会导致产品环境中的系统死机。

　　日志传送

　　日志传送（Log shipping）的本质就是把事务日志从源服务器上拿出来，转移到目标系统上，然后把它们自动恢复到接收服务器的数据库（处于恢复模式）中。这种方法的好处是不用分布式数据库（或者服务器）参与，所以对于产品环境的服务器，在处理备份时是没有风险的，因为复制机制可靠。

　　在目标系统上的数据库需要设置为还原模式，但它也可以被设置为备用（standby）模式，允许以只读的方式用于报表统计或者分析用途。对于需要在事务日志恢复期间断开连接的用户来说，这是最安全的方式。否则，你可能会遇到由于事务日志备份积累太快引起的问题。在这个复制方案中，所有的数据库（甚至是备用服务器）都可以根据需要被更新。