rman不支持allow corruption参数，该说法属误传；其设计遵循强一致性原则，遇坏块默认中止操作，合法绕过方式仅限隐含事件19548或blockrecover精准修复。
不能直接用 allow corruption 跳过坏块恢复 —— 这个参数根本不存在于 rman 的 restore 或 recover 命令中。很多人搜到的“allow corruption”其实是混淆了其他工具（比如 dbverify 或旧版导出工具）的选项，或误传的错误用法。
为什么 restore/recover 命令不支持 ALLOW CORRUPTION
RMAN 的设计原则是强一致性：遇到损坏块时默认中止操作，避免将损坏传播到新数据文件。它没有提供类似 ALLOW CORRUPTION 这种开关式参数来“强行写入坏块”。如果你在 restore 阶段看到 RMAN-19612 或 ORA-19511，说明备份集本身含坏块，RMAN 已拒绝继续。
- RMAN 在 restore 时若发现备份片中某 block 校验失败，默认行为是在目标位置写入一个全零空块（zeroed block），并记录警告，但不会跳过或忽略该 block 的还原责任
-
ALLOW CORRUPTION不是 RMAN 语法；尝试执行会报RMAN-00571: error message或直接语法错误 - 真正能影响坏块处理行为的是事件（event）和特定命令参数，不是通用开关
RMAN 恢复时跳过坏块的合法手段：EVENT 19548
当备份集里存在物理损坏、且你确认可接受数据不一致风险时，唯一被 Oracle 官方文档承认的“跳过”方式是设置隐含事件 19548。但它不是“修复”，而是“绕过校验”：
- 启用方式：
ALTER SYSTEM SET EVENTS '19548 trace name context forever, level 10'; - 必须在 RMAN 连接目标库前生效（最好重启实例，或至少
ALTER SYSTEM CHECKPOINT后再启动 RMAN） - 副作用明显：RMAN 将不再校验备份片中的块完整性，直接写入原始字节 —— 若该块逻辑已损坏（如 ITL 指针错乱、row directory 错位），恢复后表可能无法查询、
SELECT报ORA-01578，甚至引发实例崩溃 - 仅对
RESTORE阶段生效，RECOVER（应用归档/重做）阶段仍可能失败
更安全的替代方案：BLOCKRECOVER（BMR） + SKIP INACCESSIBLE
与其冒险用 EVENT 19548 强行恢复整个文件，不如聚焦在“只修坏块”上：
- 先查坏块：
SELECT * FROM V$DATABASE_BLOCK_CORRUPTION; - 若有可用备份，优先执行：
BLOCKRECOVER DATAFILE 5 BLOCK 147;—— 这才是真正意义上的“跳过其他块，只恢复指定坏块” - 如果表访问频次低、暂时可容忍缺失数据，可在修复前用
DBMS_REPAIR标记跳过：DBMS_REPAIR.SKIP_CORRUPT_BLOCKS，让后续SELECT自动跳过损坏 block（但 DML 仍报错） - 备份时预防：用
BACKUP DATABASE SKIP INACCESSIBLE;可跳过当前不可读的数据文件（如已 offline 或权限异常），但它对“文件内坏块”无效
容易被忽略的关键点
坏块恢复从来不是“一键跳过”的操作。最常被低估的是：即使你用 EVENT 19548 成功 restore 出文件，只要没做 RECOVER 到一致 SCN，这个数据文件就无法 online；而 recover 过程中一旦碰到依赖该坏块的重做记录，依然会失败。真正的断点往往卡在 recover 阶段，不是 restore。
