最近接到客户电话，咨询如何对ADG备库进行优化的问题，这个客户也是我们的老客户了，数据量庞大（100TB以上），数据库版本为19C RAC ，客户现在遇到备库性能瓶颈，经常发生数据延迟同步的情况（备库最长晚1-2天），备库服务器为X86 rac，性能杠杠的，如何优化备库？
记得内部对oracle19c培训的时候，重点关注的特性里面有一个multi-instance的东东，话说这个新特性我很少使用，大多数业务场景不用上，去新特性网站了解相关信息：Oracle Database Features
https://apex.oracle.com/database-features/
从12.2开始就有这个新特性，译文如下：
介绍：Oracle Database 12.2 之前的版本限制redo应用（物理备用数据库）到 Oracle RAC 备用数据库上的单个实例。 now redo应用可以在用户配置的所有或部分备用实例上运行。 如果需要，可以通过添加额外的备用实例来提升重做应用性能。
业务优势：借助此新功能，可以实现任何主要工作负载的恢复时间目标。 这对于 Oracle Exadata 客户和拥有大型 Oracle RAC 集群的客户尤其重要。 Oracle Active Data Guard 用户还可以实时访问当前信息。 以这种方式扩展应用性能意味着即使最大的 Oracle RAC 集群上的容量非常大，备用数据库也始终是最新的。
其意思就是12.2之前不行，12.2可以干了，在备库所有实例或者指定实例上开启，主要用来提升性能，加速应用。
打开官方文档docs.oracle.com，发现12.2有几个限制:
It has the following restrictions:
The clause is applicable only for Oracle Real Application Clusters (Oracle RAC) or Oracle RAC One Node databases.
Block Change tracking is not supported.
In-Memory column store is not supported with multi-instance redo apply in an Active Data Guard (ADG) environment.
意思是只支持RAC或者RAC ONE NODE ,不支持开了BCT或者使用了in-memory的情况。
19C官方文档解释如下：
To use In-Memory Column Store with multi-instance redo apply in an Active Data Guard environment, set the
enable_imc_with_mirainitialization parameter toTRUE.The following restrictions apply:
The clause is applicable only for Oracle Real Application Clusters (Oracle RAC) or Oracle RAC One Node databases.
You cannot use multi-instance redo apply when you enable
STANDBY NOLOGGING FOR DATA AVAILABILITYorSTANDBY NOLOGGING FOR LOAD PERFORMANCEon the primary database.
如果使用了in-memory列储存，那启用多实例应用需要修改 enable_imc_with_mira=true;
使用条件为rac或one node
不能再主库使用STANDBY NOLOGGING FOR DATA AVAILABILITY or STANDBY NOLOGGING FOR LOAD PERFORMANCE 下使用
这样看19C比起12C在功能上提升不少，那么打开的方式也比较简单：
在备库所有实例中运行（数据库状态为OPEN或者Mount)：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE using current logfile disconnect instances=all;
在备库一个实例中运行（数据库状态为OPEN或者Mount)：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE using current logfile disconnect instances=1;
监控试图为v$recover_progress MRP0
特别要注意：Because recovery processes ship redo among instances, redo apply performance is directly related to network bandwidth and latency.
redo应用性能与网络带宽、延迟有很大关系！
