DG、ADG、OGG的解析

以oracle 11G版本为准进行解析
Data Guard Architecture Overview (Data Guard架构概述)
Data Guard provides the management, monitoring, and automation software to create and maintain one or more synchronized copies of a production database to protect Oracle data from failures, disasters, human error, and data corruptions while providing high availability for mission critical applications. Data Guard is included with Oracle Database Enterprise Edition.
Data Guard提供管理，监视和自动化软件，用于建立和维护生产数据库的一个或多个同步副本，以保护Oracle数据免受故障，灾难，人为错误和数据损坏，同时为关键任务应用程序提供高可用性。 Data Guard包含在Oracle数据库企业版中。
Active Data Guard Functionality Overview (Active Data Guard功能概述）
Active Data Guard is an option license for Oracle Database Enterprise Edition. Active Data Guard enables advanced capabilities that that extend basic Data Guard functionality. These include:css

Real-Time Query - offload read-only workloads to an up-to-date standby database算法

Automatic Block Repair - automatic repair of physical corruption transparent to the user数据库

Far Sync - zero data loss protection across any distance后端

Standby Block Change Tracking - enable incremental backups on an active standby缓存

Active Data Guard Rolling Upgrade - make it simple to reduce planned downtime安全

Global Database Services - load balancing and service management across replicated databases. See Global Data Services网络

Application Continuity - make outages transparent to users. See Application Continuity
Active Data Guard是Oracle数据库企业版的选件许可证。 Active Data Guard支持扩展基本Data Guard功能的高级功能。 这些包括：架构

实时查询 - 负责将主库最新的数据刷新到物理备库oracle

自动块修复 - 自动修复对坏的数据块进行修复app

远程同步 - 任何状况下的主备同步，实现零数据丢失保护。

备库开启块跟踪 - 在备库开启块跟踪，实现备用数据库上启用增量备份。

Active Data Guard滚动升级 - 简化计划停机时间

全局数据库服务 - 跨复制数据库的负载平衡和服务管理。 请参阅 全球数据服务

应用程序连续性 - 使中断对用户透明。 请参阅 应用程序连续性 （应用程序连续性（AC）是Oracle Real Application Clusters（RAC），Oracle RAC One Node和Oracle Active Data Guard选项的一项功能，可经过在可恢复的中断后恢复正在进行的数据库会话来屏蔽最终用户和应用程序的中断。 应用程序连续性经过在中断后恢复受影响的数据库会话的正在进行的工做来屏蔽最终用户和应用程序的中断。 应用程序连续性在应用程序下执行此恢复，以便中断在应用程序中显示为略微延迟的执行。
应用程序连续性用于在处理意外中断和计划维护时改善用户体验。 应用程序连续性加强了使用Oracle数据库的系统和应用程序的容错能力。）

Oracle GoldenGate（OGG）：
是一个实现异构IT环境间数据实时数据集成和复制的综合软件包。该产品集支持高可用性解决方案，实时数据集成，事务更改数据捕获，运营和分析企业系统之间的数据复制，转换和验证.Oracle GoldenGate 12 c经过简化配置和管理，增强与Oracle数据库的集成，支持云环境，扩展异构性以及加强安全性，实现了高性能。

除了用于实时数据移动的Oracle GoldenGate核心平台，Oracle还提供了适用于Oracle GoldenGate的管理包（用于Oracle GoldenGate部署的可视化的管理和监视解决方案）和Oracle GoldenGate Veridata（容许在两个正在使用的数据库之间进行高速，海量的比较）。

表格对比总结

ADG最大的特色仍是能作到同步复制，而OGG的数据复制在亚秒级，仍是只能算做异步复制。

2、应用场景分析
DG能够用在容灾测试上，在金融、电力、能源行业，生产上常见的容灾架构为ADG，尤为是异地灾备。也有部分较高要求的采用 RAC + ADG，这里的RAC有的是基于存储集群虚拟出来的分布式卷之上作的RAC，有的是经过ASM冗余设计自己实现的。OGG在重大变动须要异构数据库同步数据的场合下或者是数据集中平台上采用。

ADG，最经常使用的同城，异地灾备解决方案，物理级备份，备机不可写，传输数据为全部redo日志的更改，数据量稍大，不过从以往的使用经验来看，也不太会影响网络，除非应用对网络有很苛刻的要求，即便有，也能够经过vlan或者路由或者多网卡的方法特别创建网络通道，主备库彻底一致，缺点是必须全库备份。OGG，DSG这两个是一个类型的，逻辑备份，主要采用特有的技术从联机日志中抽取更改项应用到备库，主备库为两个库，能够全库同步也能够同步单张表或数张表，同步速度较快，传输数据量不多，DML操做和DDL操做均支持。

ADG 同构平台数据同步，OGG能够异构平台数据同步。
ADG 能够经过快照方式保留当前时刻点数据，OGG不能作到。
ADG 直接经过日志重作实现数据复制，OGG是经过对日志加工以后的模式进行数据分析实现复制。

3、 RAC + ADG双活解决方案的难点和关键点是什么？如何解决？
1）针对分布式存储卷架构的仲裁一致性问题

在这个问题上，风险发生的引起点有两个：数据库和集群的仲裁触发以及仲裁过程的时间顺序发生紊乱；资源被1:1割裂以后的默认仲裁策略不一致。也就是说，只要控制这两个引起点，那么这个问题从理论上也就避免了。对于第一个引起点来说，实际上存储集群的默认仲裁触发时间会是15秒左右，而数据库仲裁触发的控制参数由misscount（默认30秒）这个参数来决定，因此只要咱们将misscount这个参数调整到45秒以后，也就是说理论上绝对保障存储集群仲裁在前，而数据库仲裁在后，那么第一个引起点就没有了。对于第二个引起点来说，假设两站点节点资源对等，仲裁选票一样对等的状况下，存储集群会有一个默认的Winner策略，一样在这种状况下数据库集群也有一个默认仲裁策略：选择实例号小的集群存活。只要咱们保证这两个策略结果的一致性，那么第二个引起点也就不存在了。

2）链路稳定情况不可控

这个问题是两种架构都面临的问题。主要表现为两个方面：链路稳定情况不可控；延时指标不可控。由于双中心之间的链路是经过租用运营商的裸光纤链路实现的，那么这其中会经历不少的中继设备及节点。不管从管理上仍是从技术把控上都是金融企业自身不可控制的因素。假设双中心间链路延时指标不稳定，也就是说数据库节点之间私网传输的延时会常常出现长延时状况，这势必致使这种延时会加倍放大到数据库节点之间的读写热点竞争上。因为数据库集群之间的数据传输量很是大（缓存、锁、心跳等），在读写热点相对突出的业务上，轻则致使数据库读写性能灾难，重则致使数据库节点直接处于僵死状态。另外，链路的不稳定会致使存储链路频繁切换，甚至会致使集群仲裁频繁发生，这对于业务连续性更是一个灾难。

对于这个问题来说，就目前金融、电力、能源行业的传统数据架构来说，并无一个十足的解决方案。咱们只能经过如下措施来减小这种问题带给咱们的风险。

i、业务层面须要进行拆分重组：按照IO特色进行合理拆分，将读写业务尽可能分布于不一样节点上，减小节点间的锁竞争。按照业务将数据库表进行分区，避免在数据库写上的数据热点块儿。例如，对于银行核心系统来说，尤为是要将批量业务和联机业务区分对待，批量业务的热点以及数据量很是之巨大，因此必定要将批量业务的数据库读写放在单边实现。对于联机业务来说能够根据热点情况以及链路质量评测结果能够尝试实现双中心同时读写，可是本文建议对于这种重量级的业务仍是要从业务层尽可能实现应用上的读写分离，或者在应用层双中心部署而在数据库层将数据引到单边来作。

ii、双中心间通信的总体控制，具体包括对通信带宽的优先级管理、对通信的实时监控和控制、对跨中心数据传输的严格策略把控。例如：优先保障存储和数据库通信的优先级和带宽，严格的规则算法和优先级限定VMOTION、DRS等行为的跨中心随意性，从LTM负载分发上尽量保障正常状况下纵向IO的单中心效率策略，故障状况下保障跨中心访问的科学性。DWDM上设置双中心间通信带宽的逻辑隔离以及实时可控。

3）存储网络故障泛滥

这是两种架构都会面临的问题，只是ASM冗余设计架构可能性相对高一些。

若是咱们把两个中心的SAN环境整合为一张大网，物理上没有任何隔离的大网，那么可能会由于局部的存储网络故障而波及到整个存储网络。尽管咱们经过SAN交换机上的逻辑隔离可以解决大部分的安全问题，可是这样的风险毕竟仍是存在的。

因此咱们能够经过对数据中心内部SAN环境先后物理隔离，双中心之间靠专注SAN交换机实现存储后端网络的联通来解决该问题。这样的话，单中心内前段SAN环境故障不会波及存储后端，更不会波及整个基础架构的存储网络。

4）串联深度带来的性能问题

这个问题是针对分布式存储卷架构的问题。

架构深度越深，那么IO的性能就会越差，由于IO每通过一层设备就会有必定的延时消耗，纵向深度越深经历的设备越多，那么IO的延时也就越高。若是咱们的架构在纵向上越复杂，那么这个问题应该说从本质上是没法消除的，只能经过必定的方法来减小和优化。

从存储层来看，通常存储侧在对物理卷进行虚拟化的时候都会有几种策略。为了增长管理的灵活性及扩展性，虚拟化的时候可能会通过多层映射。另一种策略是为了提升性能，在虚拟化的时候尽可能较少映射。咱们在规划存储卷的时候，尽可能采用后一种策略。例如VPLEX就会有（1:1map、Raid等策略），咱们能够选择1:1map这种策略，仅仅利用它的镜像聚合，而舍弃它的灵活伸缩特性。

4、从RPO和RTO角度来看RAC和ADG

1)从RPO角度来看，RAC方案能够作到理论上的绝对同步。ADG能够作到近似同步，可是通常用在异步场合。

