SQL HADR多个技术概览和比较

对于企业级用户和关键系统来说，最重要的要求之一就是系统的高度可用性和数据的安全性（High Availability and Disaster Recovery，HADR）。我们先来了解一下HADR的问题空间。HADR有两个目标和衡量方式：

• 保证系统可用
  目标恢复时间（Recovery Time Objective，RTO）：出了故障后把系统恢复正常工作状态所需要的时间。
• 保证数据安全
  目标恢复点（Recovery Point Objective，RPO）：系统数据能恢复到故障前的哪个时间点。换而言之，故障后你能容忍多少数据损失。

故障又主要有两大类别：

• 计划宕机时间
  • 硬件升级
  • 软件补丁（操作系统，应用程序），应用程序升级
  • 维护操作
• 意外宕机时间
  • 无法预料的故障
    • 硬件故障，软件故障，电力中断，数据损坏
    • 站点故障：火灾，地震，洪水
  • 用户或应用程序错误
    • 意外更改，不正确的数据操作

针对不同的可用性要求和故障类别，SQL Server提供多样的HADR技术来满足用户的需要。但怎样从中选择最合适的技术？下面是对SQL可用性技术和功能的一个概览：

• 意外宕机时间
  • SAN/RAID
  • 备份和恢复（Back Up and Restore）
  • 日志传送（Log Shipping）
  • 数据库镜像（Database Mirroring）
  • 故障转移群集（Clustering）复制（Replication）
• 计划宕机时间
  • 轮流升级和打补丁（Upgrade and Patching）
  • 在线操作（Online Operations）
  • 资源管理器（Resource Governor）
  • 数据库快照（Database Snapshot）

SQL Server HADR 技术比较 

这些技术都有自己的特点和要求，用户可根据自已需求，配置，和预算来选择，以满足HADR在目标恢复时间（RTO）和目标恢复点（RPO）的要求。

希望您能通过本文对SQL HADR技术有个大致了解，以后我们会再详细介绍其中的一些技术，谢谢。

SQL Engine部门经理
吴家震

Comments

• Anonymous
  August 07, 2012
  数据库复制的问题，能否解答一下！ 当我执行如下SQL： update table set col='值'  涉及修改的数据量如果超过10万，那么数据库复制同步将变的非常慢。 具体时间大概是1万 10秒  2万30秒 10万1个小时 20万4个小时 100万4天。 不是线性增长而是指数级增长。 我查看了原因，10万数据更新，在复制同步时候是在同一个事务里面，10万事务对应10万个命令，每个命令都产生X锁（在当前数据库和tempdb），而且X锁多了也不升级，最后导致X锁越来越多，越到后面锁匹配越慢，性能越来越差。 微软解决方案之一是通过存储过程提交SQL，再复制两端都执行SQL，这样感觉不是很好，因为我只能控制升级脚本这样做，不能控制程序也这样做。 另外一个解决方案是我自己想出来的，对更新的系统存储过程加上表锁，这样能解决问题，但是需要批量修改微软提供的底层存储过程，感觉不保险。 我觉得微软是不是有一个开关专门设置是否在复制期间开启事务，这样就不会出现大事务造成的N多X锁，导致性能严重下降。求答案！！！！！！