restore database preview 仅查询元数据推导还原路径，不访问物理备份片，无法验证文件损坏或逻辑错误；真正校验需用 restore database validate（加 check logical 可验逻辑一致性）。
直接说结论：用 restore database preview 只能查“要还原哪些备份集”，不能验证备份文件本身是否损坏或逻辑错误——它不读备份块，不校验crc，也不触发解压缩或解密流程。
为什么 restore database preview 不等于验证完整性
这个命令本质是 RMAN 的“计划预演”，它只查询控制文件或恢复目录里的元数据，推导出还原路径（比如该用哪个 level 0 + 哪几个 level 1 + 哪些归档日志），然后输出一个列表。整个过程完全不访问物理备份片（.bkp 文件），更不会打开它们做 I/O 校验。
- 现象：执行后
alert.log里没有Restore from backup piece记录，也没有任何校验失败报错 - 风险点：备份片可能已被磁盘静默损坏、被误删、权限丢失、或加密密钥不可用，但
preview完全发现不了 - 适用场景：仅用于确认恢复策略是否配置正确、备份链是否断裂、归档日志是否齐全
restore database validate 才真正触碰备份文件
这个命令会实际读取备份集中的每个备份片，做基础物理校验（比如块头校验和、文件可读性、结构一致性），但它默认跳过逻辑检查——也就是不解析数据块内容，不验证索引/表数据是否逻辑讹误。
- 必须确保数据库处于
MOUNT状态，且 RMAN 能访问所有备份路径（包括 NFS、ASM 别名、或远程位置） - 耗时明显：一个 200GB 的 level 0 备份，
validate可能跑 15–40 分钟，取决于磁盘吞吐和并行通道数 - 关键参数差异：
check logical必须显式加上，否则不做逻辑层扫描；而validate backupset <key></key>才能指定具体某次备份，避免只验最新
验证增量备份链的最小可行组合
只跑一次命令不够。你需要分层覆盖物理 + 逻辑 + 链路连通性：
- 先用
list backup of database summary确认 level 0 和最近 level 1 是否都AVAILABLE，状态不是EXPIRED或UNAVAILABLE - 对 level 0 备份执行
validate backupset <key> check logical</key>——这是最重的校验，必须做 - 对最近一次 level 1 执行
validate backupset <key></key>（不加check logical即可，节省时间） - 最后补一句
restore database preview，确认 RMAN 能把这两者自动串成一条可用链
容易被忽略的三个硬限制
这些不是报错，但会让验证结果失效：
- RMAN 连接目标库时没带
catalog，而备份信息只存在恢复目录里 →preview和validate都只能看到控制文件里残留的旧记录 - 备份用了透明加密（TDE），但当前实例的 Oracle wallet 没 open →
validate会卡住或报ORA-19913: unable to decrypt backup，但preview完全无感 - 备份路径在 ASM 中，但
ASMCMD权限不足或 diskgroup offline →validate报ORA-19505: failed to identify file，而preview仍显示“可用”