2)从RTO角度来看，RAC方案能够作到理论上的秒级自动故障转移。ADG通常须要人工去实现备库切换，并且须要应用改变链接IP地址，从新启动。

3)从风险角度来看，RAC方案一旦实现距离拉伸，最大的风险在于远距离光纤条件下的节点之间的数据交互。而ADG方案就没有该风险存在。

4)从方案的复杂度来看，RAC方案理论上须要第三点的仲裁，须要双中心二层打通等复杂环境条件。而ADG和OGG方案只须要网络三层可达便可。

5)从投资成原本看，RAC方案实现距离的拉伸以后，须要的环境成本（网络条件、仲裁条件）等都须要较高的成本。ADG和OGG方案没有这些成本。

由此能够看出，实际上从容灾角度考虑（RTO/RPO）,那么RAC方案必定是比ADG方案能实现RTO和RPO的更高目标，可是从成本和风险角度考虑，ADG又是最佳的选择。

补充：
Oracle 网络&磁盘心跳机制
网络心跳
网络心跳（Network Hearbeat）是RAC的内部通讯机制，每隔一秒钟，CSSD的一个线程（sending进程）发送一个TCP网络心跳包给本身和集群中的其余节点，同时CSSD的另一个进程（receiving进程）接收到心跳。若是网络传输包被drop或者出现错误，那么TCP的错误纠正机制会重传这个数据包，Oracle在这种场景下不参与网络包的重传。若是一个节点在15秒（50% of misscount）内都接收不到来自其它节点的心跳信息，那么在CSSD日志中会发现关于心跳丢失的“WARNING”信息。一样当该节点在22秒（75% of misscount）以及在27秒（90% of misscount）都没有接收到其余节点的心跳信息时，在CSSD日志中会依次发生警告。一直到30秒（Oracle 默认是30秒，可调节）为心跳丢失的完整周期，该节点会被驱逐。
磁盘心跳
磁盘心跳（Disk Heartbeat)是发生在集群间以及仲裁盘间的心跳。每一个RAC节点中的CSSD进程会在仲裁盘（voting disk）上面经过读写方式进行磁盘心跳维护，经过调用操做系统层pread/pwrite进程对1个操做系统block块进行必定偏移量的读写操做。除了维护本身的磁盘心跳（读写磁盘的偏移块），CSSD进程还会监控集群中其余节点CSSD进程维护的磁盘心跳。/这个不断被刷新的数据库头部记录节点名称和计数位，该计数位会在发生心跳探测时被集群中其余节点刷新（经过pwrite）。磁盘心跳是经过CSSD进程维护在心跳盘（vote disk）上面，若是存在某一节点因为IO超时没有刷新磁盘心跳，那么该节点会被宣布死掉。若是一个节点处于未知状态，没有真正的死掉，可是没有在存活的群组里，那么该节点会被驱逐，该节点会被在vote磁盘磁盘上更新为kill，被驱逐掉。
总而言之，网络心跳每秒钟会相互ping一次，集群节点必须在css_miscount（默认值是30s）设置的时间内响应，若是规定时间内未响应，则会致使被驱逐。同时，对于磁盘心跳，每秒钟集群节点会经过vote盘读写进行集群通讯，节点必须在disk timeout时间内响应。

