基于 Oracle RAC/ADG/OGG 等设计数据库双活方案，必须掌握五方面知识点

访问官网查看更多信息：http://www.hanyunintel.com
1.基于Oracle数据库技术的容灾方案都有那些？各有何优缺点？应该如何去选择适合自己的数据库容灾方案？
容灾向来是以RPO/RTO来定义其级别，所谓的双活只是业内对某种较高容灾级别的架构的俗称，根据不同的角度对其理解也有所偏差。那么基于此，本人暂且认为只要是两个数据中心同时能提供业务服务的就认为是所谓的双活。在这个前提条件下，从Oracle数据库本身的技术来讲，有这么几种方案。
■ 基于跨中心实现的远距离RAC架构。
1）基于ASM冗余设计实现。
2）基于存储集群化之后的分布式存储卷实现。
■ 基于Oracle ADG/OGG 实现的主备库架构。
我们先从大的方案比较：
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又是最佳的选择。
那么撇开成本和风险，只考虑容灾目标的话，我们再来比较一下对于RAC方案的两种不同存储架构的差异：
1)首先是实现难度及投资比较,ASM冗余设计架构的复杂度在于 ASM 层的设计。Oracle RAC 实例节点看到的共享盘是基于双中心存储实现的镜像策略，所有IO的读写分发是由ASM本身的冗余算法规则来决定的，DBA不仅仅要根据磁盘情况来设计合理的 Failure Group，而且需要结合第三方站点的网络存储卷来合理设计仲裁磁盘组的分配。更重要的是需要结合实际的网络环境指标（延时、稳定性等）进行复杂的性能、稳定性、灾难测试等来调整ASM的一些IO参数。基于分布式存储卷设计架构的复杂度在于整体架构的复杂度。
例如仲裁一致性问题，是指双中心之间的存储集群和数据库RAC集群的仲裁结果是否能保证一致性。存储集群是靠仲裁站点分别于两个站点之间的网络连通性来判定站点故障。而数据库集群是通过以太网心跳和OCR仲裁盘来做数据库仲裁。而数据库的OCR仲裁盘是存储集群提供的分布式共享卷。二者仲裁时的一致性如何保障是非常重要的一个问题。假设在发生站点级别故障时，数据库集群首先根据网络故障触发仲裁，判定站点A的节点存活。而存储随后再发生存储集群的仲裁，这个时候如果根据仲裁站点判定的结果恰恰仲裁委站点B的节点存活。那么数据库集群整体就会宕掉，这对于业务来讲就是一个灾难。
2)从实现的基本条件来看，两种架构的实现都会依赖双中心的二层打通。双中心的波分设备、以太转换设备、光纤链路租用就是必不可少的条件了。包括其购置成本和日后的运维成本等。这是非常可观的一项成本预算。从存储层的架构组成来看，ASM冗余设计架构不需要存储层增加任何其他设备成本及运维成本。但是分布式存储卷架构需要依赖存储层的虚拟化网关产品来实现存储虚拟化集群，无疑这需要增加相应的购置成本和相应的运维成本。尤其注意存储集群产品是否有容量许可成本问题。从第三点的仲裁站点成本来看，两种方案都需要第三点的仲裁，区别在于ASM冗余设计架构需要的是NAS存储，而分布式存储卷架构需要的基于以太网的计算资源来配置仲裁虚拟机。投入成本没有什么差异。
3)从Oracle运维成本来看，ASM冗余设计架构对DBA的要求非常苛刻，需要DBA不仅仅能够深知其中的原理，而且需要对性能的分析有较深的造诣，从而保障在复杂的双中心联动环境下各种复杂情况下的性能及稳定性变动有快速和准确的判断和处理能力。分布式存储卷架构对DBA的要求没有特殊的苛刻要求但是需要增加对存储集群的专业维护成本。
从银行业的角度来看，行业看中的更多的是RPO和RTO以及风险度本身这几个点。
从RPO和RTO角度来选的话，那么方案一定是RAC的方案。但是从风险角度来考虑的话，那么ADG会是比较好的选择。OGG主要用于异构平台之间的数据传输。但是这几中方案并不是只能选择其中一种而舍弃其他的方案。方案各有优劣，为了尽可能达到整体最优，可以考虑方案的组合。
比如说同城实现RAC、异地实现ADG。或者在RAC基础之上再增加一个ADG。成本上没有太大的改变，但是保险系数上却增加了很多。
OGG可以考虑到特殊业务场合，比如说为了搭建数据平台实现不同数据库数据的整合等。

2.基于ORACLE RAC/ADG 双活方案实施，难点和关键点是什么？如何解决？
1）针对分布式存储卷架构的仲裁一致性问题
在这个问题上，风险发生的引发点有两个：数据库和集群的仲裁触发以及仲裁过程的时间顺序发生紊乱；资源被1:1割裂之后的默认仲裁策略不一致。也就是说，只要控制这两个引发点，那么这个问题从理论上也就避免了。对于第一个引发点来讲，实际上存储集群的默认仲裁触发时间会是15秒左右，而数据库仲裁触发的控制参数由misscount这个参数来决定，所以只要我们将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这种策略，仅仅利用它的镜像聚合，而舍弃它的灵活伸缩特性。

