Slide 1

Transcription

1 数据库技术创新 12c 新特性 Exadata X4 更新 活动数据卫士 高景强 Oracle 首席技术顾问 M:

2 提纲 Oracle Database 12c 新特性 Exadata 数据库云平台 - X4 更新简介 数据库容灾 - Active Data Guard 2

3 无需更改应用程序 隔离和多承租方 快速供应和克隆 安全而具有高可用性 IT 成本降低 将多个作为一个管理 更高的资源利用率 具有高性能且可伸缩 3

4 Oracle Database 12c New Features 体系架构 4

5 新的多租户架构 (Multitenant) 只有多租户容器需要内存和进程 系统资源 5

6 新的多租户架构 Multitenant 只有多租户容器需要内存和进程 系统资源 6

7 多租户 vs 独立数据库 高效率 : 硬件资源需求降低 6 倍, 扩展性增加 5 倍 OLTP 基准测试比较 50 个数据库时, 内存需求是 3G 比 20G 多租户架构可以扩展到 250 个数据库, 而独立数据库最多到 50 个 7

8 简单的升级 在给数据库打补丁或者升级时可以灵活的选择 8

9 把多个数据库作为一个管理 作为一个数据库做备份 ; 只恢复某个指定 pluggable 数据库 一次备份 恢复指定 pluggable 数据库到特定时间点 9

10 提供管理数据库的多个服务级别 当数据库重要性提高时改变它的服务级别 金 RAC, Data Guard, 每天增量备份 银 Data Guard, 每天增量备份 铜 每周全备份 10

11 CDB PDB 资源管理协同工作 CDB plan 指定分配的 CPU,Exadata I/O,parallel servers 限制 CPU,Exadata I/O 资源的使用 限制 parallel servers 的使用 PDB/Directive Name Shares Utilization Limit Parallel Server Limit (Default Allocation) (1) (100%) (100%) (Autotask Allocation) (-1) (90%) (100%) PDB1 1 30% 50% PDB2 1 30% 80% PDB3 1 30% 30% PDB % 100% PDB1 plan Consumer Group Shares Utilization OLTP 2 100% PDB1 的资源分配情况 : 保证 1/5(20%) 的 CPU 和 Exadata 磁盘带宽 限制最多使用 30% 的 CPU 和 Exadata 磁盘带宽 限制最多使用 50% 的 parallel servers PDB1 中 report 的资源分配 REPORT 1 50% OTHER 1 50% 至少分配 :20%(1/5)*25%(1/4)=5% 的资源 分配限制 :30%*50%=15% 11

12 Oracle Database 12c New Features 高性能 12

13 长达几十年的争论 行格式或列格式 OLTP 在行格式下运行最好 行 Row 插入或者查询一个销售定单 快速处理少量行 许多列 分析在列格式下运行最好 列 Column 销售状态汇总报表 快速访问少量列 许多行 Oracle 12c: 两种数据存储格式并存 13

14 突破 : 行 列双格式的 In-Memory 内存数据库 内存 内存 同一张表在内存中同时支持 行和列两种格式 同时激活并且保持事务一致性 联机事 务处理 Sales 行格式 Sales 列格式 分析 分析和报表使用新的列格式 OLTP OLTP 使用行格式 14

15 Oracle In-Memory 内存列格式技术 非写日志的纯内存格式 内存 近零开销变更 - 甚至是 OLTP 联 机交易应用 新的内存优化的压缩格式 2x~10x 纯列式 活跃的表或分区中的数据被加 载到内存中 在启动或首次访问时 15

16 向量注册 可在亚秒级查找任何业务数据 每个 CPU 扫描本地内存列 示例 : 查找所有加州的销售 内存列存储 性能提升 扫描使用超快速的 SIMD 向量指令 销售 州 列 超过 100 倍 每个 CPU 核心可支持 10 亿 行 / 秒的扫描速度 加州 CA CPU 加载多个州的值 SIMD Compare 在 all 1 个周期内向 values in 量比较所有列值 1 cycle 16

17 亚秒级生成报告 示例 : 显示鞋类产品直销店销售趋势 动态创建内存报表大纲 报表内容在事实扫描过程中 进行填充 商店 销售 在没有预定义的立方体情况 内存报表大纲 下, 报表性能可提升高达 20 倍的速度 产品 销售 Sales 17

18 分析型索引会降低 OLTP 的性能 大多数混合使用 OLTP 数据库 ( 如 ERP) 的索引仅仅用于分析 表 1 到 3 个 OLTP 型索引 5 到 15 个分析型索引 无论是在内存还是磁盘, 索引在已 知的访问模式下工作良好 但是, 维护分析型索引将放缓所有 的数据变化 18

