2022年，为何再谈一次双活ExtendedRAC

好久没发布分享，主要是因为冬天的时候身体有恙，行动不便，难受...

所以等了好久，今天再老生常谈Oracle的RAC双活方案吧~

为啥要谈这“古董”？ 

我上一次参加双活项目估计是5年以前。随着数据库架构逐渐的云化，我一直把双活归类为2代架构的重量级方案。重量级=投资大，架构复杂，投入人力多，运维复杂度增加。

我窃以为该技术已经走入历史，但是原谅我忽略各硬件厂商的努力，存储和网络的发展日新月异。从去年到今天，没想到我还去用户现场讲过双活，客户依然在询问，双活方案对比ADG容灾？双活对比一体机？孰优孰劣？双活的风险在哪里？所以我就一次性，再次回答。

关于双活的技术，请各位翻历史文章，从《VPLEX VS ASM》，当年基本就把双活分析得透彻。另外还有，

如果想听探长，实地探案，请预约：-）

valen.wang@

本文为杂谈，不谈技术细节。

• 双活优点在在于，这个存储的远距离复制，提供了关键作用，双份data，实时保护，实时一致性访问。

• 缺点也在于距离，这个RAC的心跳，跨几十公里，带来了集群性能的下降，集群稳定性的下降，包括写入性能的下降，包括存储cluster和RAC的协作问题等, 计算能力扩展性极差。这一点，我相信在卖的时候，storage vendor是不会深入提及的。
  

双活方案有核心业务的成功的案例吗？有！

凡是对双活架构有充分深入的了解，投入大量的资金，依足双活建设规范，选择正确的实施团队的项目，是有成功案例的。

但在双活实施过程之中，一旦“省”了，那么祈祷神佛保佑，不要发生故障，尤其是站点级故障。恐怕Both alive 变 both dead，这对于DBA们来说，和管理层来说，这是可怕的故障。

先天不足，租用的光纤网络月月不稳定。

实施不足的，应该是被当成是一个普通RAC实施的。

这个故障你说为啥会发生？挖掘机这个不可预测，但是在实施过程中，没有认真评估Oracle双活的数据库版本和补丁，没有按照最佳实践配置，上线前缺乏“数据库双活混沌测试场景测试”，缺乏跨中心故障演练...

极有可能听信片面之词“在我们的设备和软件下，这就是一套普通的RAC安装”，完全不需要专家。

当然也有做的好的

性能，稳定性，都不是问题，而且承载核心业务。GC每秒大于120M，逻辑读大约300w/秒，峰值超过千万，偶尔光纤抖动，个别实例重启，大概一年一次，很少。采购的是商业双活软件，O原厂实施全程参与。

还有一种，建设以后，只承载了一些几乎没有负载的业务。那也好像没啥问题。出了问题，也没啥影响。

还有一种，远程RAC实例只做容灾备用，不启动。曲线容灾， 姑且算事。

❖

随着时间的推移，时空的伴随，我们见到故事是不断在轮回，很多投资大的双活项目下马了，新的双活项目又开始了。存储和网络厂商还在该技术上加码，技术越来越好了，这个技术的发展的确值得关注。

• 那么关键问题，双活架构，在今天，企业也开始逐渐云化的世界里面，还有价值吗？
  

• 或者是Oracle发展到19c，21c，双活这种架构，是更加适配了，还是不兼容了？

以前有一个银行的科技副行长曾经对我感叹过，“行方一定要懂技术，否则就被你们各种牵着鼻子走” ，乙方听了，很囧。

So这里本文讨论双活是站在，专业服务的角度去分析，硬件，软件没有一点利益掺杂，所以尽量给出中肯的建议。

1. 如果核心要上双活，首先认真梳理业务需求，将有双活双中心需求（RTO,RPO=0）的核心数据库部署到双活环境，根据投资的规模，尽量保证资源的冗余，只部署的确有黄金SLA业务需求的核心业务上去。宁可浪费点存储，也要减少些风险。在过去，敢于全核心业务上双活企业，都是时代的先驱，技术上勇者，本探长深表敬意。

2. 如果新系统双活选择的数据库版本是12c，19c，甚至21c，建议规范实施。例如可以参照《O记双活实施规范》，

从：

打造一个稳定可靠的双活数据库系统！

特别是19c数据库，它的设计目标是同一站点里面的数据库云化，跨站点的容灾，推荐的方案还是ADG，通过far sync等方案来实现0数据库丢失，通过DG borker等手段来实现快速切换。但是19c的数据库的进一步优化和发展，它本身的特性优化，就给双活架构带来了改进。

如下图所示：19c RAC主要的提升在于高可用，故障透明，性能提升。其中高可用提升，性能提升，这些代码级的优化都是利于双活。

这里我们简单说几点：

困扰双活的一个问题是GC，集群之间的数据库交换，跨几十公里的数据交换。这个在19c，获得代码的优化，LMS进程粒度更细，不同的进程处理不同队列长度的数据，避免单点阻塞。

亦可以利用PDB+Service做业务隔离，在A站点部署业务1，在B站点部署业务2，既减少了GC，同时业务1,2又获得了几乎等同双中心活动的高可用性。这叫做鱼和熊掌兼得。这就是前面大家可能困惑，为啥双活建议用多租户！

但是，我们说了，官方的目标里面也许双活不是重点，这也是目前几乎没有官方资料的原因。那么我们在19c，谈几个和双活架构，不太匹配的特性。

• TAC，透明应用连续性，故障透明，是云化数据库的关键指标。当运行在A站点的10000个进程要switch over到B站点，而且要不报错，透明接管。这个10000的进程的事务状态，如何正常快速通过几十公里的光纤同步过去。这个，嗯，没验证过？

• 弹性伸缩，又是云化的关键特性，弹性伸缩的关键是高质量的心跳网络，只有在高质量的网络下，比如聚合无损心跳网络，infiniband下，我们可以获得高质量的弹性伸缩。如果是几十公里光纤，出发点就是告诉我们，性能要下降，何谈弹性。
  

• Buddy recovery，通过内存来加速恢复，那么数据库也是从私网传输，这个特性，在双活下，嗯... 还是走redo log吧。
  

等等...

所以在实施双活的过程中，技术特性一定是有取舍的，满足需求为佳，勿贪多嚼不烂，带来隐患。

总之就是两个核心，

第一，做好双活架构和您的投资/业务的抉择， 

第二实施双活架构中，实施团队要对数据库特性的深入了解和规范化实施，

做好后，必然给您的企业带来收益。

复杂架构的实施过程中，人力绝对是最重要的，曾经见过一个医院案例，硬件投资几千万级，实施200w包给某某科技公司。上线后发现，连数据块读本地实例的基本参数都没有设置，这其实就是根本不懂。 故事里面的驱动力太复杂，也是存在即合理。但是希望本文，给所有准备挽起袖子要大搞特搞的DBA，技术经理，CTO一些启发和建议。