abmr仅支持主库坏块由备库自动修复，不支持备库自身物理坏块的自动修复；因abmr为单向机制，备库遇坏块时mrp0直接报错中断，须人工通过rman块恢复、dbms_repair标记或重建备库处理。
oracle 19c adg 的自动坏块修复（abmr）只在主库发生物理坏块时，由备库提供块拷贝来修复；它不支持备库自身出现物理坏块时的自动修复——这是最常被误解的一点。备库坏块必须人工干预，否则会阻断日志应用或导致查询失败。
为什么备库物理坏块无法被 ABMR 自动修复
ABMR 是单向请求机制：仅当主库读取到损坏块（如 ORA-01578）时，才向已配置的备库发起 Automatic block media recovery: requesting block from standby 请求。备库自身损坏时：
- 备库没有“主动上报坏块并请求主库修复”的能力
-
MRP0进程遇到坏块会直接报错中断（如ORA-00600 [kcbzib_kcrsds_1]或ORA-19505），不再继续应用日志 - 即使主库健康、ADG 许可有效、
FAL_SERVER配置正确，ABMR 也不会触发
备库物理坏块的典型错误现象与定位
发现备库坏块往往不是靠用户查询报错，而是日志应用停滞或告警日志中出现明确 I/O 类错误：
-
ORA-01110: data file/path/to/datafile.dbf—— 文件头或控制文件记录异常 -
ORA-01578: ORACLE data block corrupted (file #X, block #Y) —— 备库自己读到坏块（非主库触发） -
ORA-19505: failed to identify file/path/to/arch_xxx.arc—— 坏块影响归档日志读取 -
v$managed_standby.process = 'MRP0'状态变为ERROR或消失，APPLYING_LOG中断
确认方式：
SELECT process, status, sequence#, block#, blocks FROM v$managed_standby WHERE process = 'MRP0';
修复备库物理坏块的实操路径
没有“自动”选项，只能选以下之一，取决于是否有可用备份和业务容忍度：
-
有 RMAN 全备/增量备份：停
MRP0，用RECOVER DATAFILE X BLOCK Y执行块介质恢复（最快、最安全） -
无备份但需紧急恢复：用
DBMS_REPAIR标记坏块所在段为“跳过”，后续查询将绕过该块（数据丢失不可逆） -
备库完全不可用：直接重建物理备库，使用 19c 新特性
RMAN> RECOVER STANDBY DATABASE FROM SERVICE primary_db;（无需停库，但要求主库归档完整）
注意：ALTER DATABASE OPEN READ ONLY 不能绕过坏块 —— 备库若处于 READ ONLY WITH APPLY 模式下发生坏块，MRP0 仍会因无法读取数据块而失败，强制打开只会掩盖问题。
最容易被忽略的验证点
很多人修完坏块就以为万事大吉，但 ABMR 的“娇气”体现在细节里：
- 修复后必须检查
v$database.open_mode是否仍为READ ONLY WITH APPLY（不是READ ONLY） - 确认
v$managed_standby中MRP0已重新启动且status = APPLYING_LOG -
LOG_ARCHIVE_CONFIG必须在备库端也包含主库DB_UNIQUE_NAME，否则后续主库坏块也无法触发 ABMR - 备库坏块修复本身不会重置主备同步状态，但若曾中断较久，需人工校验
APPLIED_SCN和PRIMARY_SCN差距是否在可接受范围