19 分析和极限性能的 OLTP 内存列存储可以替代分析型索引 并消除了表所需要的内存开销 表 1 到 3 个 OLTP 型索引 内存列存储 无论是预定义的, 还是即席分析 查询都运行更快 OLTP 联机事务处理和批处理的运 行速度最高可提升 300% 更少的维护和管理 19

20 工程化设计系统的展示 20

21 Oracle In-Memory 内存选件对应用透明 全部功能 没有 SQL 限制 容易实施 无需迁移数据或改变产品 完全兼容 所有现有的应用程序运行不变 DB 数据库服务就绪 Oracle In-Memory 内存多租户 唯一能够实现所有 In-Memory 内存的好处 而无需改变应用 21

22 您现有的应用程序能够直接运行 最高提升 100 倍性能 22

23 Oracle Database 12c New Features 高可用 23

24 24

25 25

26 全局数据服务 (GDS) 全局数据库资源池 统一的架构 Sales Service Sales Service Sales Global Service Replication Replication 使用集群 ( 服务器池 ) 使用 GDS ( 数据库池 ) 26

27 多个数据库之间的负载均衡 & 故障转移 全局数据服务 - GoldenGate 的例子 在双活配置下, 全局服务可以在 GoldenGate 的所有节 点上启动 Payroll Service 可以在每个数据库启动多个不同的服务 对于冲突避免很 有效 客户连接和请求将被路由至 最近或最合适 的数据 GoldenGate DB 1 DB 2 库 实时负载均衡度量通知客户端, 下一个请求将由哪个数据库进行处理 支持所有类型的 Oracle 连接池 (UCP, WLS, OCI, ODP.NET) 如果一个节点失败, 全局服务将自动在其他节点上启 动 27

28 多个数据库之间的负载均衡 & 故障转移 全局数据服务 Active Data Guard 的例子 更新服务在主节点运行, 查询或报表服务在主节点或 ADG 备用节点运行 更新服务 报表服务 客户连接和请求将被路由至 最适合 的数据库 基于位置, 响应时间, 数据和可接受的数据延迟 查询或报表将自动在最小负载的服务器上运行 Primary Active Data Guard 客户请求失败 如果首选数据库不能使用, 将自动路由至同一区域的其他数据库或远程数据库 服务策略 全局服务自动完成故障切换 如果主数据库出现问题, 自动在备用数据库 ( 新的主数据库 ) 上启动更新服务 全局服务基于策略在其他数据上启动 28

29 临时 Undo 使用临时 undo Stored in Stored in Temporary tablespace User tablespace 临时表 不使用临时 undo 永久表 减少了对 UNDO 段的开销, 并降低了 REDO 的生成, 提高性能 这个特性允许在 Actvie Data Guard 中对临时表进行 DML 操作 进一步提升 ADG 的价值 Temporary Undo Permanent Undo Redo Stored in Temporary tablespace Stored in Undo tablespace Stored in Redo Log Files 29

30 30

31 31

32 应用持续 (Application Continuity) 可靠地重做当前事务 用户在程序界面选择产品并购买 终端用户 应用服务器 网络交换机 如果事务需要重做," 程序持续 " 用户事务到达应用层 会在可用节点上重新运行所有未应用层为应用层的数据库驱动发现数据库此在数据库处产生一个事务 完成事务, 并且提交 对于应用故障, 利用 事务卫士 特性, 来说, 这都是透明的 通过集群中的可用节点, 检查事务是否已经提交还是需要重做 在事务提交到数据库之前, 底层软件 / 硬件发生了故障 数据库服务器 API available for JDBC-Thin, C/C++(OCI/OCCI), ODP.Net 32

33 Oracle Database 12c New Features 可维护性 33

34 12c 中数据生命周期的解决方案 活动跟踪和自动数据优化 数据分级 自动检测 自动执行 What If and When Then Automatically DO Scope - Tablespace-level - Group-level - Segment-level Table/Partition/ Sbupartition Clustered table - Row-level If conditions met 相关的主要技术组件 Which Operation to Heat track? Map ADO - Creation - Access - Modification Advanced Compression In-Database Row Archiving When Partition - After 10 days - After 1 year - Tablespace FULL - Then Actions Compression Move to storage tier Both compression + move... 34

