Oracle 12c RAC配物理备库必须启用Active Data Guard许可，并强制满足FORCE LOGGING、STANDBY REDO LOG、REAL-TIME APPLY三项前提，否则open read only后会报ORA-16000且查询延迟不可控。
oracle 12c rac 主库配物理备库，必须用 active data guard 许可，且不能跳过 force logging、standby redo log、real-time apply 这三项硬性前提——缺一即导致只读会话报 ora-16000，或查询结果延迟不可控。
为什么物理备库 open read only 后立即报 ORA-16000
这不是权限或角色问题，而是数据库状态未真正进入“Active Data Guard 就绪态”。物理备库即使 recover managed standby database disconnect 后，若未启用 real-time apply，MRP 进程只应用已归档日志（archived log），而非在线日志（online log）流；此时数据库虽 open read only，但内部仍被标记为“recovering”，拒绝任何 DML（包括隐式写入如序列 nextval、临时表 insert）。
实操要点：
- 主库必须已执行
ALTER DATABASE FORCE LOGGING，且V$DATABASE.FORCE_LOGGING = 'YES' - 备库必须提前添加 standby redo log（SRL），数量 ≥ 主库 online redo log 组数 + 1，大小 ≥ 主库最大日志文件尺寸
- 启动实时应用：执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT（注意是USING CURRENT LOGFILE，不是NOREDO） - 验证是否生效：查
V$MANAGED_STANDBY.PROCESS = 'RFS'和'MRP0'均为APPLYING_LOG，且V$DATAGUARD_STATS.DELAY_MINS = 0
如何确认 RAC 主库归档已正确传到物理备库
RAC 环境下，V$ARCHIVE_DEST_STATUS 按实例返回，单看一个节点的 STATUS = VALID 不代表全部 OK。真正有效的是跨实例聚合视角。
关键检查点：
- 在任意 RAC 节点查：
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID = 2—— 所有实例该行STATUS必须为VALID，ERROR为空 - 查传输延迟：
SELECT VALUE FROM V$DATAGUARD_STATS WHERE NAME = 'transport lag'，值应为+00 00:00:00或极小秒级偏差 - 查应用延迟：
SELECT VALUE FROM V$DATAGUARD_STATS WHERE NAME = 'apply lag'，首次同步后可能达分钟级，稳定后应 ≤ 5 秒 - 勿依赖
ARCHIVED_THREAD#和ARCHIVED_SEQ#，RAC 下它们按线程独立推进，需结合V$LOG_HISTORY对比 SCN
ADG 只读连接连不上？重点盯死 TNS 和服务名注册
常见现象：tnsping 备库服务名通，sqlplus /@standby 能连，但应用连 standby_ro 就超时或报 ORA-12514。本质是监听器没注册只读服务。
必须手动配置静态服务名：
- 在备库
listener.ora中添加静态注册段：SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = standby_ro_DGMGRL)(ORACLE_HOME = /u01/app/oracle/product/12.2.0/dbhome_1)(SID_NAME = stdby))) -
GLOBAL_DBNAME必须为<db_unique_name>_DGMGRL</db_unique_name>格式（如rac_standby_DGMGRL），Broker 和 ADG 客户端都认这个 - tnsnames.ora 中定义
standby_ro时，SERVICE_NAME必须匹配该GLOBAL_DBNAME，不能写SID_NAME或普通 service - 重启监听：
lsnrctl reload，再查lsnrctl services确认输出含service "rac_standby_DGMGRL"
备库 open read only 后查询变慢？别急着调并行
ADG 物理备库的只读性能瓶颈通常不在 SQL 层，而在底层 block 构建逻辑。MRP 应用日志时若遇到 block 需要“前滚构造”（例如主库做了大量直接路径插入），备库首次访问该 block 会触发 on-the-fly reconstruct，造成单次延迟突增。
缓解策略：
- 避免在备库执行全表扫描类操作，尤其对大表；优先走索引路径
- 不建议盲目设
PARALLEL_DEGREE_POLICY = AUTO，ADG 下并行服务器可能争抢 MRP 的 buffer cache 资源 - 确认
DB_BLOCK_CHECKING = OFF（默认值），开启会额外校验 block checksum，加重延迟 - 最有效手段：主库启用
ENABLE BLOCK CHANGE TRACKING，备库自动利用变更位图跳过未改 block，显著降低首次访问延迟
最容易被忽略的一点：RAC 主库所有节点的 LOG_ARCHIVE_DEST_2 必须完全一致，且 VALID_FOR 显式声明为 (ONLINE_LOGFILES,PRIMARY_ROLE)。少一个参数，Broker 就无法统一调度，某节点归档中断，整个 ADG 实时性就断在那儿了。
