在决定哪个选项对客户有意义，考虑方法多么有效以及付出多大努力使它就绪是十分重要的。首先，你应先实现客户端SQL Server的可用性目标和满足服务级别协议(SLA)的要求。例如，您的客户寻找99.99%的正常运行时间?他们只是需要保护数据库还是整个SQL Server实例?他们是需要自动还是手动故障转移功能呢?他们需要预防一个站点离线吗?每一项要求都决定选择哪一个解决方案。

　　显然，故障转移集群对于减少系统停机时间并为一个站点内SQL Server的整个实例提供更高的应用可用性来说是最好的选择，但是，一个故障转移集群并不预防磁盘故障，也不需要一个SAN。如果在SQL Server实例中的一个或多个数据库无论有无自动故障转移都要提供高可用性，数据库镜像将是一个极好的选择。

　　不同于故障转移集群，数据库镜像不需要一个SAN而磁盘也不是一个单点故障，数据被存储两次，一次在主数据库而另一次在镜像数据库。如果客户试图以最少的成本和多个备用数据库实现可用性或灾难恢复解决方案，而备用恢复数据库可以跨一个或多个地理数据中心，则日志传送是完美的。复制可用于从一个SQL Server实例分发数据到另一个实例或用于两个相同的只读数据库之间的负载平衡。

　　当涉及到实现时，SQL Server故障转移集群需要精通Windows故障转移集群和配置基于Windows故障转移集群模式的共享存储系统(SAN 与/或NAS)。

　　另一方面，日志传送配置相对容易。通过使用SQL Server 2008向导，数小时内可实现日志传送，而根据场景其他选项则需要几个星期来实施。

　　在两个物理站点间搭建数据库镜像需要花费时间来实现，尤其是如果有大量的数据需要同步和两个站点间带宽缓慢或有过多的延迟。

　　点对点事务复制可能是最复杂的实施选项-特别是当它归结为故障排除或管理。你必须理解诸如发布者、分发者、订阅者和条款这些复制术语，也必须理解如何在每个SQL Server实例中实现这些角色。

　　最后，注意你肯定是最希望合并SQL Server高可用性选项来最大程度的保护物理SQL Server数据库或SQL Server实例。它通常在一个站点内使用故障转移集群，然后在其上添加镜像数据库以满足另一个物理站点的灾难恢复要求。显然，没有一种解决方案能够满足每一位客户的SQL Server高可用性要求。但是，通过了解替代品和整合技术则可能满足他们的高可用性要求。