active data guard

"THE FOLLOWING IS INTENDED TO OUTLINE OURGENERAL PRODUCT DIRECTION. IT IS INTENDED FORINFORMATION PURPOSES ONLY, AND MAY NOT BEINCORPORATED INTO ANY CONTRACT. IT IS NOT ACOMMITMENT TO DELIVER ANY MATERIAL, CODE, ORFUNCTIONALITY, AND SHOULD NOT BE RELIED UPON INMAKING PURCHASING DECISION. THE DEVELOPMENT,RELEASE, AND TIMING OF ANY FEATURES ORFUNCTIONALITY DESCRIBED FOR ORACLE'S PRODUCTSREMAINS AT THE SOLE DISCRETION OF ORACLE."

Oracle Enterprise Architecture

河北移动甲骨文技术日

Software. Hardware. Complete

Oracle容灾与数据高可用性解决方案

徐健大中国区，企业技术架构部，架构师

[email protected]

mailto:[email protected]

mailto:[email protected]

Agenda

• 容灾与数据高可用性解决方案

• Exadata在容灾中心建设方面的优势分析

• 当前各种复制技术概要对比

• Oracle容灾方案总结与建议

• Oracle容灾方案的成功案例

业务连续性定义

业务连续性：业务连续性是指当认为灾难、自然灾难来临的时候，基于建设完备的灾难备份系统切换，达到业务中断时间最短和业务数据丢失最少的状态。

RTO：恢复时间目标（Recovery Time Objective）是指灾难发生后，从IT系统宕机导致业务停顿时刻开始，到IT系统恢复到可支持各部门运作、业务恢复运营之时，此两点之间的时间段称之为RTO。

RPO：恢复点目标（Recovery Point Objective）是指对系统和应用数据而言，要实现能够恢复到可以支持业务运作，系统及生产数据应恢复到怎样的更新程度。简而言之，RPO就是灾难发生时，最大允许丢失的数据量的时间量度。

Mins DaysHrsSecs WksDays MinsHrsWks Secs

恢复点恢复时间

Source：Business Continuity Institute

业务连续性管理

•本地高可用是一切业务连续性的根本基础

•备份可以防止逻辑错误，是保证数据安全最后的保障

•业务应急系统由于有较低的启用成本，能解决大部分业务连续性问题

•容灾系统用于大规模、大范围灾难事件下的关键乃至全业务恢复运行能力

•容灾和应急系统共同提供业务连续性保障

保障业务连续性需要同时运用多个手段

第三方的卷管理器及文件系统。。。

第三方备份软件

第三方的冷备集群

存储阵列

空闲的Failover

服务器生产服务器

完全对等匹配的存储阵列

空闲的灾备系统

第三方的远程镜像

冗余的系统及存储

不可能知道容灾系统是否可用，直到你真的去尝试failover

传统的业务连续性方案昂贵的空闲冗余

需求需要的解决方案

完整的高可用支持帮助解决任何地方，任何类型的高可用性问题

典型的恢复时间秒到分钟级

高可用方案的测试频率任何时候都可以随时测试检验

典型的数据丢失零或秒级的数据丢失

方案的部署复杂度简单部署

解决方案堆栈的集成需求预集成

ROI “一定要帮我省钱！”

今天的业务连续性需求来自Oracle客户

服务器可用性

数据可用性

系统变更

应用变更

非计划

停机

计划

停机

真正应用集群（RAC）

Flashback

RMAN & Oracle Secure Backup

ASM

Data Guard

GoldenGate

在线重配置滚动升级

基于版本的重定义

Ora

cle

MA

A 最

佳实

践

在线重定义数据变更

Oracle数据库的业务连续性解决方案集业内最为强悍的解决方案！

1. Active-active 高可用性

2. 优化的数据保护和性能

3. 快速的数据修复

4. 系统改变不需要停机

5. 通过整合实现更多的强大的高可用性

Oracle数据库的业务连续性架构原则

• 传统的可用性技术需要空闲冗余

• 冷故障切换集群、被动灾难恢复站点

• 这样很不经济

• 更糟的是不可靠

• 您无法确定备份系统在你需要的时候能否正常工作

• 客户害怕使用灾难恢复站点

您是否检查过备用轮胎的气压呢？

原则 1: Active-Active 高可用性

缺点：

•备机空闲

•切换时存在较长时间的停顿

传统的灾备模式主机运行，备机等待

节点2

独立的存储阵列

第三方的备份

备用系统不是空闲的集群系统 – 节点1

3. 实现联机/滚动升级

Read-Only / Read-Write

Reporting

Backups

Tape

1.备用系统可以减少主生产系统用于执行上述操作的工作负载，提高整个系

统的效率

2.保护人为错误

新一代的容灾解决方案有效利用系统资源

• 所有的节点都是在线的(不是冷切换)

• 创建唯一的数据库由多台服务器组成

• 应用透明

HR SALES ERP

Active-Active 高可用性Real Application Clusters (RAC)

• 实现Oracle数据库的数据高可用性和数据保护，一个配置即可支持多达30个备用库• 备用数据库用于查询、报表统计、测试或备份—使用实时数据• Active Data Guard 能够实现查询访问实时数据，查询结果在transaction级别一致• 能够自动修复数据库的坏块，应用程序无需停机• 联机升级，自动故障的切换

Active Data Guard

Standby Database

Primary

Database

Sync / Async

Redo Transport

Active Data Guard 旨在确保发生灾难时恢复站点能随时可用

Active-Active 高可用性Active Data Guard

