Oracle Data Guard 以最低的成本实现
最高的数据保护
Ashish Ray 首席产品经理
高可用性与灾难恢复
甲骨文公司
议程
HA / DR 挑战
Data Guard 结构与特性
Data Guard 10g 的新特性
最高可用性结构
Data Guard 案例研究及其优点
停机造成的损失
信用卡销售验证服务：每小时 2,600,000 美元
在线拍卖：每小时 225,000 美元
旅店预约系统：每小时 100,000 美元
制造工厂：如果有 4 个 FAB，那么每个 FAB 厂每小时损失 25,000 美元
收入
财务绩效
生产效率
名誉受损
其他损失……
造成停机的原因
系统 故障
数据 故障
系统 变更
数据 变更
意外 停机
计划 停机
存储器故障
人为错误
毁坏
站点故障
Oracle 的集成高可用性解决方案
系统 故障
数据 故障
系统 变更
数据 变更
意外 停机
计划 停机
真正应用集群
自动存储管理 闪回 RMAN 与快速恢复区 Data Guard
联机重新配置 滚动升级
联机重定义
Oracle 的集成高可用性解决方案
系统 故障
数据 故障
系统 变更
数据 变更
意外 停机
计划 停机
真正应用集群
自动存储管理 闪回 RMAN 与快速恢复区 Data Guard
在线重新配置 滚动升级
在线重定义
议程
HA / DR 挑战
Data Guard 结构与特性
Data Guard 10g 的新特性
最高可用性结构
Data Guard 案例研究及其优点
什么是 Oracle Data Guard？
Oracle 为 Oracle 数据提供的灾难恢复解决方案
Oracle 数据库企业版 (EE) 的特性
自动创建和维护生产数据库（或主数据库）的一个或多个事务一致的副本（备用数据库）
如果主数据库（因灾难、维护）不可用，那么可以激活一个备用数据库并使之承担主数据库的角色
要求主服务器和备用服务器上的 Oracle 数据库和操作系统的版本相同
Oracle Data Guard 核心
数据故障与站点灾难：
此外还解决了人为错误和计划维护的问题
数据保护
数据可用性
数据恢复
数据是企业的核心资产！
三者都很重要！
Oracle Data Guard 结构
网络
Broker
生产数据库
逻辑备用数据库
可用于
报表操作
SQL 应用
将重做转换成 SQL
额外的索引
和物化视图
物理备用数据库
备份
重做应用
同步或异步
重做传输
Data Guard 流程结构 (9i)
FAL
Oracle 网络
主数据库
事务
物理/逻辑
备用数据库
备份/报表
LGWR
联机重做日志
RFS
备用
重做
日志
存档的重做日志
ARCH
MRP/ LSP
将重做转换成
SQL，以进行
SQL 应用
存档的重做日志
ARCH
Data Guard 重做应用
物理备用数据库是主数据库的一个块到块的副本
使用数据库恢复功能来应用更改
可以以只读方式打开，用于生成报表和查询
还可用于备份和减轻生产数据库的负载
主数据库
物理备用数据库
重做传输
网络
重做应用
备份
备用重做日志
Data Guard
Broker
Data Guard SQL 应用
逻辑备用数据库是一个开放、独立和活动的数据库
包含与生产数据库相同的逻辑信息（行）
物理组织和结构可能大不相同
可以托管多种模式
当通过 SQL 来应用日志时，可以查询逻辑备用数据库，以进行报表操作
可以创建额外的索引和物化视图，以获得更高的查询性能
额外的索引和物化视图
重做传输
网络
可随时进行报表操作
将重做转换成 SQL
并应用
Data Guard
Broker
主数据库
逻辑备用数据库
备用重做日志
转换和故障切换
主数据库和备用数据库角色的转换
转换
计划的角色转换
无需将数据库重新实例化
用于维护操作系统和硬件
故障切换
主数据库出现意外故障（例如灾难）
必须将主数据库重新实例化或闪回 [10g]
利用简单的 SQL / GUI 界面进行初始化
Data Guard 使涉及到的过程自动化
灵活的数据保护模式
LGWR ASYNC 或 ARCH — 重做异步传输
最少的数据丢失
最高性能
LGWR SYNC — 重做同步传输
零数据丢失
单重故障保护
最高可用性
LGWR SYNC — 将重做同步传输至两个站点
零数据丢失
双重故障保护
最高保护
重做传输
数据丢失保护
保护模式
均衡成本、可用性、性能和事务保护
例如：ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION;
自动重新同步
可能出现网络连接问题
Data Guard 在网络连接恢复后自动重新同步备用数据库
隐式
主数据库上空闲的 ARCH 进程定期 ‘ping’ 所有的备用数据库，以查看它们是否丢失了任何重做数据
如果丢失，则把丢失的重做数据发送给它们
显式
应用过程期间在物理备用数据库中发现数据丢失
根据 FAL_SERVER 和 FAL_CLIENT 设置，通知主数据库，然后发送丢失的重做数据
议程
HA / DR 挑战
Data Guard 结构与特性
Data Guard 10g 的新特性
最高可用性结构
Data Guard 案例研究及其优点
Data Guard 10g 的新特性
一般的新特性
实时应用
闪回数据库集成
SQL 应用的新特性
零停机时间的实例化
支持额外的数据类型
滚动升级
Data Guard Broker 和企业管理器的新特性
RAC 集成
以最佳实践为核心，简化的基于浏览器的界面
实时应用
最新的物理/逻辑备用数据库
MRP/ LSP
RFS
备用
重做
日志
ARCH
存档的
重做日志
存档的重做
日志
主数据库
事务
LGWR
联机
重做
日志
ARCH
Oracle 网络
实时应用
现有站点恢复的权衡
可以使日志应用延迟，以防止用户错误，但是：
转换/故障切换也将延迟
报表操作使用的将是旧数据
在故障切换到备用数据库之后，必须重新构建生产数据库
主数据库
备用数据库
重做
传输
延迟的
应用
基于延迟的数据
进行报表操作
利用闪回数据库增强 DR
闪回数据库使得不再需要延迟日志应用
闪回数据库使得在故障切换之后无需重新实例化主数据库
实时应用实现了备用数据库上的实时报表操作
实时应用
无延迟！
实时报表操作
闪回日志
闪回日志
主数据库：在故障切换后
无需重新实例化！
重做传输
主数据库
备用数据库
SQL 应用增强
现在可以从主数据库的一个联机备份中创建逻辑备用数据库
支持额外的数据类型：
NCLOB
LONG
LONG RAW
BINARY_FLOAT
BINARY_DOUBLE
IOT（没有溢出和 LOB 列）
SQL 应用 — 使数据库滚动升级
重大的
版本升级
补丁集
升级
集群软件
和硬件升级
初始的 SQL 应用配置
客户机
重做
版本 X
版本 X
1
B
A
转换到 B，升级 A
重做
4
升级
X+1
X+1
B
A
在混合模式下运行，进行测试
重做
3
X+1
X
A
B
将节点 B 升级到 X+1
升级
日志
队列
X
2
X+1
A
B
企业管理器的新特性
Broker 和 EM 现在可以创建和管理包含 RAC 主数据库和 RAC 备用数据库的配置
简化的基于浏览器的界面可以对整个备用数据库生命周期进行管理
重点是：
易于使用
基于最佳实践的管理
预置的与其他高可用性特性的集成
示例 — 易于使用
使用企业管理器进行转换，轻轻点击鼠标即可
已转换！
议程
HA / DR 挑战
Data Guard 结构与特性
Data Guard 10g 的新特性
最高可用性结构
Data Guard 案例研究及其优点
最高可用性结构
Oracle 推荐的高可用性结构
基于 Oracle 技术的高可用性蓝图：
数据库、应用服务器、企业管理器……
与 Oracle 的新版本和新特性一起发展
基于客户的高可用性需求
预期面向对高可用性感兴趣的 Oracle 客户
定义和满足 SLA 要求的最佳实践
结构、配置和操作的最佳实践
使计划和意外停机时间最短
可从故障中高效地恢复并还原容错能力
与硬件和操作系统无关
坚不可摧的结构 + 最佳实践 ＝ 最高可用性
MAA 最佳实践出版物
关于以下事项的最佳实践：
RAC/ Data Guard 配置
重做数据传输机制
即时恢复
转换/故障切换
介质恢复
SQL 应用配置
网络配置
高可用性技术的集成
白皮书1：
MAA — 详细信息
介质恢复
站点/网络配置
快速启动检查点
SQL 应用的最佳实践
角色管理
1. 请参见
一些 Data Guard 的 MAA 效果
Data Guard 同步传输对于 LAN，甚至对于 MAN（~300 英里/10 毫秒 RTT）都是可行的
零数据丢失
对主系统的吞吐量影响最小（在测试中小于 3%）
异步传输对于所有类型的网络都可行
美国大西洋岸到太平洋岸的部署（~2600 英里/ 80 毫秒 RTT）对性能几乎没有影响（在测试中小于 1%），并且在出现灾难的情况下，潜在的平均事务丢失为 1 秒
异步模式下，在 WAN 上使用 SSH 压缩可使网络流量减少 35-60%
转换可以在 1 分钟内完成，故障切换在短短的 15 秒内即可完成
Data Guard 和 RAC
Data Guard 和真正应用集群是互补的，应一起使用以实现最高可用性结构
真正应用集群提供了高可用性
能够快速和自动地从节点故障或一个实例崩溃中恢复过来
提供了增强的可伸缩性
Data Guard 提供了灾难保护并防止数据丢失
维护主数据库的几个事务一致的副本
防止灾难、数据损坏和用户错误
无需昂贵且复杂的 HW/SW 镜像
Data Guard 与 Streams
Streams 和 Data Guard 是 Oracle 数据库企业版两个独立的特性，它们基于一些共同的底层技术
Data Guard： 灾难恢复与数据保护
事务一致的备用数据库
零数据丢失
自动转换/故障切换
各种数据保护模式
Streams：信息共享/分发
细粒化和控制要复制的内容
双向复制
数据转换
异种平台
由于业务需要，客户可能选择将 Streams 用于 DR/HA，而将 Data Guard SQL 应用用于信息分发
使用 Data Guard 和 Streams 的金融服务公司
数据输入
主数据库
Data Guard
用于 DR
物理备用数据库
Streams
用于信息分发
供客户端访问的
产品交付数据库
数据转换
具备远程镜像的灾难恢复
远程镜像（基于主机和基于存储器）是保护企业数据的另一种流行的方式
业务连续性实施的关键问题是：
数据可靠性
数据可恢复性
数据可用性
成本
Data Guard 的优点
网络效率
只传输重做数据
更适于 WAN
无需协议转换器，基于标准的 TCP/IP
更好的数据保护
保持写顺序的一致性，避免逻辑损坏和物理损坏
功能
全面的 DR 解决方案
灵活性
底层存储器对供应商没有限制
ROI
从 DR 投资中提取价值，与数据库本地集成
议程
HA / DR 挑战
Data Guard 结构与特性
Data Guard 10g 的新特性
最高可用性结构
Data Guard 案例研究及其优点
Data Guard 的客户
医疗保健
金融/保险
电子商务
其他行业
制造业
政府
公共事业
电信
运输
灾难恢复案例研究
公司：
为一个顶尖的汽车制造商提供全球物流和供应链管理服务
通过供应链实现了原材料和成品的端到端可视性
收益：1B+
系统：
为关键供应链数据库的选择 DR 解决方案
通过周期性的批量数据输入和面向 web 的应用程序更新数据库
由数据库生成的重做数据： MB/秒
数据库大小： TB，以后会变大
DR 案例研究（续）
DR 考虑事项：
恢复点目标：12 hrs
恢复时间目标：24 hrs
由于零数据丢失不是必要的，因此倾向于采用异步解决方案
使用 2,500 英里外的一个数据中心
网络连接是一个 VPN 到一个 DS-3 的连接（没有来自 ISP 的服务质量保证）
平均往返等待时间 — 120 毫秒，高峰使用期间的等待时间 — 200 毫秒
对于远程数据，将考虑使用一个不同于主数据库数据的存储阵列
DR 案例研究（续）
DR 解决方案：
考虑一个磁盘到磁盘的镜像解决方案 — 但这种解决方案以及协议转换器 (ESCON <-> IP) 非常昂贵
选择 Data Guard 来通过 TCP/IP 在 2,500 英里的距离上异步传输重做数据
数据库的无需额外成本
预置的与现有 RAC 解决方案的集成
允许为远程站点选择一个不同的存储阵列
虽然备用服务器没有主服务器那么强大，但如果备用服务器随时将承担主数据库的角色，那么可以选择增加 RAC 节点
Oracle Data Guard 的优点
灾难恢复与高可用性
主数据库和备用数据库之间可轻松进行故障切换/转换
完整的数据保护
实现零数据丢失，防止数据损坏
有效利用系统资源
备用数据库可用于报表操作、备份、查询
平衡数据可用性与性能
灵活的数据保护/同步模式
集中的简单管理
用于管理和监控的按钮式图形界面
在恢复网络连接之后自动重新同步
自动存档差异检测和解决，无需人工干预
资源
最高可用性结构白皮书：
OTN 上的 HA 门户：
OTN 上的 Data Guard 主页：
Oracle 文档 — Data Guard：
Oracle 文档 — 高可用性最佳实践：
A
Q
&
问答
7
7
For Redo Apply: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
For SQL Apply: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
When real time apply is enabled, RECOVERY_MODE column in V$ARCHIVE_DEST_STATUS displays “MANAGED REAL TIME APPLY”
Release Upgrades
Many changes
Often changes disk format, network protocols, views, packages
Relatively risky to apply to production system
Safety is primary goal
Apply in a rolling fashion across Data Guard nodes
Don’t need extra nodes or clusters to do a rolling upgrade
Can create a standby database on existing node or create an extra RAC instance on an existing node
Extra disk space and memory IS required
