RMAN备份片默认明文，必须显式启用加密：CONFIGURE ENCRYPTION FOR DATABASE ON（依赖wallet OPEN）或SET ENCRYPTION ON IDENTIFIED BY 'xxx' ONLY（会话级，恢复需SET DECRYPTION），二者机制独立且不可互替。
加密备份片必须显式启用，RMAN不会自动继承表空间加密
RMAN 备份片默认是明文的，哪怕数据库已启用 TDE 表空间加密或列加密。这是因为 RMAN 加密和 TDE 是两层独立机制：TDE 保护数据文件块在磁盘上的静默状态，而 RMAN 加密保护的是备份集（.bkp 文件）本身。不配置加密，备份文件直接可被读取、复制、挂载——哪怕源库所有表空间都加了 ENCRYPTION USING 'AES256'。
必须用以下任一方式显式开启：
-
CONFIGURE ENCRYPTION FOR DATABASE ON：全局生效，但依赖 TDE wallet 当前为OPEN状态（查V$ENCRYPTION_WALLET.STATUS），wallet 关闭时备份仍为明文，且无任何警告 -
SET ENCRYPTION ON IDENTIFIED BY 'xxx' ONLY：会话级临时生效，只影响紧随其后的BACKUP命令；密码区分大小写和空格，恢复时必须一字不差输入
注意：ONLY 关键字不能省略，否则 RMAN 会尝试同时使用 wallet 和口令，失败概率陡增。
解密备份片恢复时，口令模式与 wallet 模式路径完全不同
恢复加密备份片前，先确认它用的是哪种加密方式——这决定了你该执行哪条命令：
- 若备份用的是
SET ENCRYPTION ON IDENTIFIED BY 'mypass' ONLY，恢复时必须先运行SET DECRYPTION IDENTIFIED BY 'mypass'，再执行RESTORE；不设解密口令会直接报ORA-19913: unable to decrypt backup - 若备份用的是
CONFIGURE ENCRYPTION FOR DATABASE ON，则恢复前必须确保 wallet 已打开：ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "wallet_pwd"；查V$ENCRYPTION_WALLET.STATUS必须为OPEN，而非OPEN_NO_MASTER_KEY - 混合加密（即既配了 wallet 又用了
SET ENCRYPTION ... ONLY）极少用，恢复时优先匹配口令，wallet 状态仅作辅助校验
常见错误：在口令加密备份上误执行 ADMINISTER KEY MANAGEMENT 命令，不仅无效，还可能干扰 wallet 状态。
AES 算法切换后，旧版本 Oracle 无法识别新备份片
修改加密算法看似简单：CONFIGURE ENCRYPTION ALGORITHM 'AES256'，但实际影响很隐蔽：
- Oracle 12.1 及更早版本无法 restore 用
AES256加密的备份片，即使密码正确，也会报ORA-28374: typed master key not found—— 根源是密钥派生协议不兼容 - 查看当前支持算法：SQL>
SELECT ALGORITHM_NAME FROM V$RMAN_ENCRYPTION_ALGORITHMS；注意字段IS_DEFAULT和IS_AVAILABLE的值 - 生产环境切算法前，务必验证目标恢复库版本是否支持；跨版本迁移时，建议保持
AES128兼容性
算法变更不改变已有备份片格式，只影响后续新生成的备份。
备份脚本里最容易漏掉的三处加密控制点
自动化备份脚本中，加密常因细节缺失而失效：
- 没加
SET ENCRYPTION就直接写BACKUP DATABASE：RMAN 不会报错，但生成明文备份；检查备份片大小可初判——加密备份通常比明文大 5%~10% - 在
SET ENCRYPTION和BACKUP之间穿插了CROSSCHECK或LIST BACKUP：会话级加密上下文可能被重置，导致备份未加密 - 用
CONFIGURE ENCRYPTION FOR DATABASE ON后，忘了在数据库启动后确保 wallet 自动打开：若用cwallet.sso（AUTO_LOGIN）可规避；若用ewallet.p12，必须在启动后立刻执行ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "xxx"
最稳妥的做法是在每个 RUN 块开头重复写一次 SET ENCRYPTION ON IDENTIFIED BY 'xxx' ONLY，不依赖会话持久性。