LAN & MAN 部署提供本地 HA 和 DR

扩展到广域网提供远程 DR

Data Guard 能力

1. Oracle 内置集成: 保障交易的一致

2. 极限性能

3. 应用透明，支持所有 Oracle 特性和数据类型

4. 应用级集成的故障切换

5. 整合的 HA/DR 解决方案

6. 确保故障隔离: 防止数据块损坏

7. 保障数据零丢失

8. DR 提供实时报表+测试，多重功效

9. 提供对计划和非计划的宕机时间支持

10.针对存储层没有厂商绑定

11.最少的网络损耗

12.没有距离限制

Oracle Data Guard高可用性的核心基础

Control

Files fil

Online

Logs

Archive

Logs

Flashback

Logs

Data

Files

SYSTEM

USER

TEMP

UNDO

生产数据库 DBMS 备用文件 Files

Control

Files fil

Online

Logs

Archive

Logs

Flashback

Logs

Data

Files

SYSTEM

USER

TEMP

UNDO

更新

Network I/O

注意: 数据块坏会传递到目的端

数据保护: 为什么不采用存储的镜像?显著的网络消耗

Control

Files fil

Online

Logs

Archive

Logs

Flashback

Logs

Data

Files

SYSTEM

USER

TEMP

UNDO

生产 DBMS 备用 DBMS

更新

Oracle applyOracle validationNetwork I/O

7X less

volume*

27X fewer

network

I/Os*

注意: 备用数据库可以保护主数据库的块损坏

用Data Guard实现数据保护Database数据库和网络优化的传输和重用

生产数据库

持续 redo

投递, 验证和重用

实时报表快速增量备份

物理 Standby

数据库

读-写负载

Data Guard备用数据库: Failover 目的端

生产数据库

持续 redo

投递, 验证和重用

实时报表快速增量

备份

Active Standby Database

(可打开使用)

读-写负载

Active Data Guard备用数据库: 卸载生产压力 + Failover 目的端

优点

提升主数据库的性能通过 offloading 处理到备用数据库

可以在物理备用数据库上使用standby数据库（用于查询、报表统计、测试）

物理 standby 可以以只读open 的方式打开并接受主数据库的变化

RMAN 快速更新备份可以在物理 standby 上使用 Block Change Tracking

自动修复损坏的数据块

可扩展的Reader

Farm

生产数据库

更新

查询

查询

查询

查询

• 支持多达30个活动的备用数据库

• 易于扩展读性能

• 增加更多的单节点活动备用数据库

• 或使用Oracle RAC来

扩展活动备用数据库的性能

Active Data Guard Reader Farms通过DR为读性能提供无限的扩展能力

Active Standby

Database

Active Data Guard 查询的 SLA 自动监控和回复 Apply 的延迟

• 预配置最大允许的apply延迟

• Data Guard 自动遵循设置的范围

主数据库

读/写

负载

持续日志投递, 验证和更新

实时报表

• 应用可以在代码级重定向到主数据库进行查询以满足SLA的要求

• 查询报错如果应用日志超出SLA的限制

Oracle Database 11g Release 2

New in 11.2

Active Standby

Database

Active Data Guard Auto Block Repair High Availability 在线修复损坏块

• 自动修复块损坏

• 当Oracle 在主数据库发现坏块时, 它会自动的通过从active standby database拷贝正确的版本来解决问题(反之亦然)

• 对用户和应用透明

Primary

Database

读/写负载

持续的日志投递, 验证和应用

实时报表

New in 11.2


• 业界最好的逻辑复制

• 针对异构系统的持续的高可用性

• 针对报表, BI, EPM的实时数据访问.

• 零停机时间的迁移/升级, 迁移/升级Oracle数据库和应用

• 异构, active/active, 子集复制

• 能够铺获和交付到: Oracle, DB2, SQL Server,

Sybase ASE, Teradata, Enscribe, SQL/MP,

SQL/MX

• 另外, 可以交付到: HP Neoview, Netezza,

Greenplum, 任何 ODBC 匹配的数据库, MySQL,

TimesTen, ETL products, JMS message queues

Real-time

information

Real-time Access

Active-Active 高可用性Oracle GoldenGate

源数据库目标数据库可读可写

LAN / WAN / Internet(TCP/IP)

Capture: 实时读取交易日志捕捉数据变化并可实现过滤.

Capture

队列文件: 暂存数据变化.

Source Trail

Delivery:执行所需的数据变化，然后将数据变化提交到目库的.

Target Trail

Delivery

双向

Source TrailTarget Trail

Delivery Capture

Pump

Pump

传输: 数据经过压缩和加密传送到目的地

数据泵出: 分布数据为传输到多个目标

Read/Write

Workload

Read/Write

Workload

生产库实时同步数据给容灾库；容灾库上做的辅助操作的结果数据还可以同步给生产库。

Active-Active 高可用性Oracle GoldenGate 架构

GoldenGate TDM提供异构环境下交易数据的实时捕捉、变换、投递。

TDM 具有 :

实时性秒一级延迟

异构环境支持在不同平台和数据库环境下复制数据

以交易为单位复制维护交易一致性

特性:

高性能能够以低资源消耗完成每秒数千交易的复制

可扩展开放的结构使客户适应各种异构数据平台

可靠保证数据的连续可用

GoldenGate交易数据管理TDM : Transactional Data Management

GoldenGate

- Information Distribution

- Heterogeneous

Bi-directional

Replication Subsetting MySQL

Standby

Database

Active Data Guard