35 自动数据最优化 (Automatic Data Optimization) 为表增加压缩和存储分层的策略 如果分区内数据 180 天没有修改, 就对分区进行列式压缩 如果表空间快满了, 就对最老的分区进行归档压缩, 并且移动到第二层存储 Po licy 1 Po licy 2 Po licy 3 最老的数据 最近的数据 如果数据 30 天没有更改, 就对分区进行行内压缩 35 Copyright 2012, Oracle and/or its affiliates. All rights reserved. 35

36 分区技术的增强 36

37 在线移动分区 在线 Move/Split/Merge 分区和子分区 High cost Storage ( 不需要 DBMS_REDEFINITION) Low cost Storage Move Online SALES 2008,2009 partitions SALES 2008,2009 partitions 在线压缩分区和子分区 Uncompressed High Uncompressed Move Online SALES 2008,2009 partitions SALES 2008,2009 partitions 37

38 在线移动数据文件 存储类型的移动, 比如从文件系统移动到 ASM 或从 ASM 移动到文件系统 File System Storage ASM Storage Move Online ASM Disk ASM Disk ASM Disk Tablespace SALES: 3 data files Tablespace SALES: DiskGroup A ASM Storage File System Storage ASM Disk ASM Disk ASM Disk Move Online Tablespace APP: DiskGroup B Tablespace APP: 3 data files 38

39 增强的实时 ADDM 用于严重性能问题的数据库自我监视 主动问题检测和分析 每 3 秒运行高度轻量级的检查 ( 内存中 无锁 ) 检测到性能低下的趋势时, 触发进一步的分析 对高 CPU 占用 I/O 峰值 内存 互联 挂起和死锁进行分析 在问题威胁到应用程序性能之前将其识别可以在系统级或者会话级启用这个特性 对于当前的峰值, 可以手动触发实时 ADDM 用于短时间 (5 分钟以内 ) 的性能极值, 如影响非常严重的瞬时问题 提供对关键问题的可操作性建议 为分析收集丰富的数据集 在 AWR 中存储用于历史分析的报告和数据 39

40 Oracle Database 12c New Features 安全性 40

41 41

42 提纲 Oracle Database 12c 新特性 Exadata 数据库云平台 - X4 更新简介 数据库容灾 - Active Data Guard 42

43 对比 : 传统架构 vs 一体机架构 传统架构 一体机架构 客户端 客户端 应用平台 应用服务器 ( 多机集群 ) ETL/BI 服务 应用服务器 ( 多机集群 ) ETL/BI 服务 数据库平台 数据库服务器双机热备或集群 SAN 存储交换机 存储阵列 数据库平台以 Oracle Exadata 为例, 包含 : 1. 数据库服务器 2. 交换机 3. 智能存储服务器, 部署 : - CPU Memory - Disk - Flash Cache - Storage Server Software 43

44 按传统架构设计的数据库平台 存在先天的性能瓶颈 Exadata 数据库云平台的设计目标则是做到各 个环节的平衡设计, 消除瓶颈 44

45 存储层 : 一 硬件架构设计的对比 按传统架构设计的数据库平台 60TB 5GB/s 10,000 次 IOPS 存储 100 块硬盘 高端存储阵列可以容纳大于 1000 硬盘, 存储控制器配置只 有 8 至 16 核 CPU 每块硬盘的吞吐量可以达到 150MB/s 或 次 IOPS 硬盘数不足交换机带宽不足 存储控制器不足 14 2GB/s 平均响应时间 :5ms SAN 交换机 2 根 8Gb/s 网络层 : 高端光存储交换机 (SAN) 现在带宽为 4-8Gb/s 通常每台服务器配置多根 SAN 交换机网线 注 :IOPS 指 Oracle 数据库层能够获得的值, 每次 IO 至少 8KB 上述所有数据均来自于客户实际生产 / 测试环境及 TPCC 测试结果 Exadata 存储 生产系统存储 传统磁盘存储 SSD 存储 未来 L1 cache reference HBA 卡不足 数据获取路径时间倍数 Main memory reference 主机层 : 每核 CPU 处理能力约为 MB/s 造成性能瓶颈的典型原因 25GB/s 或 64, ,000 次 IOPS 数据库主机 32 核 CPU 每核 CPU 处理能力至少 100,000 次逻辑读 ( 按 98% 命中率计算, 相当于 2,000 次 IOPS) 0.5 ns 100 ns Native Flash Memory Access 25 µs 1 SSD random read 150 µs 6 SPC:SSD 存储阵列的一次 IO 520 µs 21 SPC:Disk 存储阵列的一次 IO 2310 µs 92 按照 TPCC 公开的测试报告计算, 过去 Disk seek 10 ms 400 每核 CPU 应对应 IOPS 45

