12.2之后识别NOLOGGING坏块必须用validate database nonlogged block，主库执行无效；需先查V$DATAFILE中FIRST_NONLOGGED_SCN>0定位污染文件，再在主库基于该SCN做增量备份，备库离线数据文件后注册并RECOVER DATAFILE NOREDO修复。
RMAN中识别NOLOGGING坏块的命令和时机
12.2之后必须用 validate database nonlogged block，不能再依赖 validate database check logical。后者只报逻辑坏块，对NOLOGGING导致的“数据不一致但校验通过”的块完全沉默。
执行前确认：v$nonlogged_block 视图在12c才存在；11g及更早版本只能查 v$database_block_corruption 里 CORRUPTION_TYPE='NOLOGGING' 的记录，但该视图在12c已被弃用。
常见误操作：在主库上运行 validate database nonlogged block —— 这个命令只对物理备库有意义，主库没有NOLOGGING坏块的概念（它自己写的是什么就是什么）。
修复NOLOGGING坏块必须走增量备份+SCN恢复
不能直接 RESTORE DATAFILE，因为标准还原会拉取最近一次全量或增量0备份，而NOLOGGING操作发生在备份之后、归档日志应用之前，单纯还原无法覆盖这部分“无重做”的变更。
关键动作是定位并使用 FIRST_NONLOGGED_SCN：
-
SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE WHERE FIRST_NONLOGGED_SCN > 0—— 找出哪些文件被NOLOGGING污染 - RMAN在主库执行
BACKUP INCREMENTAL FROM SCN，不是全量备份，也不是任意增量DATAFILE - 增量备份必须从
FIRST_NONLOGGED_SCN开始，否则仍会漏掉那部分裸写的数据
注意：这个SCN不是随便选的，它代表该数据文件中最早一次NOLOGGING操作发生的点。早于它，数据可由归档日志覆盖；晚于它，必须靠这个增量备份补上。
备库上执行恢复时的脱机与联机顺序不能颠倒
先停Redo Apply，再 ALTER DATABASE DATAFILE ，最后重启Apply —— 这个顺序是为了让控制文件把该文件标记为“待修复”，否则RMAN注册备份后可能拒绝应用。
常见坑：
- 执行
OFFLINE后没停Apply就直接注册备份，RMAN报错RMAN-06026: some targets not found - aborting restore - 恢复完忘记
ALTER DATABASE DATAFILE，文件一直卡在ONLINE RECOVER状态，v$datafile里显示STATUS = 'RECOVER'，但数据库能正常打开 - 误用
OFFLINE DROP而非OFFLINE FOR DROP，后者允许后续在线，前者等同于删除元数据，再ONLINE会报ORA-01113
NOLOGGING恢复失败最常卡在归档日志链断裂
即使增量备份正确，RECOVER DATAFILE 仍可能失败，因为RMAN需要从增量起点SCN开始，一路应用归档日志直到当前备库SCN。中间缺一个归档，整个链就断了。
绕过方式有限且有代价：
- 从其他节点拷贝缺失归档 —— 最稳妥，但依赖网络和权限
- 用
SET UNTIL SCN截断恢复点 —— 数据丢失，仅适用于可接受少量数据损失的场景 - 启用
FORCE LOGGING并重建备库 —— 成本最高，但一劳永逸，适合长期运维
真正难处理的不是技术步骤，而是判断哪个SCN才是安全下限：它既要大于所有NOLOGGING操作的起点，又不能高于最新可用归档的终点。这个窗口一旦消失，就只剩重建一条路。