- DR & Data Protection

- Real-time Query

Primary

Database

RAC

- Scalability

- Server HA

Active Dataguard + GoldenGate强强联合提供整合的异构数据分发，高可用,灾备及双活复制

Network

Broker

ProductionDatabase

读写双活

SQLApply

Open R/O withActive Data Guard

Transform Redo to SQL

只读双活

DIGITAL DATA STORAGE

DIGITAL DATA STORAGE

Backup

Redo Apply

Sync or Async Shipping of Redo Blocks

Boston

Chicago

Dallas

Open R/W forperipheral writes

Active Dataguard + GoldenGate强强联合完整的数据保护方案

原则 2: 优化的数据保护

• 数据保护的基本方法是匹配两个版本来保证一致性- e.g., disk mirroring, checksum comparison

• 存储&第三方HA 解决方案只能把数据块作为opaque binary 数据• 操作系统, 文件系统无法知道Oracle数据块是否是好的, 即使他们存储数据

• Oracle知道数据块包含什么 , 所以我们能够做更多更好的检查, 即使我们获得两个不同的版本, 我们可以选择对的版本.

$!$%% !#@!! !$ *&^@ /^$++%!$94999^

北京市景华南街5号,远洋光华写字楼

• 存储或者操作系统级别的复制是复制 bits

• 假如主数据集的数据被破坏了, 破坏的数据也肯定被复制到备份端

• Active Data Guard 和 GoldenGate 使用基于 redo log

的复制• 我们传递变化的vectors, 它具有定义非常好的结构和语法是可以被验证的

• 可以防止坏块数据被传递

• 甚至可以监测到到丢失的写操作

• 主数据库可使用Active Data Guard 自动修复坏的数据块来实现零应用停机

Oracle 优化数据保护基于Log的数据复制

原则 3: 快速的外科手术式的数据修复

• 传统的 HA 技术不知道数据的含义• 只能做coarse-grained 恢复 – 整个文件或者是

volume

• Oracle 具体知道数据结构• 能够进入到物理结构里面做外科手术式的修复

• 可以做更多类型的修复

• 可以极大地减少修复时间

0

20

40

60

80

• Flashback 革命性改进错误修复

• 查看过去某个时间点的”好的” 数据

• 简单地回放数据变化

• 纠正错误的时间等于产生错误的时间

Correction Time = Error Time + f(DB_SIZE)

• 低影响, 容易– 简单的命令, 没有复杂的过程

• Flashback Query, Table, Transaction, Database, Drop

• E.g.: SQL> flashback database to <timestamp>;

• 在Oracle Database 11g Release 2中继续增强:

• Flashback database performance & monitoring optimizations

• Flashback archive support for schema evolutions

Re

co

ve

ry T

ime

Traditional Recovery

Flashback

快速的外科手术式的数据修复Flashback Technologies

快速的外科手术式的数据修复错误更正使用Flashback

• 任何级别的错误更正

• Database• Flashback Database - restore

database to time

• Table• Flashback Table - restore

contents of tables to time

• Flashback Drop - restore dropped table

• Row• Flashback Query - restore

individual rows

Order

Database

Customer

原则 4:系统改变不需要停机

• 一个主要的原因进化到开放系统是使系统改变快速响应业务的变化.

• 用户习惯于要求的系统停机时间，来实现数据和应用程序的更改

• 运行的非常好的系统不应该有非计划内的停机时间

• 我们也不应该接受计划内的停机时间

• 所有的index 变化可以被在线实现

• Tables 可以被在线重新组织 & 重新定义• 可以变化location, table type, partitioning, columns, column types

• 当在复制过程中可以转换数据内容

Source Table

Update Tracking

Transform Copy

Table

Transform

Updates

Result Table

Continuous Queries & Updates

Store Updates

变化不需要停机时间在线的 Index & Table 重定义

系统改变不需要停机Online Patching and Upgrades

• 大部分的 one-off patches可以被应用到运行的 Oracle instance

• Linux-x86, Solaris 10, HP-UX 11i

• [New in 11.2] Windows 32-bit and Windows 64-bit, AIX v6.1 [TL2 SP1]

• 大部分的复杂的one-off patches可以在线部署, 通过使用RAC rolling

patches (available 10g onwards)

• 数据库版本/补丁集升级, 操作系统升级, 平台迁移可以滚动方式升级采用Data Guard / GoldenGate

• 数据中心/ SAN 迁移 etc. 可以采用Data Guard / GoldenGate 实现最小时间内的停机

• Servers

• 增加/删除RAC nodes 在线

• 不需要数据移动

• Storage

• 增加/删除ASM 磁盘或者阵列在线

• 当存储发生改变, 自动重新平衡

• Clusterware, ASM