3. 基于ASM冗余设计架构实现的数据库双活方案，如何规划ASM？
   ASM使用独特的镜像算法：不镜像磁盘，而是镜像盘区。作为结果，为了在产生故障时提供连续的保护，只需要磁盘组中的空间容量，而不需要预备一个热备(hot spare)磁盘。不建议用户创建不同尺寸的故障组，因为这将会导致在分配辅助盘区时产生问题。ASM将文件的主盘区分配给磁盘组中的一个磁盘时，它会将该盘区的镜像副本分配给磁盘组中的另一个磁盘。给定磁盘上的主盘区将在磁盘组中的某个伙伴磁盘上具有各自的镜像盘区。ASM确保主盘区和其镜像副本不会驻留在相同的故障组中。
   磁盘组的冗余可以有如下的形式：双向镜像文件(至少需要两个故障组)的普通冗余(默认冗余)和使用三向镜像(至少需要3个故障组)提供较高保护程度的高冗余。 一旦创建磁盘组，就不可以改变它的冗余级别。为了改变磁盘组的冗余，必须创建具有适当冗余的另一个磁盘组，然后必须使用RMAN还原或DBMS_FILE_TRANSFER将数据文件移动到这个新创建的磁盘组。三种不同的冗余方式如下：
   1、 外部冗余（external redundancy）：表示Oracle不帮你管理镜像，功能由外部存储系统实现，比如通过RAID技术；有效磁盘空间是所有磁盘设备空间的大小之和。
   2、 默认冗余（normal redundancy）：表示Oracle提供2份镜像来保护数据，有效磁盘空间是所有磁盘设备大小之和的1/2 （使用最多）
   3、 高度冗余（high redundancy）：表示Oracle提供3份镜像来保护数据，以提高性能和数据的安全，最少需要三块磁盘（三个failure group）；有效磁盘空间是所有磁盘设备大小之和的1/3，虽然冗余级别高了，但是硬件的代价也最高。
   至于如何选择，不言而喻。
   一个简单的案例：
   A中心存储的LUN在系统上看到的设备文件名叫： hdisk1,hdisk2,100G hdisk3,hdisk4,20G, hdisk5,1G
   B中心存储的LUN在系统上看到的设备文件名叫： hdisk6,hdisk7,100G hdisk8,hdisk9,20G, hdisk10,1G
   仲裁中心的LUN在系统上看到的文件名叫：hdisk11,1G
   DATA磁盘组： 规划两个failuregroup：
   failuregroup1=(hdisk1,hdisk2) failuregroup2=(hdisk6,hdisk7)
   策略=normal
   FRA磁盘组：规划两个failuregroup：
   failuregroup1=(hdisk3,hdisk4) failuregroup2=(hdisk8,hdisk9)
   策略=normal
   OCR磁盘组：
   hdisk5,hdisk10,hdisk11

4. ADG&OGG的优缺点是什么？各自应用的场合是什么？DG实施的注意点有哪些？
   ADG 同构平台数据同步，OGG可以异构平台数据同步。
   ADG 用在容灾场合，可以同城、可以异地。OGG一般用在异构平台迁移场合。
   ADG 相对比较稳定，OGG 相比而言问题多一些。
   ADG 架构可以灵活组合，OGG 架构相对会单一。
   ADG 可以通过快照方式保留当前时刻点数据，OGG不能做到。
   ADG：五级容灾目标场合下的数据库主备切换架构。
   OGG：数据平台的建设或者是异构数据库之间的集中整合或者是同步。
   在金融行业，常见的容灾架构为ADG，尤其是异地灾备。也有部分较高要求的采用 RAC + ADG，这里的RAC有的是基于存储集群虚拟出来的分布式卷之上做的RAC，有的是通过ASM冗余设计本身实现的。OGG在重大变更需要异构数据库同步数据的场合下或者是金融行业的数据集中平台上采用。
   ADG，最常用的同城，异地灾备解决方案，物理级备份，备机不可写，传输数据为所有redo日志的更改，数据量稍大，不过从以往的使用经验来看，也不太会影响网络，除非应用对网络有很苛刻的要求，即使有，也可以通过vlan或者路由或者多网卡的方法特别建立网络通道，主备库完全一致，缺点是必须全库备份。OGG，DSG这两个是一个类型的，逻辑备份，主要采用特有的技术从联机日志中抽取更改项应用到备库，主备库为两个库，可以全库同步也可以同步单张表或数张表，同步速度较快，传输数据量很少，DML操作和DDL操作均支持。

5. 在 Oracle RAC 双活方案落地之前，我们应该做那些测试？应该模拟那些灾难故障？
   观点一：
   最重要的是压力测试，尤其要测试两个节点之间的热点可以承受到什么样的水平。然后就是故障测试，模拟单中心故障、链路故障、以太设备故障、节点故障、网卡故障、仲裁故障等各种条件下是否能如预期实现。
   观点二：
   测试无非就是设备的测试和应用的测试，这块都差不多，尽可能的压到最大的阀值。
   至于灾难故障的话，双活的最大故障就是一个中心完全不可用，模拟一个数据中心全部宕机，当然还有一些其他的单设备或者单应用的测试，虽然操作起来有一定的风险，不过还是值得的。