最近有个客户Oracle RAC （11g）的因为interconnect network网络问题导致脑裂，节点驱逐，恢复后重启，应用有配置TAF，所以出现ORA-25402: 事务必须回滚等，并且有一段时间的连接超时，客户需要了解Reconfiguration过程时间长的原因，发现Oracle 23c 在RAC 的Reconfiguration又做创新如Recovery Buddy和调整reconfig和stop instance顺序，简单记录。
RAC节点的离开或加入集群会导致Reconfiguration（重新配置），这本质上是一个同步事件，用于恢复故障实例所做的所有更改。Oracle RAC 缩短了会话在重新配置期间等待此事件的时间。
在 Oracle RAC 23ai 中，智能重配置利用 Recovery Buddy、PDB、服务隔离和平滑重配置等多种功能，降低了计划内和计划外操作导致的服务中断的影响，从而实现了比以往版本更快的重配置速度。
我们来回顾一下全局资源管理。用户连接到某个 RAC 实例后，可以提交 SQL 语句请求一组数据块。为了捕获数据库数据块，必须分配缓冲区，并且还必须分配主元数据，以便描述这些缓冲区的更改。
系统使用内部算法来决定哪个实例应该包含该实体的主元数据结构。在我们的示例中，主元数据结构分布在实例 1 和实例 2 上。实例启动期间，该实体的主元数据结构信息已持久化到数据字典中，并在实例启动时重用。此外，系统还会管理全局资源，以应对计划外实例崩溃和计划内服务迁移。
PDB和服务隔离
假设有三个PDB——PDB1、PDB2和PDB3。
PDB1 运行在实例 1 上，PDB2 运行在实例 1、实例 2 和实例 3 上。PDB3 也存在于实例 2 和实例 3 中。因此，当您对 PDB1 进行任何更改时，PDB1 拥有的元数据结构仅在实例 1 中可用。
当您对 PDB3 进行任何更改时，PDB3 的主元数据结构将分布到 PDB3 正在运行的所有实例中。在本例中，分布在实例 2 和实例 3 中。接下来，我们来看一下 RAC 的重新配置。
在 RAC 实现中，仅当 PDB1 在实例 2 上打开时才需要重新配置 PDB。例如，最初 PDB1 仅在实例 1 上可用。当您在实例 2 上启动 PDB1 时，主元数据会在实例 1 和实例 2 之间重新分布。
此外，如果 CDB 2 启动，会发生什么？所有在实例 2 上运行的 PDB 都将不可用。因此，保存在实例 2 中的主元数据必须重新分发到其他幸存的实例上，在本例中即实例 1 和实例 2。
只有当 CDB 实例崩溃时 PDB 本身未受影响，或者 PDB1 在实例 2 上打开，或者启动了第四个实例时，影响才会局限于受影响的 PDB。因此，在这些情况下，影响仅限于 PDB 级别。
如果 CDB 2 重启，会发生什么？所有在实例 2 上运行的 PDB 都将不可用。实例 2 中的主元数据必须重新分发到其他幸存的实例上，DB 和服务隔离。这是 CDB 的一项功能，是对面向服务的缓冲区缓存访问的增强。该功能通过减少并非所有 PDB 实例都提供的服务的分布式锁管理器操作来提高性能。
伙伴恢复（Buddy Recovery）
下一个主题是伙伴恢复（Buddy Recovery）功能，用于重新配置。伙伴恢复功能可以减少重新配置期间的等待时间。在之前的版本中，Oracle RAC 实例通过读取REDO重做日志来识别并恢复故障实例所做的更改。
例如，假设实例 1 中的 PDB1 宕机。为了恢复 PDB1 上被大量修改的数据块，幸存的实例之一必须访问 PROD 1 拥有的重做日志文件，然后识别需要恢复的数据块。这属于物理 I/O 操作，非常耗时。
借助恢复伙伴功能，我们可以利用内存日志和恢复伙伴机制来减少 I/O。例如，在三节点直接数据库中，我们实际上会为每个实例分配一个恢复伙伴。例如，PDB1 是 PROD 3 的恢复伙伴，PROD 2 是 PROD 1 的恢复伙伴，PROD 3 是 PROD 2 的恢复伙伴。
这意味着，当您对实例 1（即 PROD 1）中的数据块进行任何更改时，这些更改不仅会直接记录在 PROD 1 中，还会保存在 Recovery Buddy 的内存中（即内存日志）。同样，当您对 PROD 2 进行任何更改时，这些更改不仅会保存在本地，还会保存在 Buddy Recovery 实例中。
举个例子。我们连接到实例 1，像这样请求数据块，然后进行修改。我们像这样进行修改。现在，当您对 PROD 1 进行任何更改时，这些更改不仅会保留在 PROD 1 中，还会保留在 Recovery Buddy 实例中。
因此，如果生产环境 1 发生故障，我们无需访问生产环境 1 拥有的在线重做日志文件，而是可以直接访问 Recovery Buddy 实例中保存的内存日志，并读取该日志以识别需要恢复的数据块。一旦我们识别出需要恢复的数据块并应用更改，系统即可恢复。因此，此功能可减少重新配置所需的时间。
平滑重配置
Oracle Real Application Clusters 实例的平滑重配置可减少集群重配置期间的停机时间。举个例子，假设您运行 srvctl 命令停止实例，在之前的版本中，一旦运行 srvctl stop instance 命令，实例就会立即停止。
此外，在停止实例中保存的元数据重新分发之前，您的数据库将被冻结一段时间，直到全局资源恢复。但是，在 23ai 中，我们对算法稍作修改。因此，您需要请求停止实例。
但是，我们不会立即停止实例，而是先执行资源重编操作。也就是说，我们会在停止实例之前分发元数据。因此，在重新分发实例之后，我们才会真正关闭实例。
例如，当您查看 19c 版本和 23ai 版本之间的差异时，我们会发现我们稍微调整了顺序，从而缩短了集群重新配置所需的时间。在 19c 版本中，一旦您发出停止实例命令（`srvctl stop instance`），您的实例就会被终止并停止。然后，全局资源必须重新配置。因此，在短时间内，您的数据库将无法执行任何操作。
然而，在 23ai 中，当用户请求执行 `srvctl stop instance` 命令时，我们不会直接停止实例，而是先对资源进行重新配置。资源重新配置完成后，我们才能真正关闭实例。这样可以减少重新配置的时间。
此功能会分配资源协调器。资源协调器与主资源、所有者或资源主节点相同，术语相同。因此，在因计划维护而关闭实例之前，我们现在称之为资源协调器。
因此，平滑重配置功能适用于计划内维护，例如用户通过发出用户命令请求执行特定操作时。它还能减少重配置时间，因为无需重新配置资源。所以在关闭系统之前，我们会先重新配置资源，然后再关闭。这样一来，应用程序就能受益于计划内维护操作期间运行时间的缩短。
References
https://aristadba.com/2024/12/smooth-reconfiguration-of-oracle-rac-instancesi-in-23ai