46 一 硬件架构设计的对比 Exadata 数据库云平台 ( 以 X4-2 1/8 配为例 ) 21TB(4.8TB) 10.7 GB/s 285,000 次 IOPS 20GB/s 平均响应时间 :0.1ms 15 GB/s 或 240,000 次 IOPS 存储 :3 台 18 块硬盘 6 块 FlashCache 卡 18 核 CPU 存储层 : 每块 FlashCache(800GB) 可以实现 1800MB/s 或 47,000 次 IOPS, 相当于 150 块硬盘的性能 Infiniband 交换机 : 2 台 40Gb/s, 网络层 : 单通道速率为 40Gb/s 每台存储服务器和数据库服务器配置 2 根 Infiniband 网线 ( 冗余 ) 数据库主机 : 2 台, 24 核 CPU 主机层 : 每核 CPU 处理能力约为 MB/s 按照 TPCC 公开的测试报告计算, 每核 CPU 应对应 IOPS 46

47 二 存储层的软件设计导致了根本性的差异 按传统架构设计的数据库平台 60TB 5GB/s 或 10,000 次 IOPS 2GB/s 平均响应时间 :5ms 25GB/s 或 320,000 次 IOPS SELECT cust_last_name, channel_id, SUM(amount_sold) FROM sales s, customers c WHERE s.cust_id = c.cust_id AND c.location in ( CA, NY ) AND s.gender = M GROUP BY c.cust_last_name, s.channel_id ORDER BY SUM(amount_sold); 大量数据被传送到主机端, 其中只有 0.1% 是用户需要的 大量的带宽被用于毫无意义的数据传输, 消耗大量的用户时间 47

48 二 存储层的软件设计导致了根本性的差异 Exadata 数据库云平台 Exadata 智能存储软件的效果 问题 : 昨天的 销售业绩如 何? Exadata 数据库服务器 Select sum(sales) where Date= 24-Sept 构建并发 Smart Scan 请求 未来 Exadata 智能存储层 Smart Scan 在 TB 级数据中 扫描匹配请求的 数据 - Row filtering based on where predicate 数据获取路径时间倍数 L1 cache reference Main memory reference - Column filtering - Join filtering - Incremental backup 0.5 ns filtering - Storage Indexing - Scans on encrypted data 100 ns - Data Mining model scoring Native Flash Memory Access 25 µs 1 SSD random read 150 µs 6 SPC:SSD 存储阵列的一次 IO 520 µs 21 SUM MB51( 物料凭证清单 ) 报表执行情况 : 仅仅返回满足条 件的数据 在客户现有 ERP 系统上执行 :2266 秒, 超过 230,000 次 IO 在 Exadata 上执行 :3.5 秒 SPC:Disk 存储阵列的一次 IO 2310 µs 92 Disk seek 10 ms

49 三 多厂商 vs 单一供应商 = 风险差异 开放 vs 封闭 按传统架构设计的数据库平台 DB & HA/RAC 安装 Volume Mgr File System OS/Cluster 安装调试 Patch Volume Mgr File System OS/Cluster 安装调试 Patch 服务器选型 Sizing 高可用设计 集群实现 性能调优 集成 / 测试 至少几个月 SAN 设计 Patch SAN 兼容性 布线 安装 Patch 存储软件 Patch 部署数据中心多套业务系统 存储软件 存储系统选型 Sizing 兼容性 Layout /RAID 实现 1. 系统兼容性需要长期磨合 ;2. 问题定位诊断周期长 ;3. 软硬件设备型 号多, 维护效率低 ;4. 部署过程遗留较多隐患 49 49

50 三 多厂商 vs 单一供应商 开放 vs 封闭 Exadata 数据库云平台 Exadata 是 Oracle 在数据库领域的 30 年技术积累和专家优化经验统一融合的结晶 迄今为止最平衡设计和最佳性能的数据库平台 所有硬件和软件都来自于 Oracle, 全球统一的规格与版本, 实现最高效的服务 数据库服务器与智能存储服务器都是 X86 服务器, 运行环境为 Linux 或 Solaris 数据库服务器上运行的是标准的 Oracle 11g 数据库软件, 利用传统的工具可以实现与传统平台的数据库之间的平滑迁移 从用户使用角度看, 开放与封闭 的考虑 : Exadata 与传统平台数据库 类似于汽车中的 宝马 与 夏利, 驾驶方式相同 传统的大型机与开放平台的数据库 则类似于 坦克 与 汽车, 驾驶方式存在着巨大差异 50 50

