DAT211SQLServer始终在线技术：选择正确高可用性解决方案SQLServerAlwaysOnTechnologiesChoosing.pptVIP

DAT211: Choosing a High Availability Solution 议程 介绍 SQL Server 的几种满足可用性需求的技术 对可用性的高层次定义 宕机的几种原因 分析 5 种常见的高可用性需求，以及 SQL Server的相应解决方案 SQL Server 高可用性功能的新名称 始终在线技术主要用于支持需要高可用性的核心关键应用 提高有计划宕机期间的可用性 应用，操作系统，硬件升级 系统维护 为意外宕机提供保护和快速恢复 人为出错 系统问题 从数据损坏恢复 自然灾害 SQL Server 2005 企业版提供始终在线技术 微软将会继续投入，在未来 SQL Server 产品中扩展始终在线技术 什么是可用性？ 可用性通常是由明确的或暗含的服务级别协议（SLA）来定义的 例如 当订单能够在一分钟内处理完，那么订单系统就是可用的。可接受的最长宕机时间是每月 5 分钟。 宕机时间 = 不能达到 SLA 的时间 通常 uptime 是被记录下来的 (i.e. 99.993%), 这个并不包括计划内的宕机时间 SLA 应该被用来设计，部署，修改和监控系统 应用程序宕机原因 系统管理 更新安装，索引重建… 逻辑错误 (用户或应用) 错误的数据修改，意外修改… 自然灾害 台风，火灾… 硬件失败 内存，网络，磁盘… 软件失败 Bugs SQL Server 2005 高可用性方案 在线管理 应用场景举例 打补丁或升级 出于系统维护的需要，迁移一个表 部署一个应用程序的新版本 恢复损坏的数据 解决方案 滚动升级和数据库镜像热补丁，日志传送，或者复制 快速升级 在线命令：alter table, index create, index rebuild 在线细粒度恢复 滚动升级分三步 升级镜像，或订阅者 交换角色 数据库镜像 　　故障转移到镜像 日志传送 复制 　　　　　客户端重定向到订阅者 升级原数据库 在线管理 SQL Server 2005 高可用性解决方案 用户或应用程序错误恢复 场景例子 一张表被意外删除 一个应用程序错误的修改了数据 用户未经授权就修改了数据 解决方案：逻辑恢复 及时对系统进行快照 周期性的照数据库快照 用 restore delay/standby 选项将日志传送到另外的站点上 在关键时间点对日志进行标记 使用 diff 工具比较表的当前版本和就的版本 跟踪 DML 命令历史 使用 SQL Trace 或定制的复制 SQL Server 日志传送工作原理 SQL Server 2005 数据库快照工作原理 逻辑恢复用户错误 SQL Server 2005高可用性解决方案 站点灾难保护 场景 地震，火灾，洪水等造成数据中心无法运作 解决方案 数据镜像到从属站点 优化方案 – 允许快速故障转移到从属站点 可以采用日志传送实现额外的站点保护 第三方的 geo-群集 方案实现数据中心存储介质级的冗余 SQL Server 始终在线建议解决方案： /SQL/AlwaysOn 数据库镜像同步模式 数据库镜像配置分为三步 数据库镜像灾难恢复 SQL Server 2005高可用性解决方案 数据库查询横向冗余扩展 场景 在备用服务器上进行接近实时的查询，并且这台服务器也用作灾难恢复 冗余数据库服务器横向扩展以提高查询性能，并且可以用其中任意一台作为灾难恢复服务器 解决方案 事物复制 点对点复制 复制选项 SQL Server 2005高可用性解决方案 高可用系统硬件 场景：最大的系统硬件可靠性 解决方案 Microsoft 群集技术 – 实例故障转移 SQL Server 始终在线建议解决方案 SQL Server 始终在线合作伙伴提供的存储方案都是经过仔细的检查，都符合 Microsoft SQL Server Storage Solution 需求 SQL Server 始终在线技术和合作伙伴的存储方案一起提供高度可用和可靠的点到点方案 SQL Server 始终在线合作伙伴计划的第一阶段主要是存储方案，将来阶段会注重其他的硬件和软件 该计划的合作伙伴 /SQL/AlwaysOn Microsoft 群集技术 本地服务器硬件冗余 使用共享磁盘子系统 整个实体虚拟成一个单元，并作为一个单元故障迁移 可以包括其他非 SQL Server 资源 不直接支持灾难恢复 合作伙伴提供存储级别的复制方案 群集技术可以和数据库镜像，日志传送，或复制一起使用 总体方案 更多信息 SQL Server High Availability Home /sql/technologies/highavailability SQL Server 始终在线计划 /SQL