数据库镜像

　　数据库镜像可以用于对一个备用服务器镜像事务。在这种情况下，数据库或者备用服务器处于与日志传送方案中很相似的恢复模式。然而，如果你有足够的存储空间，你可以在时间允许的范围内创建一个恢复数据库的快照，创建一个只读副本用于报表统计和分析。记住你只能针对一台备用服务器采用这种方案，而复制方案和日志传送方案支持N个备用服务器。

　　这种方案在那种报表数据只需要每天产生一次快照的情况下效果很理想，但是对于需要实时（或者基本实时）获取报表数据的情况就不合适了。而日志传送在处理事务日志备份时，对于报表数据也会有一定延时，如果系统没在性能上出现阻塞，复制方案提供了近乎实时的解决方案。

　　SSRS n-tier部署

　　对于部署了很多SSRS（SQL Server Reporting Services，SQL Server报表服务）的情况，SSRS被安装在希望运行它的服务器上。这种方法的问题是SSRS会占去大量CPU和内存资源，这取决于报表公式复杂度，报表大小，使用模式等等。结果，SSRS会很快开始与SQL Server主服务竞争CPU和内存资源，最后服务器响应会越来越迟缓。

　　SSRS可以被安装在任何独立于SQL Server实例的服务器上，你可以把SQL Server实例统一部署在中心服务器上。SSRS需要元数据数据库才能运行，但是它们可以被设置在任何独立于SSRS服务本身的服务器上。

　　也就是说，服务器1可能运行着SSRS元数据数据库，它是一个统一的SQL Server，而服务器2可能是一个统一的SQL Server，而且有一些SSRS报表的目标数据。服务器3可能是一个SSRS服务箱，没有虚拟存储——但是CPU或者RAM充足——它会与服务器1交互自己的元数据，与服务器2交互获取报表数据并运行。

　　SSAS服务器场部署

　　SSAS（SQL Server Analysis Services，SQL Server分析服务）服务器对CPU和内存的需求可能比SSRS更甚，这取决于当前存在的活动。SSAS可被安装到处于服务器配置负载均衡下的多个服务器上。

　　采用具有丰富并可靠特性集的第三方负载均衡解决方案是可行的。在微软公司的解决方案中，网络负载均衡特性是Windows Server操作系统的一部分，它通常接受混合评审。一旦网络负载均衡被创建，接收到的所有请求会被在服务器场中的所有服务器之间平衡。这样就把处理过程分散开了，而且为服务器故障的情况提供了优秀的冗余方案。它也为满足负载增加提供了良好的可扩展性。

　　在这种配置下，集群中的一个节点与另一个节点之间的性能是不同的，因为每一个节点都有自己独立的缓存。

　　SQL Server可以以很多种不同的方式横向扩容，我这里也只是对这个话题进行了简单的探讨。在针对特定的商业问题考虑SQL Server解决方案时，一定要考虑一下上面列出来的所有方法以及 SQL Server Service Broker（SQL Server的特性）。

　　你实际情况中的特殊业务问题和工具决定了在当前情况下你对可扩展性有什么样的需求。要记住，在许多情况下，你会需要使用这些技术中的不只一种，所以不必害怕混合搭配使用。最后，请对其它的负载均衡方法（包括你选择的网络负载均衡NLB）持开放的态度。