51 Exadata 设计的数据库平台 51

52 X4 研发时间 :2005 年发布时间 :2008 年 全球 : 超过 3000 用户中国 : 超过 300 用户 52

53 Oracle 工程化设计的系统 典型的基础架构 Vendor 工作量大, 集成费用昂贵 不能保证有效协作 不保证有效性能 维护成本高 零碎的服务和支持 意外的事故 Oracle 更多创新, 开放 更好性能, 扩展性, 安全性 更少的部署时间 易于管理和升级 更低的拥有成本 TCO 减少变化管理的风险 一站式支持服务 53

54 Oracle 数据库云服务器 -Exadata 最佳的数据仓库服务器 性能提高 倍 高达 10 倍的数据压缩 数据智能扫描能力 内存数据的并行查询 最佳的 OLTP 系统服务器 性能平均提高 5-20 倍 业界唯一的在真实用户环境中运行的网格数据库 智能闪存缓存提供 20 倍的磁盘 IOPS 能力 归档数据可达 50 倍的压缩能力 安全 容错的架构 最佳的整合服务器, 支持云计算能力 业界唯一能运行所有工作负载的数据库机 在多数据库 多应用 多用户环境下提供可预测的响应时间 Exadata 保留并集成了 Oracle30 年来积累的数据库技术发展的重要成果和优 化经验 54

55 Exadata X4 配置更新 Exadata X4 提供更高的性能和更大的容量 Very Large increase in Flash Capacity Large increases in Disk Capacity Large increases in processor throughput on X4-2 Large increases in InfiniBand throughput on X4-2 Exadata X4 软件 ( ) Flash 缓存自动压缩 支持更多数据库的整合 许多管理功能的提升 更高的可用性保障 55 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

56 Exadata X4 硬件 硬件升级, 但价格不变 X4-2 and X3-8 Database Machines 2X Larger Physical Flash Memory Up to 4X Larger Logical Flash Memory 66% More Flash IOs/sec on X4-2 33% Larger High Capacity Disks 2X Larger High Performance Disks 44 TB of Flash Memory per Rack Smart Flash Cache Compression 2.66M Reads, 1.68M Writes from SQL 4TB SAS Disks 1.2 TB SAS 2.5 Disks (Still 12 per Cell) X4-2 Database Servers 50% More Database Cores 2X Larger DB Server Local Storage 10% 2X to Faster 20% Lower InfiniBand Power 12-Core Xeon IvyBridge E v2 600GB SAS Disks InfiniBand PCI-3 Card. All Ports Active 56 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

57 X4-2 Database Server New 12-core IvyBridge CPUs, Faster InfiniBand Card, Larger Disks Processors Memory Local Disks Disk Controller Network 2 Twelve-Core Intel Xeon E v2 Processors (2.7GHz) 256 GB (16 x 16GB) Expandable to 512GB (16 X 32GB) via memory kits 4 x 600GB 10K RPM SAS Disks (Hot-Swappable) Disk Controller HBA with 512MB Cache Battery Online Replaceable 2 x InfiniBand 4X QDR (40Gb/s) Ports (PCIe 3.0) Both Ports Active 4 x 1GbE/10GbE Base-T Ethernet Ports 2 x 10GbE Ethernet SFP+ Ports (1 Dual-port 10GbE PCIe 2.0 network card based on the Intel GbE Controller technology) Remote Management Power Supplies 1 Ethernet port (ILOM) Redundant Hot-Swappable power supplies and fans 57 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

58 X4-2 Storage Server 6-core IvyBridge CPUs, Larger disks, Larger Flash Cards, Flash Compression Processors Memory Disks Flash Disk Controller Network Remote Management Power Supplies 2 Six-Core Intel Xeon E v2 Processors (2.6 GHz) - Faster clock 96 GB (4 x 8GB + 4 x 16GB) - More memory needed to manage larger flash 12 x 1.2 TB 10K RPM High Performance SAS (hot-swap) 2.5 disk size OR 12 x 4 TB 7.2K RPM High Capacity SAS (hot-swap) 3.5 disk size 4 x 800 GB Sun Flash Accelerator F80 PCIe Cards Hardware Compression Disk Controller HBA with 512MB Cache - Battery Online Replaceable 2 InfiniBand 4X QDR (40Gb/s) Ports (PCIe 3.0) Both Ports Active Embedded Gigabit Ethernet Ports for management connectivity 1 Ethernet port (ILOM) Redundant Hot-Swappable power supplies and fans 58 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

