很多企业都需要他们的全部或部分数据高可用，比如说在线购物网站，在线商品数据库必7*24小时在线，否则在竞争激烈的市场环境下，宕机时间就意味着流失客户和收入。

当然，在一个理想的世界中，所有的关键数据都会时刻在线，但在现实世界中，会存在各种各样的原因导致数据库不可用，由于无法预估灾难出现的时间和形式，需要提前采取措施来预防各种突发情况，因此SQL Server提供了多种高可用性技术，这些技术主要包括：集群、复制、镜像、日志传送、AlwaysOn可用性组以及其它诸如文件组备份还原、在线重建索引等单实例的高可用性技术。使用何种高可用性技术并不是随意挑一个熟悉技术直接使用，而是要基于业务和技术综合考虑。因为没有一项单独的技术可以实现所有的功能。如何根据具体的业务和预算采用这些技术，就是所谓的高可用性策略。

• RTO（Recovery Time Objective）-也就是恢复时间目标，意味着允许多少宕机时间，通常用几个9表示，比如说99.999%的可用性意味着每年的宕机时间不超过5分钟、99.99%的可用性意味着每年的宕机时间不超过52.5分钟、99.9%的可用性意味着每年的宕机时间不超过8.75小时。值得注意的是，RTO的计算方法要考虑系统是24*365，还是仅仅是上午6点到下午9点等。您还需要注意是否维护窗口的时间在算在宕机时间之内，如果允许在维护窗口时间进行数据库维护和打补丁，则更容易实现更高的可用性。

• RPO（Recovery Point Objective）-也就是恢复点目标，意味着允许多少数据损失。通常只要做好备份，可以比较容易的实现零数据损失。但当灾难发生时，取决于数据库损坏的程度，从备份恢复数据所需要的时间会导致数据库不可用，这会影响RTO的实现。一个早期比较著名的例子是某欧美的银行系统，只考虑的RPO，系统里只存在了完整备份和日志备份，每3个月一次完整备份，每15分钟一次日志备份，当灾难发生时，只能够通过完整备份和日志备份来恢复数据，因此虽然没有数据丢失，但由于恢复数据花了整整两天时间，造成银行系统2天时间不可用，因此流失了大量客户。另外一个相反的例子是国内某在线视频网站，使用SQL Server作为后端关系数据库，前端使用了No-SQL，定期将No-SQL的数据导入关系数据库作为备份，当灾难发生时最多允许丢失一天的数据，但是要保证高可用性。

预算 –RTO和RPO统称为SLA（服务水平协议），设计高可用性策略时，要根据业务来衡量满足何种程度的SLA，这要取决于预算以及衡量不同SLA在故障时所造成的损失。SLA并不是越高越好，而是要基于业务需求，通常来说，在有限的预算之下很难实现很高的SLA，并且即使通过复杂的架构实现较高的SLA，复杂的架构也意味着高运维成本，因此需要在预算范围之内选择合适的技术来满足SLA。

SQL Server中所支持的高可用性功能与版本息息相关，企业版支持所有的高可用性功能，这些功能包括：

• l 故障转移集群
• l 数据库镜像
• l 事务日志传送
• l 数据库快照
• l AlwaysOn可用性组
• l 热加载内存
• l 在线索引操作
• l 数据库部分在线（只还原了主文件组或主文件组和额外的NDF文件）

故障转移集群为整个SQL Server实例提供高可用性支持，这意味着在集群上某个节点的SQL Server实例发生了硬件错误、操作系统错误等会故障转移到该集群上的其它节点。通过多个服务器（节点）共享一个或多个磁盘来实现高可用性，故障转移集群在网络中出现的方式就像单台计算机一样，但是具有高可用特性。值得注意的是，由于故障转移集群是基于共享磁盘，因此会存在磁盘单点故障，因此需要在磁盘层面部署SAN复制等额外的保护措施。常见的故障转移集群是双节点的故障转移集群，包括主主节点和主从节点。

事务日志传送提供了数据库级别的高可用性保护。日志传送可用来维护相应生产数据库（称为“主数据库”）的一个或多个备用数据库（称为“辅助数据库”）。发生故障转移之前，必须通过手动应用全部未还原的日志备份来完全更新辅助数据库。日志传送具有支持多个备用数据库的灵活性。如果需要多个备用数据库，可以单独使用日志传送或将其作为数据库镜像的补充。当这些解决方案一起使用时，当前数据库镜像配置的主体数据库同时也是当前日志传送配置的主数据库。
事务日志传送可用于做冷备份和暖备份的方式。

数据库镜像实际上是个软件解决方案，同样提供了数据库级别的保护，可提供几乎是瞬时的故障转移，以提高数据库的可用性。数据库镜像可以用来维护相应生产数据库（称为“主体数据库”）的单个备用数据库（或“镜像数据库”）。

因为镜像数据库一直处于还原状态，但并不会恢复数据库，因此无法直接访问镜像数据库。但是，为了用于报表等只读的负载，可创建镜像数据库的数据库快照来间接地使用镜像数据库。数据库快照为客户端提供了快照创建时对数据库中数据的只读访问。每个数据库镜像配置都涉及包含主体数据库的“主体服务器”，并且还涉及包含镜像数据库的镜像服务器。镜像服务器不断地使镜像数据库随主体数据库一起更新。

数据库镜像在高安全性模式下以同步操作运行，或在高性能模式下以异步操作运行。在高性能模式下，事务不需要等待镜像服务器将日志写入磁盘便可提交，这样可较大程度地提高性能。在高安全性模式下，已提交的事务将由伙伴双方提交，但会延长事务滞后时间。数据库镜像的最简单配置仅涉及主体服务器和镜像服务器。在该配置中，如果主体服务器丢失，则该镜像服务器可以用作备用服务器，但可能会造成数据丢失。高安全性模式支持具有自动故障转移功能的备用配置高安全性模式。这种配置涉及到称为“见证服务器”的第三方服务器实例，它能够使镜像服务器用作热备份服务器。从主体数据库至镜像数据库的故障转移通常要用几秒钟的时间。

数据库镜像可用于做暖备份和热备份。

复制严格来说并不算是一个为高可用性设计的功能，但的确可以被应用于高可用性。复制提供了数据库对象级别的保护。复制使用的是发布-订阅模式，即由主服务器（称为发布服务器）向一个或多个辅助服务器或订阅服务器发布数据。复制可在这些服务器间提供实时的可用性和可伸缩性。它支持筛选，以便为订阅服务器提供数据子集，同时还支持分区更新。订阅服务器处于联机状态，并且可用于报表或其他功能，而无需进行查询恢复。SQL Server 提供四种复制类型：快照复制、事务复制、对等复制以及合并复制。

AlwaysOn可用性组是SQL Server 2012推出的新功能。同样提供了数据库级别的保护。它取数据库镜像和故障转移集群之长，使得业务上有关联的数据库作为一个可用性组共同故障转移，该功能还拓展了数据库镜像只能1对1的限制，使得1个主副本可以对应最多4个辅助副本（在SQL Server 2014中，该限制被拓展到8个），其中2个辅助副本可以被作为热备份和主副本实时同步，而另外两个异步辅助副本可以作为暖备份。此外，辅助副本还可以被配置为只读，并可用于承担备份的负载。

正因为如此，数据库镜像在SQL Server 2012中被标记为“过时”。

具体何种版本支持哪些高可用特性，请参阅：http://msdn.microsoft.com/zh-cn/library/cc645993.aspx