ORA-19566是Oracle主动熔断机制，非备份故障，源于读到坏块后按maxcorrupt=0中止；需先查v$database_block_corruption定位坏块类型，再分物理（需硬件介入+恢复）或逻辑（可在线修复）处理，严禁盲目调高maxcorrupt。
RMAN本身不生成修复建议，只精准定位坏块位置；所谓“建议”必须靠人工结合V$DATABASE_BLOCK_CORRUPTION、DBA_EXTENTS和坏块类型判断，不能依赖RMAN自动输出。
VALIDATE CHECK LOGICAL 是唯一能发现逻辑坏块的校验方式
默认的VALIDATE DATABASE只做物理校验（如块头checksum），对行目录错位、ITL损坏、索引键与表行不匹配等逻辑问题完全无感。必须显式加上CHECK LOGICAL参数才触发深度结构扫描。
- 命令必须写成
VALIDATE DATABASE CHECK LOGICAL或VALIDATE TABLESPACE users CHECK LOGICAL，漏掉CHECK LOGICAL等于白跑 - Oracle 11.2.0.4之前版本对
CHECK LOGICAL支持不稳定，易漏报或误报ORA-01200，生产环境务必确认版本 - 该操作CPU开销大（比默认校验高3–5倍），别在业务高峰执行；若库大，优先用
VALIDATE DATAFILE 4 CHECK LOGICAL缩小范围 - 校验结果不会直接打印坏块位置，必须紧接着运行
LIST FAILURE，再查alert.log找ORA-01578行里的file #和block #
坏块定位后，靠两个视图关联出具体对象
拿到file #和block #后，不能靠DBMS_ROWID构造ROWID反查——逻辑坏块下ROWID可能已指向非法offset，查出来是空或错表。
- 先查
V$DATABASE_BLOCK_CORRUPTION确认类型：CORRUPT（物理）、FRACTURED（块头尾不一致）、LOGICAL（结构错乱） - 用
DBA_EXTENTS定位段：SELECT owner, segment_type, segment_name FROM dba_extents WHERE file_id = &file_num AND &block_num BETWEEN block_id AND block_id + blocks - 1; - 再连
DBA_OBJECTS确认对象号：SELECT object_name, object_type FROM dba_objects WHERE object_id = &object_id; - 如果是
NOLOGGING操作导致的坏块（12c+查V$NONLOGGED_BLOCK），修复路径完全不同：需从主库拉增量备份，不能直接BLOCKRECOVER
BLOCKRECOVER 不是修复命令，而是“覆盖还原”动作
BLOCKRECOVER本质是从备份里把指定块拉出来，覆盖当前损坏块。它不理解业务逻辑，也不校验覆盖后是否真能用。
- 语法必须带完整定位：
BLOCKRECOVER DATAFILE 4 BLOCK 123;，不能写BLOCKRECOVER TABLE livan.test——RMAN根本不认表名 - 执行前必须确认该块在备份中是干净的：
LIST BACKUP OF DATAFILE 4;查最近一次备份时间，再比对V$DATABASE_BLOCK_CORRUPTION里CORRUPTION_CHANGE#SCN是否早于备份SCN - 若报
no backup of block found，说明所有可用备份都含此坏块，此时BLOCKRECOVER失效，只能走DBMS_REPAIR跳过或导出重建 - 修复后必须手动
CHECKPOINT并立刻VALIDATE DATAFILE 4 CHECK LOGICAL验证，否则buffer cache里旧脏块可能继续返回错误
真正容易被忽略的是：VALIDATE CHECK LOGICAL只检查当前SCN下已刷盘的数据块，对刚修改未提交、还在buffer cache里的脏块不生效。应用报ORA-00600 [kdxlin: invalid rowid]但校验通过，大概率就是这个原因。