59 Exadata Flash Cache 自动压缩 As always, compression benefits vary based on data Data Type Uncompressed Tables OLTP Compressed Tables Indexes Oracle E-biz uncompressed DB HCC Compressed Tables or Compressed LOBs Typical Compression 1.3X to 4X 1.2X to 2X 1.3X to 4X 3x to 5x Minimal Many OLTP Databases will see 2x Flash Increase X4 with flash cache compression stores up to 80TB of data in flash Up to 4X more than X3 (depending on compressibility of data) 59 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

60 Transactions per Sec Exadata 网络资源管理 Network Resource Management maintains steady performance Exadata Network Resource Management uniquely prioritizes critical database messages through the entire fabric From database to InfiniBand card through InfiniBand switches to storage Latency sensitive messages prioritized over Without Network RM, OLTP performance drops when a network intensive workload is introduced Time DB Version or 12c, Switch batch, reporting, and backup messages Log file writes have highest priority to ensure low latency transactions Combines with Exadata CPU and IO Resource management to ensure safe consolidation of workloads and databases Completely automatic & transparent 60 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

61 提纲 Oracle Database 12c 新特性 Exadata 数据库云平台 - X4 更新简介 数据库容灾 - Active Data Guard 61 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

62 Oracle 活动数据卫士 最佳的数据保护 同步 / 异步 Redo 日志传送 Active Data Guard 备份数据库 基于 Oracle 日志复制的数据库软件容灾方案 保护数据的同时, 保证业务的连续性 备点在线, 可以被用于查询 报表生成, 测试及备份 提升可用性 : 零应用系统宕机时间的自动数据块修复 62 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

63 扩展为 Reader Farm 采用 Oracle Active Data Guard Primary Database ADG 1 ADG 2 L o App 1 SYNC ASYNC ADG 3 a d App 2 B al App 3 ADG 8 a n c ADG 9 e r App n Data Guard Standby Database (Max Availability Mode) Oracle Database 11g Release 1 63 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

64 Data Guard 异步 -11g 之前 发生灾难时有丢失数据的风险 主数据库 异步 ASYNC 备用数据库 64 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

65 Active Data Guard Far Sync 远程同步 12c 操作流程 主数据库 同步 备用数据库 异步 远程同步 实例 65 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

66 Active Data Guard Far Sync 远程同步 12c 操作流程 主数据库 零数据损失 Zero Data Loss 备用数据库 同步 异步 远程同步 实例 无需权衡可用性与性能! No Compromise 66 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

67 Active Data Guard Far Sync 远程同步 12c 不需要在可用性和性能之间折衷 主数据库备用数据库 备用数据库主数据库 异步 同步 远距离同步实例 ( 活动空闲 ) 远距离同步实例 ( 空闲活动 ) 67

68 Active Data Guard Far Sync 远程同步 12c 优势 最佳的数据保护 最小的性能影响 低成本 低复杂性 是实现近程灾难恢复 + 远程灾难恢复模型的最佳方式 与现有 Data Guard 异步配置类似 Data Guard 故障切换? 没问题! 只管去做吧 - 不会丢失数据! 68 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

69 Active Data Guard 实时级联 12c 消除传播延迟 在 11.2 中, 在将重做从存档日志转发到备用数据库 2 之前, 备用数据 库 1 会一直等待日志切换 同步或异步 异步 主数据库备用数据库 1 备用数据库 2 在 12.1 中, 备用数据库 1 会在收到重做时实时将重做转发到备用数据库 2: 没有等待日志切换的延迟 备用数据库 2(Active Data Guard 备用数据库 ) 是最新的, 可供只读查询和报告使用 69 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

70 Data Guard Fast Sync 快速同步 12c 降低对主数据库的影响以实现最高可用性 主数据库 LGWR NSS RFS 备用数据库 对于同步传输 : 在将重做写到备用重做日志 之前, 远程站点会确认收到重做 提交 缩短主数据库上的提交延迟 提交确认 重做日志 备用重做日志 灾难恢复更佳 - 增大了同步距离 如果网络往返延迟时间小于本地联机重做日 志写入时间, 同步传输将不会影响主数据库 确认收到后返回 的性能 主数据库 备用数据库 LGWR NSS RFS 提交 提交确认 重做日志 备用重做日志 70 Copyright 2013, Oracle and/or its affiliates. All rights reserved.

71 71