RMAN VALIDATE 默认仅做物理校验，需显式加 CHECK LOGICAL 才检查逻辑坏块；跳过未格式化块、脏页缓存块及 NOLOGGING 导致的 soft corrupt；V$DATABASE_BLOCK_CORRUPTION 非实时，应主动重跑带 CHECK LOGICAL 的 VALIDATE 并结合 dbv 或 ANALYZE 验证。
RMAN VALIDATE 默认只做物理校验，不查逻辑坏块
执行 VALIDATE DATABASE 或 VALIDATE DATAFILE 3 却没报错，不代表数据块完好——它默认只验证块头 checksum、文件可读性、块地址有效性等物理层内容。逻辑层面的损坏（比如 ITL 条目错乱、row directory 指向非法 offset、索引键值与表行不匹配）完全跳过。
必须显式加上 CHECK LOGICAL 才会触发逻辑一致性检查：
RUN {
ALLOCATE CHANNEL c1 TYPE DISK;
VALIDATE DATABASE CHECK LOGICAL;
RELEASE CHANNEL c1;
}
漏掉这个参数，哪怕块里数据已严重错乱，LIST FAILURE 也始终为空。
VALIDATE 跳过未格式化、空块和脏页缓存中的块
RMAN 不会去读那些“理论上存在但实际没写过”的空间：
- 刚分配给段（segment）但尚未写入数据的 extent，对应块处于未格式化状态，
VALIDATE直接跳过 - 块在 buffer cache 中被修改过（脏页），但还没刷盘；此时物理文件里仍是旧状态，
VALIDATE读的是磁盘文件，可能错过正在内存中腐化的逻辑错误 -
NOLOGGING操作产生的 soft corrupt 块：备份时不会报错，恢复后首次访问才暴露为ORA-01578+ORA-26040，而VALIDATE在备份时刻根本看不到问题
这类情况要换手段：ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE 强制读所有块，或用 dbv file=<path> blocksize=<bs></bs></path> 绕过 Oracle 层直接校验物理文件。
Oracle 19c 的 V$DATABASE_BLOCK_CORRUPTION 视图不是实时快照
这个视图只记录最近一次 RMAN VALIDATE 或 BACKUP VALIDATE 发现的坏块，不是数据库当前状态的实时反映。如果之前跑过一次 VALIDATE 没发现问题，之后发生损坏，视图也不会自动更新。
更可靠的做法是每次怀疑坏块时都主动重跑：
- 先清空历史记录：
DELETE FROM V$DATABASE_BLOCK_CORRUPTION;（需 SYSDBA 权限，且仅对当前会话有效） - 再执行带
CHECK LOGICAL的VALIDATE - 立即查
LIST FAILURE和告警日志，别依赖视图缓存
注意：V$DATABASE_BLOCK_CORRUPTION 对 NOLOGGING 坏块支持有限；12c+ 应优先查 V$NONLOGGED_BLOCK。
VALIDATE CHECK LOGICAL 在 19c 下仍受版本行为影响
虽然 Oracle 19c 官方支持 CHECK LOGICAL，但部分场景下仍有隐性限制：
- 如果目标数据文件处于
READ ONLY状态，VALIDATE会跳过它，即使加了CHECK LOGICAL - 某些内部结构（如 SecureFiles LOB 块、In-Memory Column Store 缓存块）不被该选项覆盖
- 并行通道数过多时（比如
ALLOCATE CHANNEL c1 TYPE DISK MAXPIECESIZE 1G配了多个），个别通道可能因资源争用跳过逻辑校验步骤，建议单通道测试确认
最稳的兜底方式：当应用已报 ORA-01578 但 VALIDATE CHECK LOGICAL 无响应时，直接用 dbv 扫描对应数据文件——它不依赖 Oracle 实例状态，也不绕开任何块。
