ABMR在Oracle 19c中需ADG许可、备库为READ ONLY WITH APPLY且MRP0运行、主备归档与FAL参数正确配置才生效，仅修复永久表空间运行时物理坏块，验证须通过告警日志观察请求痕迹。
automatic block media recovery（abmr）在 oracle 19c 中不是默认开启的“开关”，而是一套依赖严格配置的自动修复机制。它只在 active data guard（adg）许可且正确启用的物理备库上生效，主库或普通 data guard 备库无法触发该能力。
确认 ADG 许可与实时应用是否就绪
ABMR 的前提是备库必须运行在 real-time query 模式 + real-time apply 状态，这二者缺一不可：
-
v$database.open_mode必须是READ ONLY WITH APPLY（不是READ ONLY或MOUNTED） -
v$managed_standby.process中必须存在MRP0进程，且status为APPLYING_LOG - 检查许可证：执行
SELECT * FROM v$option WHERE parameter = 'Active Data Guard';，返回TRUE才表示已启用 ADG 选件 - 若返回
FALSE，即使参数全对，ABMR 也不会工作——这是最常被忽略的前提
主库和备库必须满足的归档与通信参数
ABMR 是双向的，但主备角色对参数要求不同，容易配反：
- 主库发现坏块时，需能向备库发起请求 → 要求主库的
LOG_ARCHIVE_DEST_n显式指向该备库（VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)），且DB_UNIQUE_NAME匹配 - 备库发现坏块时，需能主动连回主库 → 备库必须设置
FAL_SERVER指向主库的DB_UNIQUE_NAME，且主库监听正常、TNS 可解析 -
LOG_ARCHIVE_CONFIG在主备两端都必须包含完整 DG 配置，例如：'DG_CONFIG=(primary_db,standby_db)'；漏掉任一端都会导致 ABMR 初始化失败 - 注意：19c 不再强制要求
LOG_ARCHIVE_DEST_2必须是SYNC，ASYNC也可支持 ABMR，但延迟过高可能影响修复时效
验证 ABMR 是否实际生效的实操方法
不能只看参数，要模拟并观察日志行为：
- 用
dd手动损坏主库某个数据文件的指定块（如知识库中提到的ts2_01.dbf第 139 块），然后执行SELECT COUNT(*) FROM test.adg; - 立即检查主库告警日志：
tail -f $ORACLE_BASE/diag/rdbms/primary_db/trace/alert_primary_db.log，搜索ORA-01578和Automatic block media recovery - 若看到类似
Automatic block media recovery: requesting block from standby，说明 ABMR 已触发；若只有ORA-01578报错无后续，说明配置未生效 - 关键指标：修复过程通常在几秒内完成，且不中断 SQL 执行（用户侧感知为短暂延迟而非报错中断）
常见失效场景与绕过陷阱
ABMR 看似自动，但实际非常“娇气”，以下情况会静默失效：
- 备库处于
READ ONLY模式但未启用REAL-TIME QUERY（即没开 ADG），ABMR 完全不启动 - 主库坏块位于临时表空间、UNDO 表空间或控制文件——ABMR 只修复永久表空间中的数据块
- 损坏块已被缓存在主库 buffer cache 中，且未被刷出；此时首次读取可能仍报错，需清缓存或等 DBWn 刷盘后重试
- RMAN
BACKUP VALIDATE CHECK LOGICAL发现的坏块不会触发 ABMR，它只响应运行时访问（如 SELECT/UPDATE）引发的物理读错误
ABMR 的修复动作本身不记录到 v$database_block_corruption，它发生在内存层面，所以查这个视图永远为空——这点和手动 RECOVER BLOCK 完全不同，容易误判为“没修”。真正要看的是告警日志里的通信痕迹和用户 SQL 是否恢复正常。
