adg自动块修复仅针对物理坏块，不修复逻辑坏块；它通过主库读取坏块时实时从同步备库拉取相同文件号和块号的干净物理副本完成热替换，而逻辑坏块因物理校验通过、语义错误无法被同步识别与修复。
adg 不修复逻辑坏块。
Active Data Guard 的自动块修复（auto block repair）仅针对物理坏块，也就是由磁盘 I/O 错误、内存故障、扇区损坏等导致的块校验失败（如 ORA-01578 + 校验和不匹配）。它通过主库读取坏块时，实时从备库拉取同一文件号+块号的干净物理副本完成“热替换”。
逻辑坏块（比如索引结构错乱、ITL 条目损坏、数据块内 row directory 指向非法 offset、或 ORA-00600 中参数落在 [2000, 8000) 区间）不在 ADG 自动修复范围内——因为这类问题块在物理层面是“完好”的（checksum 通过），只是内部逻辑关系断裂。备库同步的是物理块镜像，不是语义校验结果，所以同步过去仍是同样逻辑错误的块。
为什么 SELECT 报 ORA-00600 / ORA-08102 却看不到 replaced from physical standby？
查 alert.log 没有 replaced from physical standby 记录，基本可确认：这不是物理坏块，ADG 根本不会介入。常见逻辑坏块触发场景包括：
- 索引分裂异常后未正确清理分支指针（
ORA-08102） - UPDATE 导致 ITL 插槽溢出且未回滚干净（部分
ORA-00600 [kdxlin]） - NOLOGGING 操作后又在备库上执行了 DML（但备库只读，实际极少发生）
- 使用
DBMS_REPAIR标记跳过坏块后，后续 DML 访问残留结构引发二次崩溃
逻辑坏块该用什么修？
必须人工干预，路径取决于是否有备份、对象类型和影响范围：
- 如果是索引：直接
DROP INDEX+CREATE INDEX（最安全快捷） - 如果是表数据块逻辑损坏（非关键业务表）：用
EXPDP/IMPDP导出有效行，重建表 - 如果有 RMAN 备份且知道坏块时间点：用
RECOVER TABLESPACE ... UNTIL TIME做表空间时间点恢复（TSPITR） - 若无任何备份且不能停业务：尝试
DBMS_REPAIR.CHECK_OBJECT定位损坏行，再用DBMS_REPAIR.SKIP_CORRUPT_BLOCKS临时绕过（数据丢失不可逆）
怎么快速区分物理坏块 vs 逻辑坏块？
看报错组合和底层验证结果：
- 物理坏块典型信号：
ORA-01578+ORA-01110+ alert log 出现 “Corrupt block (file X, block Y)” 且 checksum 验证失败 - 逻辑坏块典型信号：
ORA-00600（第一参数 2xxx~7xxx）、ORA-08102、ORA-01498；RMAN VALIDATE CHECK LOGICAL会报logical corruption；而dd if=/dev/zero of=... conv=notrunc手动破坏块后反而可能触发 ADG 替换 - 验证命令：
SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;只记录物理坏块；逻辑坏块需靠ANALYZE TABLE ... VALIDATE STRUCTURE CASCADE或RMAN VALIDATE显式扫描
ADG 的自动修复能力非常强，但它的边界很清晰：只管“字节对不对”，不管“结构对不对”。一旦怀疑是逻辑问题，别等备库，立刻收 trace、跑 validate、查对象归属——物理层的容错机制，救不了语义层的崩塌。
