ABMR在Oracle 19c中仅修复物理坏块，不处理逻辑坏块；其生效需同时满足四条件：备库open_mode为READ ONLY WITH APPLY、MRP0进程状态为APPLYING_LOG、v$option显示Active Data Guard为TRUE、LOG_ARCHIVE_CONFIG两端均含完整DG名称。
automatic block media recovery（abmr）在 oracle 19c 中不修复逻辑坏块——它只处理物理坏块，且仅在 active data guard（adg）许可启用、备库处于 read only with apply 状态时，对主库或备库上发生的运行时物理坏块自动发起跨库块级拉取与替换。
如果你看到备库报 ORA-01578 并查到 v$database_block_corruption 中类型为 LOGICAL 或 MEDIUM 的坏块，ABMR 不会触发，也无能为力。这是最常被误解的一点。
ABMR 实际生效的前提条件
不是“开了DG就能用”，而是必须同时满足以下四点，缺一不可：
-
v$database.open_mode在备库必须是READ ONLY WITH APPLY（不是READ ONLY，也不是MOUNTED） - 备库后台必须有
MRP0进程且状态为APPLYING_LOG（查v$managed_standby） - 执行
SELECT * FROM v$option WHERE parameter = 'Active Data Guard'返回TRUE（FALSE表示没许可，ABMR 永远不工作） -
LOG_ARCHIVE_CONFIG主备两端都需包含完整 DG 名称，如'DG_CONFIG=(primary_db,standby_db)'；漏掉任一端，ABMR 初始化失败
为什么逻辑坏块无法触发 ABMR
ABMR 的设计目标是应对底层存储层（如磁盘扇区损坏、RAID重构失败、SSD写放大异常）导致的**块内容与校验和不匹配**，即物理层面读取失败。而逻辑坏块（如索引结构错乱、ITL 事务槽损坏、行目录溢出）属于数据库内部一致性破坏，Oracle 无法通过“从另一端拷贝原始块”来解决——因为备库上同一块在逻辑上也可能已损坏（比如归档日志重放过程中就已出错）。
典型逻辑坏块场景包括：
-
ANALYZE TABLE ... VALIDATE STRUCTURE CASCADE报ORA-01498 -
RMAN VALIDATE CHECK LOGICAL发现块头校验通过但行数据解析失败 -
v$database_block_corruption.corruption_type字段值为LOGICAL
逻辑坏块在备库上的正确处理路径
一旦确认是逻辑坏块，ABMR 路径失效，应立即切换到 RMAN 或 DBMS_REPAIR 方案：
- 若备库有可用 RMAN 备份且归档完整：用
BLOCKRECOVER DATAFILE <file#> BLOCK <block#>—— 注意：该命令在备库执行时，目标是修复备库本地坏块，RMAN 会从备份中拉取干净块覆盖，不依赖主库 - 若无备份，且坏块位于非关键对象（如普通用户表）：用
DBMS_REPAIR标记跳过，再通过SELECT /*+ SKIP_CORRUPT */或 ROWID 分段扫描抢救数据 - 若坏块在索引中：直接
DROP INDEX+CREATE INDEX，无需修复块 - 切勿尝试在备库上对 SYSTEM 表空间或回滚段对象使用
BLOCKRECOVER，大概率报ORA-19566或静默跳过
验证 ABMR 是否真在工作，而不是误判
别只看参数，要模拟物理坏块并观察日志：
- 在主库用
dd if=/dev/zero of=<datafile_path> bs=8192 conv=notrunc seek=<block_num> count=1损坏一个物理块 - 立刻在主库执行
SELECT COUNT(*) FROM <table_on_that_file> - 检查主库告警日志：
tail -f $ORACLE_BASE/diag/rdbms/<db_name>/trace/alert_*.log | grep -i "automatic block media recovery" - 看到类似
Automatic block media recovery: requesting block from standby才算真正触发；若只有ORA-01578无后续，说明 ABMR 配置链上某环断裂
逻辑坏块不会产生这类日志，也不会触发任何跨库请求——这是判断是否“误以为 ABMR 可用”的最硬指标。