补充：基于ASM冗余设计架构实现的数据库双活方案，如何规划ASM？
ASM使用独特的镜像算法：不镜像磁盘，而是镜像盘区。做为结果，为了在产生故障时提供连续的保护，只须要磁盘组中的空间容量，而不须要预备一个热备(hot spare)磁盘。不建议用户建立不一样尺寸的故障组，由于这将会致使在分配辅助盘区时产生问题。ASM将文件的主盘区分配给磁盘组中的一个磁盘时，它会将该盘区的镜像副本分配给磁盘组中的另外一个磁盘。给定磁盘上的主盘区将在磁盘组中的某个伙伴磁盘上具备各自的镜像盘区。ASM确保主盘区和其镜像副本不会驻留在相同的故障组中。

磁盘组的冗余能够有以下的形式：双向镜像文件(至少须要两个故障组)的普通冗余(默认冗余)和使用三向镜像(至少须要3个故障组)提供较高保护程度的高冗余。 一旦建立磁盘组，就不能够改变它的冗余级别。为了改变磁盘组的冗余，必须建立具备适当冗余的另外一个磁盘组，而后必须使用RMAN还原或DBMS_FILE_TRANSFER将数据文件移动到这个新建立的磁盘组。三种不一样的冗余方式以下：

一、 外部冗余（external redundancy）：表示Oracle不帮你管理镜像，功能由外部存储系统实现，好比经过RAID技术；有效磁盘空间是全部磁盘设备空间的大小之和。

二、 默认冗余（normal redundancy）：表示Oracle提供2份镜像来保护数据，有效磁盘空间是全部磁盘设备大小之和的1/2 （使用最多）

三、 高度冗余（high redundancy）：表示Oracle提供3份镜像来保护数据，以提升性能和数据的安全，最少须要三块磁盘（三个failure group）；有效磁盘空间是全部磁盘设备大小之和的1/3，虽然冗余级别高了，可是硬件的代价也最高。