• 升级 Oracle Clusterware 和 ASM (11g在线方式

Database

Storage

系统改变不需要停机Online Reconfiguration

• 可以使两个版本的应用同时运行

• 维护多个版本的变化数据库对象• 新版本的应用能看到新的列和存储过程

• 老版本的应用能看到老的表和PLSQL存储过程

• 新老版本的应用的变化可以被转换和应用到其它的版本• 应用程序版本都支持并发的变化

• 允许升级和降级, 不会有数据丢失Pre-upgrade Edition

New in 11.2

Post-upgrade Edition

Crossedition

Triggers

系统改变不需要停机基于版本的重新定义

原则5:通过整合实现更多的强大的高可用性

• 任何系统推栈里的组件都可能发生故障

• 软件– applications, middleware, database, …

• 硬件 – disk drives, disk controllers, HBAs,

memory, …

• 网络 – routers, switches, cables, …

• 操作过程 – human errors, bad installs &

upgrades, …

• 你需要一个全面的解决方案，包括相互合作的子系统

Active Data Guard–Data Protection, DR

–Query Offload

GoldenGate–Active-active

–Heterogeneous

Oracle Secure Backup–Backup to tape / cloud

Active Replica

Edition-based Redefinition,

Online Redefinition, Data Guard, GoldenGate– Minimal downtime maintenance, upgrades, migrations

RAC–Scalability

–Server HA

Flashback–Human error

correction

Production Site

ASM–Volume Management

RMAN & Fast Recovery Area–On-disk backups

通过整合实现更多的强大的高可用性Oracle Maximum Availability Architecture

Agenda






• 数据库云服务器在硬件中加入最大可用性结构• 更好、更快、更高的可用性

• 数据库云服务器不仅是集成的—它还是一个标准配置

• 如今，每个客户都使用自己独特的配置• 而数据库云服务器改变了这种情况

• 您是运行着同一配置的广大用户中的一员• 它正是我们在实验室中运行的配置• 它正是尖端客户所运行的配置

• 将为您提供卓越的可靠性

• 数据库云服务器Exadata正以其震撼的性能、卓越的性价比，迅速改变着数据库市场的架构格局，Exadata等同于行业趋势与方向所在！！

通过集成整合实现更多的强大的高可用性Exadata 数据库云服务器作为标准配置一个更好的小白鼠战略

WAN

• 全面的保护防止故障发生: server, storage, network, site故障

• 人为错误的更正: database, table, row, transaction

• Active DR: 实时远程standby库打开, 为了查询及备份卸载

• 在线的索引和表重新定义

• 在线打Patch和升级

Real

Application

Clusters

ASM

Fast

Recovery Area

Active

Data Guard

Oracle Secure Backup

通过整合实现更多的强大的高可用性Oracle MAA with Exadata Database Machine

优点高性能，简单的HA和DR解决方案，在备用节点可读

零数据丢失, 集成的数据损坏保护， switchover / failover

针对所有数据类型和Oracle数据库特性的充分支持

优化的 redo apply (220-600 MB/sec) 和备份 (17-18 TB/hour)

Standby 优先 Patch Apply 降低主库的风险

在主库和备用库的一致的性能特征

客户端 failover 集成可能性

注意点 Active Data Guard 数据库是无法更新的（只读打开）

Active Data Guard在Exadata

Exadata HP IBM

硬件设备配置说明

Exadata 1/2配置

SPECint_rate2006=3091

存储用户数据量 60T

HP Superdome(满配）*264×1.6GHz Dual-coreSPECint_rate2006=1480*2=3060


IBM P595 * 226×5GHz Dual-coreSPECint_rate2006=1870*2=3016


设备价格(万RMB) 800 1100 950

第一年硬件服务费 0 0 0

第二年硬件服务费 176 0 0

第三年硬件服务费 176 0 0

数据库服务器实际开销费用小计： 1152 1100 950

存储系统配置说明 Exadata已提供，无需新购存储空间需采购新存储系统，总裸容量需要230TB，可采购CX4-480存储系统，配置390

块600GB硬盘，共26个DAE，另外包括PP×6

存储设备价格 0 400 400

存储设备三年服务费 0 144 144

存储系统实际开销费用小计： 0 544 544

新购Oracle许可证费用需要DB/Partition/RAC license各24个

需要DB/Partition/RAC 许可各192个需要DB/Partition/RAC许可各78个

DB 许可费用 285 2278 925

Partition 许可费用 71 569 231

RAC 许可费用 142 1139 463

Oracle许可证采购费用小计： 498 3986 1619

Oracle年服务费 110 878 356

Oracle三年服务费小计： 330 2634 1068

采购与三年运行费合计： 1980 8264 4181

某数据库容灾系统的需求：

1、基于并行计算服务器的衡量指标SPECint_rate2006指标，假设需要SPECint_rate2006=3000的服务器处理能力；

2、假设需要的存储的用户数据量为60T；

3、基于中国移动集采价格报采购与三年运行费用；

某数据库容灾系统，Oracle Exadata方案与HP/IBM方案的成本对比

FC随机IO时的CPU消耗

@8 CPU rx6600

FC连续IO时的CPU消耗

@8 CPU rx6600

FC测试参考

• Exadata解决方案- Exadata Infiniband方式(远比传统FC技术高效、CPU开销小)

• 有效IO速率：

• 在Exadata方式下，单路可以看到3.6GB/s以上的IO能力，是FC的10倍到20

倍

• CPU消耗

• 鉴于40Gb/s的传输速率是FC的10倍，故软件设计上没有采用传统的驱动方式，而采用了RDMA/RDS/iDB（远程DMA操作之上的数据库块传送），CPU不会介入IO传输过程，40Gb/s IO只会占用2-3%左右的CPU资源

• 传统HP/IBM方案 - 小机传统FC光通道方式

• 有效IO速率：在典型场景下，4Gb FC的有效传输效率通常在 200-300MB/s左右，而不是 400MB/s，因为：

• 阵列控制卡资源配置通常没达到理想值

• Cache资源配置通常没达到理想值

• 后端FC环路配置通常没达到理想值

• 磁盘组的划分方式受限

• 阵列内部其它资源限制

• CPU消耗

• 从HP的FC测试来看，FC对CPU的消耗非常大(单路甚至高达19.4%)

对传统系统，考虑FC对CPU的大量消耗，需要增加更过的CPU来处理业务。

存储IO技术对比

• Exadata解决方案：按½机架Exadata X2-2计算，共需：• 2C×6cores×4serversx0.5licence rate = 24 CPU 数据库授权

• 传统HP/IBM解决方案：按HP的方案计算，共需：• HP Superdome方案： 64Cx2coresx2servers×0.75license rate =

192CPU 数据库授权

• IBM P595方案： 26Cx2coresx2servers×0.75license rate = 78CPU数据库授权

• Exadata解决方案可节约54 – 168 CPU 授权

数据库软件许可对比

特性Exadata解决

方案传统HP/IBM

解决方案作用

ASM on Exadata Yes X减少90%的存储管理需求，单一表空间

SmartScan Yes X 10x – 100x 查询速度提升

EHCC混合型列压缩 Yes X5x-50x信息密度提升，并提升查询速度

扫描BW + Storage Index Yes X 减少90%以上索引

11g内存管理、SQL管理、DOP、并发排队等新技术

YesYes(若升级到11g)

减少80%以上调优工作

IORM（IO资源管理） Yes X 确保整合后资源合理调配

云特性 Yes X确保向数据库云方向发展，符合未来技术发展趋势

数据库软件特性对比

特性 Exadata解决方案传统HP/IBM解决方案

OLTP 好，4+倍性价比好

OLAP 非常好，10+倍性价比不好，或价格极其高昂

OLTP+OLAP

混合型业务可以（Flash + MPP,

DBRM + IORM可非常

容易控制混合型业务的有效执行）

难以共存(硬件配置结构及资源控制房子存在众多约束)

OLTP + OLAP业务共存对比

• 系统开通方式对比• Exadata解决方案中Oracle服务目标：交给用户一个已经运行起来的超高性能数据库系统 – 交钥

匙项目

• 货物运输

• 硬件施工（不包含基础设施）

• 操作系统软件安装

• 数据库集群安装

• 数据库初始化

• 表空间建立

• 传统HP/IBM解决方案中Oralce服务目标：只确保软件本省的问题，不负责硬件、局部负责硬件与软件的配合问题、不负责安装、不负责调试等任务（除非购买Oracle高级服务选项）

• BUG解决方式对比• Exadata解决方案：硬件(主机及存储、网络)、OS、数据库平台由Oracle提供，一站式解决全部

基础问题，一个责任人，极大减少中间环节。

• 传统HP/IBM解决方案：必须在确保各硬件(主机及存储、网络)及OS没有问题的前提下，才会进入到数据库层面讨论问题，时间漫长，容易相互推诿。

服务方式对比

项目 Exadata解决方案传统HP/IBM解决方案

硬件管理 Intel服务器，简单由小机、SAN、阵列等不同设备组成，复杂

存储空间管理可单一表空间，100%横向部署，基本不需要管理

需要不停管理物理接口、LUN、卷组、表空间等，工作繁杂

电力消耗单体密度较高，但总量小单体密度低，但总量很大

机房空间 1机架 4 – 5机架空间

DBA技能简化空间管理简化了Index管理系统容易稳定，DBA简单

需要不停调优，管理复杂

OPEX对运行维护及人员的要求对比

• 保修• Exadata解决方案

• 硬件成交价12%(包含操作系统)

• 软件成交价22%

• 传统HP/IBM解决方案

• 硬件成交价10%（比率略低，备品、备件昂贵）

• 软件成交价22%（同样百分比，但是在这种方案下软件许可的数要远远大于Exadata方案数倍以上，因此保修费用也就大幅提升）

• 扩容• Exadata解决方案：¼机架=> ½机架=> 1机架 => 多机架或增加独立的存储

单元，且目前已有明确的价格定义，保持在相同的价格水平。得益于采用的标准Intel服务器架构，即使技术已经升级，未来扩容成本可预期，相对低廉。

• 传统HP/IBM解决方案：按部件方式扩容，技术及成本结构复杂，尤其在技术已经升级的情况下，成本难以预期。

保修及扩容对比

项目 ½ Exadata

CPU48 DB Server + 84 Storage

Server 核

内存1:8（每core对应8G内存）+1:2 (每core对应2G内存)

存储 IO 12.5+25GB/s

存储IO连接 280Gb/s

磁盘存储50TB(Raw)/

12.5GB/s

Flash存储2.65TB/

25GB/s

随机IOPS 50万/s

响应时间(8k) <1ms(90%)

机架 1/2

数据库License 24CPU

硬件成本 700-800万

Oracle ½机架数据库一体机技术指标

Agenda






复制模式技术选择

智能存储复制

数据日志复制—逻辑级

逻辑卷复制• 同步模式

• 异步模式

数据库级复制—整库级

数据复制技术

• 同步镜像复制

- 写操作必须在远端副本及本地源端都完成写操作后才反馈给主机

- 保证源端和远程副本上的数据时刻一致

- 同步副本提供最短的RPO和RTO

• 异步镜像复制

- 写操作的确认在本地源端完成后就反馈给源端

- 数据被缓存并被发送到远端

- 固定的RPO

• 混合式镜像复制- 三中心部署方案

- 同城双中心同步镜像，异地中心异步镜像

- 往往结合多种存储技术（例如本地复制）

存储远程镜像复制技术

• 冷灾备中心模式

•优势

• 独立于主机，不占用主机资源，异步模式对应用影响小

• 模式简单

•限制

• 存储平台不独立，多中心存储设备硬件平台相同

• 单一的复制拓扑，不支持多对一模式

• 同步模式：性能影响大，网络要求高

• 异步模式：存在数据一致性问题

• 混合模式：需要较多的存储投资

•主要产品

• IBM PPRC/EMC SRDF

存储远程镜像复制技术

IP 网络

Application

Volume Manager

Application

Volume Manager

Volume Manager

Volume Replicator

Volume Manager

Volume Replicator

RLink RLink

RVGSRL SRL

• 在本地和远端有完全一样的卷组（VG）

• 所有对源卷的写操作都被复制到远程站点

- 同步或异步

逻辑卷（LVM）远程复制

• 冷灾备中心模式

• 优势

- 存储平台无关，源端和远端可以使用不同的存储设备和RAID保护级别

- 可以在IP网络上复制，网络要求不高

- 异步模式下应用响应时间不受影响，但RPO会被延长

• 限制

- 占用主机资源，IO等待较高

- 同步模式：性能影响大

- 异步模式：存在数据一致性问题

• 主要产品

• VERITAS

逻辑卷（LVM）远程复制

源端

目标端

• 基于主机的日志传送

• 适用于数据库数据复制

• 两种模式：

• 逻辑数据复制

• 数据库复制

数据日志复制

网络

源数据库目的数据库双向复制

队列文件暂存数据变化.

数据经过压缩和加密传送到目的地.

实时读取交易日志捕捉数据变化并可实现过滤.

执行所需的数据变化，然后将数据变化提交到目的库。

CaptureSource Trail Target Trail

Source TrailTarget Trail

Delivery

Delivery Capture

数据日志复制逻辑级复制

• 热灾备中心模式

• 优势- 日志解析，对主机（数据库服务器）负载较少- 准同步模式，RPO短- 主机无关，存储无关，数据库平台相关性弱- 元数据对象独立于数据库,可以支持异构数据库- 可以细化到具体的数据对象（Schema），可以选择性地进行复制

- 复制拓扑结构灵活- 网络要求较低

• 限制- 只支持数据库同步，不支持其他类型数据同步- 较多的数据层维护工作量- 数据库支持有一定限制要求

• 主要产品：Oracle GoldenGate

数据日志复制逻辑级复制

远端数据库

源端数据库

同步/ 异步Redo Transport

同步复制优势

• 数据完全同步 (RPO=0)

劣势

• 复制网络要求高，

• 对应用性能影响较大，尤其距离远时

异步复制优势

• 性能好，对应用影响小

劣势

• 灾备中心数据滞后 (RPO)

• 数据一致性危险

数据日志复制数据库级复制

• 热灾备中心模式

• 优势

• 实现方式简单

• 应用透明，支持数据库所有特性

• 网络传输效率高

• 故障隔离，防止数据块损坏

• 限制

• 同步模式：对应用性能有影响

• 异步模式：数据一致性问题

• 只支持数据库同步复制

• 主要产品• Oracle Data Guard/Active Data Guard

数据日志复制数据库级复制

模式优势局限性适用场景

存储镜像IBM/EMC/HP

冷中心独立于主机，不占用主机资源，异步模式对应用影响小;

模式简单

存储平台不独立，多中心存储设备硬件平台相同单一的复制拓扑，不支持多对一模式同步模式：性能影响大，网络要求高异步模式：存在数据一致性问题混合模式：需要较多的存储投资

容灾

逻辑卷镜像VERITAS

冷中心存储平台无关，源端和远端可以使用不同的存储设备和RAID保护级别可以在IP网络上复制，网络要求不高异步模式下应用响应时间不受影响，但RPO会被延长

长时间网络故障需要巨大日志文件空间占用主机资源，IO等待较高同步模式：性能影响大异步模式：存在数据一致性问题

容灾

逻辑数据复制GoldenGate

热中心日志解析，对主机（数据库服务器）负载较少准同步模式，RPO短

主机无关，存储无关，数据库平台相关性弱元数据对象独立于数据库,可以支持异构数据库可以细化到具体的数据对象（Schema），可以选择性地进行复制复制拓扑结构灵活网络要求较低

只支持数据库同步，不支持其他类型数据同步较多的数据层维护工作量数据库支持有一定限制要求

应急

数据库复制Active

Dataguard

热中心实现方式简单应用透明，支持数据库所有特性网络传输效率高故障隔离，防止数据块损坏

同步模式：对应用性能有影响异步模式：数据一致性问题只支持数据库同步复制

容灾

几种技术的比较分析

Agenda






Real-time

Queries

Standby

Database

Production

Database

技术特点：

1.基于RedoLog的数据复制方案；

2.主节点做业务，Standby节点；

3. 分为同步/异步数据传输恢复。

基于Data Guard的容灾方案

Real-time

Queries

Physical Standby

Database

Production

Database

Continuous Redo

Shipment and Apply

Real-time

Query

技术特点：

1.基于RedoLog的数据复制方案；

2.Active-Active的高可用，备份节点可实现查询访问实时数据，查询结果在transaction级别一致；

3. 分为同步/异步数据复制，复制过程对源端与目标段的负载影响很小；

4. Active Data Guard 能够能够自动恢复主数据的坏块。

5. 联机升级，自动故障的切换；

基于Active Data Guard的容灾方案

ManagerManager

- Capture / Extract - Delivery / Replicat - Trail

OLTP UsersReporting Users

Primary Live Standby

技术特点：

1.基于SQL的数据复制方案，支持异构数据库；

2.Active-Active的高可用，可以做双活中心，真正做到零宕机；

3. 延迟低，低带宽，可以指定复制粒度到表；

4. 目前不支持压缩格式的数据表。

基于Golden Gate的容灾方案

Active Data Guard–Data Protection, DR

–Query Offload

GoldenGate–Active-active

–Heterogeneous

Active Replica

RAC–Scalability

–Server HA

Flashback–Human error

correction

Production Site

技术特点：

1.根据不同的复制需求选择不同的技术，发挥Golden Gate和Active Data Guard的优势；

2.提供完善，高效的容灾方案。

集成的容灾备份方案

• 中国移动业务运营支撑系统-容灾备份系统规划和建设目标：• 实现关键业务系统及其关联系统的数据安全

• 减少计划停机次数、时间，消除对核心数据的争用

• 将异地中心接管业务的时间控制在可以接受的范围内

• 实现异地中心的软硬件设备和数据的复用

• 业务连续性=从计划外停机中实现灾难恢复+在计划停机期间保持连续可用+利用冗余资源提供增值服务

中国移动业务运营支撑系统容灾备份技术规范

• 急用先行• 以解决青园街生产中心扩容压力为当下首要目标

• 同城复用• 以同城高可用的双活中心为近期目标，充分利用灾备资源

• 异地容灾

• 以廊坊为异地容灾中心（尤其是关键数据的异地容灾），以三活中心为最终目标（廊坊可以承担查询、报表统计及测试）

• 统筹规划• 着眼三中心建设来衡量总体投入及技术选择，总体统筹规划

河北移动三中心容灾建议建设策略及原则

• 急用先行• 基于Exadata对青园街生产中心做数据库的整合改造，将腾退出的机器部分用于应用服务器或数据库服务器的扩容，或移入开发区增强开发区应用服务器计算能力

• 同城复用• 开发区引入Exadata，将青园街Exadata上的部分应用迁移到开发区Exadata上（可以按当前的AB库划分原则，两边分别承担A/B库），通过Active Data Guard两边做双活灾备

• 异地容灾

• 将腾退出的机器移入廊坊中心，成为应用服务器，廊坊中心通过Active Data Guard分别与开发区及青园街同步数据，廊坊中心成为异地容灾中心（尤其是关键数据的异地容灾），并成为查询、报表统计及测试中心

• 统筹规划• 先就Exadata方案及传统小机方案做ROI分析，然后再执行

河北移动三中心容灾建议建设建议

Oracle 作为的合作伙伴

• Oracle 是领导者

• 你需要和领导者做合作伙伴, 与一个追随者作合作伙伴是危险的.

• 即使是 Oracle的竞争对手, 也承认Oracle具有正确的方向

• Oracle 宣布推出Exadata Database Machine V1 在2008, V2 在2009, X2-2 和X2-8 在 2010

• IBM 收购 Netezza 花了$1.78 billion – 2010 9月

• EMC 买了 Greenplum – 2010年7月

Agenda






Oracle HA: Customer Success Stories• Allstate - Oracle Maximum Availability Architecture with Oracle RAC, ASM, Data Guard, RMAN, Flashback

• Amazon.com - Automatic Failover using Data Guard Fast-Start Failover

• Amtrust Bank - Oracle Database Maximum Availability Architecture & Zero Data Loss

• Bonnier - Site migration with Oracle Streams

• CERN - Oracle Streams for the Large Hadron Collider at CERN

• Commonwealth Bank of Australia - MAA with Oracle RAC, Data Guard, ASM, RMAN, and Grid Control

• ChevronTexaco - RMAN DUPLICATE – DBA Time Saver to the Rescue

• Chicago Stock Exchange - Expects 171% ROI in Five Years from Oracle Enterprise Grid Computing

• CSX - Online RMAN Backups Protect over 16TB of Data

• Dell - Dell Consolidates European Support System with Oracle Enterprise Grid on Dell

• E-Rewards - HA and synchronization of Data Warehouse and OLTP databases using SQL Apply and MAA

• Fidelity National Financial - MAA for 12TB database with primary and standby data centers separated by 750 miles

• The Hartford - Incrementally Updating Transportable Tablespaces using RMAN

• Intermap Technologies - Using an Active Data Guard 11g standby for secure 24x7 Internet access

• Kemira GrowHow Ltd, UK - Replacing Outsourced Disaster Recovery Services with Oracle Data Guard

• KLM - KLM Royal Dutch Airlines Eliminates Costly Downtime with Grid Solution

• NeuStar - Synchronous Zero Data Loss Protection with Production and Standby Databases Separated by 300 Miles

• Nokia - The use of RMAN within Nokia's Oracle Database 11g MAA Architecture

• Oracle Global IT - Saving over $300,000 with Oracle Secure Backup

• Public Trust - Low cost grid for SMB: Data Guard, RAC, RMAN, ASM, Oracle Application Server, Grid Control

• Starbucks - Enterprise data warehouse (EDW) VLDB backup and recovery architecture

• Starwood Hotels - RMAN in Oracle Database 10g Best Practices for Maximum Benefit

• USA Today – Data Protection and Availability for Mission Critical Publishing System

• Yahoo - MAA with Oracle RAC (16 nodes) and Data Guard

• Volkswagen Group – Streams Hub & Spoke Architecture with Data Guard Standby Database

and many more* …

* http://www.oracle.com/technology/deploy/availability/htdocs/HA_CaseStudies.html

Oracle ITScale Beehive Office Applications to 90,000 Users

• Beehive – Oracle’s unified

collaboration solution

• Email, instant messaging, conferencing,

collaboration, calendar…

• Oracle Database 11.1.0.7

• 16 node RAC clusters

• 98 Exadata storage cells / site

• Multi-standby Data Guard configuration

• Local standby for HA

• Offload read-only workload

• Offload backups

• Remote standby for DR

MAA components: The complete, integrated MAA technology stack

• Next generation architecture• Consolidation of 70+ legacy claims apps

running on multiple mainframe & SQL

Server databases into a scalable

architecture based on Oracle MAA

• 10,000 users at full roll-out

• MAA benefits• Better than mainframe availability

• Scales to handle peak workload

• Transparent to most failures

• Fast recovery where not transparent

• Best protection from physical corruptions

Primary Site

Oracle RACASMFlashbackRMANData GuardGrid Control

Remote Recovery Site

Physical Standby- DR- Testing- Offload reporting

using Active Data Guard (future)

Allstate InsuranceNext Generation Claims Applications

Data Guard

• #1 utility provider for Northern and

Central California

• Customer Care & Billing System

for 13 million users : DB2 /

mainframe migration to Oracle

MAA on open systems

infrastructure

– Daily load: 1+ billion select, 100

million insert/update/delete

– 2300 concurrent online users,

350,000+ bills per day

• With MAA:

– 24x7 uptime SLA

– $5M annual cost savings

– 25% performance improvement

(online, batch)

Data

Synchronization

through Data Guard

8 Node RAC & ASM

17 TB Primary Database

Single Node

Standby Database

(expandable to 8 nodes)

8 Node RAC

Full Scale Testing

50 miles

Pacific Gas & Electric (PG&E)Mainframe Availability, Higher Performance, Lower Cost

MAA components: RAC, ASM, Data Guard, Flashback, RMAN, Grid Control

MercadonaRegularly Validate DR Readiness

• Spain: 1,267 supermarkets, 60,000

employees, $14 Billion Euro

• Two new data centers, 350km apart

• Symmetric configurations

• Test/QA in standby data center

• Oracle Database 11.1.0.7

• 25 databases, 10.6TB of data

• Oracle WebLogic Server

• 99+ different applications

• Data Guard 11g

• Maximum Performance, ASYNC

• Data Guard Broker

• 30MB/second redo generation

• Data Guard switchover across data

centers enables easy DR testing

every 4 monthsMAA components: Data Guard, RMAN, Flashback

Database, Enterprise Manager Grid Control

Primary SiteNetwork tostandby site

>

WebLogic ServerDR - MIRRORING

Oracle DatabaseDR - DATA GUARD

Apple IncReader Farm Scale Out using Active Data Guard

App 1

App n

Data Guard Standby Database

ADG 1

App 2

App 3

Primary Database

ADG 2

ADG 3

ADG 8

ADG 9

(Max Availability Mode)

SYNC

ASYNC

Load

Balancer


Intermap Technologies Inc.Active Data Guard 11g - Secure Access to Real-time Data

Ingest

geo-spatial

data

10 TB

Primary Database

10 TB

Active Data Guard

Standby Database

Real-time data

synchronization

through Data Guard

With Active Data Guard 11g

• Better performance

• Secured Internet access

• 24x7 - standby always up-to-date

• Quick win!

• Easy to implement

• Utilize existing DR system

Use Active Data Guard to offload

public Internet access to high-res

3D digital data- Auto Safety & Fuel Efficiency

- Insurance Flood Modeling

- Global Positioning Systems

- Environmental Planning

- Wireless Communications

MAA components: ASM, Active Data Guard (Fast-Start Failover)

Amazon.comHigh Availability Integrated with Disaster Recovery

0

10

20

30

40

50

60

Min

ute

s

End-to End Failover Time

Resolve

Respond

Identify

BeforeData Guard

Data GuardAutomatic Failover

With Data Guard HA/DR

Database failover: 20 secs

Apps redirected: 2 mins

Standby site distance: 15 miles

MorphoTrakCut $100,000 in System Cost with Active Data Guard

• Printrak Biometrics Identification

• 15 Terabyte database

• Mixed OLTP – read intensive

Site ARead-write transactions

• Read-only transactions directed to active standby

• Full utilization reduces acquisition cost

• Simpler deployment reduces admin cost

Data Guard Maximum Availability - SYNCActive

Data Guard

Standby

Database

Site BRead-only transactions

Zero data loss - automatic database failover

Primary

Database

2-node RAC

Oracle

11.1.0.7

MAA components: RAC, Active Data Guard, ASM, Flashback Database, RMAN

“The State of Connecticut was able to satisfy its demands for increased

system availability and reliability by deploying its PeopleSoft system on

Oracle RAC with a Data Guard physical standby database.”

– Angelo Romano, IT Manager, State of Connecticut

Primary Site

6-node Dell PowerEdge

RAC DatabaseOracle Database 11g

on LinuxSecondary Site

4-node Dell PowerEdge

Data Guard

SYNC

State of ConnecticutIncreasing PeopleSoft availability with Oracle MAA

11i Web/Forms/PCPPeopleSoft

Midtier PortalEPMFinanceHRMS

• Oracle.com:http://www.oracle.com/ha

• Oracle HA Customer Success Stories on OTN:http://www.oracle.com/technology/deploy/availability/htdocs/HA_CaseStudies.html

• Maximum Availability Architecture (MAA):http://otn.oracle.com/goto/maa

• MAA Assessment: http://www.oracle.com/goto/hasurvey

Resources

active data guard

Documents