ORA-19693错误源于RMAN控制文件中同一backup piece被重复注册，而非磁盘文件真实重复；需通过list backup定位#Copies>1的冗余条目，再用crosscheck与delete expired清理，或采用移动–crosscheck–catalog法安全去重。
ORA-19693 错误本质是控制文件里重复注册了同一个 backup piece
这不是磁盘上文件“真的重复”，而是 rman 控制文件中对某个备份片（如 e:\bak_04p9jk4q_1_1）存在多条记录。rman 在 restore 时会拒绝加载同一 backup piece 两次，直接报错退出。
常见诱因包括：
- 异机恢复时多次执行
catalog start with，尤其在 Windows 路径大小写不敏感或路径末尾斜杠处理不一致时，容易触发重复编目 - 使用 ASM 存储 +
catalog start with触发 Oracle BUG 4483368（10g–12c 均有报告） - 手工拷贝备份集后未清理旧 catalog 条目，又重新 catalog
- duplicate 或 standby 环境残留的归档备份条目未同步清理
用 list backup 和 list backup of database tag=... 定位重复项
先确认是否真有重复——不是看磁盘文件名，而是查 RMAN repository 中的逻辑记录：
- 运行
list backup summary;，关注#Copies列：值 >1 就是高危信号 - 再执行
list backup of database tag='TAG20140530T170010';（把实际 tag 替换进去），明确看到哪些RECID指向同一个物理路径 - 若输出中出现多个
RECID对应相同handle（如都显示E:\BAK_04P9JK4Q_1_1），就坐实了控制文件冗余
删除冗余 catalog 条目比删磁盘文件更安全
别急着 rm 或 del 磁盘上的 .bkp 文件——多数情况下磁盘只有一份，删了就真没了。优先清理控制文件里的“幽灵条目”：
- 先做
crosscheck backup;，把状态变成EXPIRED的无效条目标记出来 - 再执行
delete expired backup;，清除所有EXPIRED条目（这是最常用且安全的第一步） - 如果仍有多个
AVAILABLE条目指向同一文件，uncatalog可能失败（报RMAN-20261: ambiguous backup piece handle），此时改用“移动–crosscheck–catalog”法：
— 把那个backup piece临时移出原目录（如从E:\BAK_04P9JK4Q_1_1改名为E:\BAK_04P9JK4Q_1_1.bak）
— 执行crosscheck backup;，原路径条目全变EXPIRED
—delete expired backup;
— 把文件移回原名
—catalog backuppiece 'E:\BAK_04P9JK4Q_1_1';单独注册一次
避免下次再踩坑的关键操作习惯
ORA-19693 往往是流程松散导致的，不是配置问题：
- 异机恢复前，务必先
list backup summary;，确认#Copies全是 1；如有异常，不跳过，必须清理完再restore - 禁用多次
catalog start with，尤其不要在不同路径下反复执行（比如catalog start with 'E:\bak\';和catalog start with 'E:\bak\';看似一样，但 trailing slash 差异可能被 RMAN 当作不同路径） - 在脚本中做 catalog 操作时，加前置检查：
list backuppiece '<full_path>'; </full_path>若返回非空，跳过 catalog 步骤 - 备份集拷贝到新主机后，第一件事不是
restore，而是crosscheck backup; delete expired backup;—— 这两行应该成为你的肌肉记忆
真正麻烦的不是修复动作，而是控制文件里那些看不见的、指向已不存在路径的残留条目。它们不会报错，直到某次 restore 突然卡住。
