ABMR在Oracle 19c备库需同时满足ADG许可、READ ONLY WITH APPLY模式及MRP0进程运行、主备双向归档与通信参数对齐三条件才生效，缺一即静默失效，须通过dd模拟坏块并验证告警日志确认。
abmr（automatic block media recovery）在 oracle 19c 备库上不是开个参数就能用的功能，它依赖 adg 许可、实时应用状态、主备通信链路三者同时就位。缺一不可，配错一个就静默失效。
确认 Active Data Guard 许可与备库实时应用状态
ABMR 只在物理备库启用 ADG 且处于 READ ONLY WITH 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才表示许可已激活；FALSE时所有 ABMR 配置都白搭，这是最常被跳过的检查点
主备两端归档与通信参数必须双向对齐
ABMR 是双向请求机制：主库坏块找备库要块，备库坏块找主库要块。参数配反或漏配会导致请求发不出、收不到。
- 主库侧：必须有
LOG_ARCHIVE_DEST_n显式指向该备库，且VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，DB_UNIQUE_NAME必须匹配备库的DB_UNIQUE_NAME - 备库侧：必须设置
FAL_SERVER指向主库的DB_UNIQUE_NAME，且主库监听正常、TNS 名可解析 - 主备两端都要配置
LOG_ARCHIVE_CONFIG，例如'DG_CONFIG=(primary_db,standby_db)'—— 少写一个名字，ABMR 初始化就失败 -
LOG_ARCHIVE_DEST_2不再强制要求SYNC，ASYNC也可支持 ABMR，但延迟过高（如 >30 秒）可能导致修复超时或用户感知卡顿
验证 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才算成功触发；只有ORA-01578报错而无后续，说明配置未生效 - 修复过程通常在几秒内完成，SQL 不中断——用户侧表现为短暂延迟，而非报错退出
ABMR 只修永久表空间的运行时物理坏块
它不处理逻辑坏块、不修临时/撤销表空间、不覆盖 SYSTEM 表空间关键字典块。别指望它解决所有坏块问题。
- 仅限永久表空间（
PERMANENT）中发生的运行时物理坏块（如磁盘 I/O 错误、存储层位翻转） - 逻辑坏块（如索引结构损坏、块头校验码错但内容可读）需走
BLOCKRECOVER，且前提是 RMAN 有含该块的备份 - SYSTEM 表空间中部分数据字典块（如
obj$、tab$的根块）ABMR 不支持修复，会跳过或报ORA-19566 - 如果坏块来自备库本地存储故障（如 ASM diskgroup 不一致、OS 磁盘坏道），ABMR 无法修复——它只换块，不修硬件
ABMR 看似自动，实则极其敏感：许可没开、MRP0 没跑、FAL_SERVER 写错、LOG_ARCHIVE_CONFIG 漏名，任一环节出问题都会静默失效，连错误都不报。真正上线前，必须用 dd 模拟坏块 + 日志抓取双重验证，不能只看参数和视图返回值。
