RMAN加密备份需同时满足wallet为OPEN状态、session凭据紧接backup命令、AES算法跨版本兼容三重条件，否则静默生成明文备份；必须通过V$ENCRYPTION_WALLET确认状态、避免RMAN命令穿插、验证目标库算法可用性并完成端到端restore测试。
RMAN加密备份不是“配了就生效”，而是依赖 wallet 状态、session 生命周期和算法兼容性三重隐式条件。直接执行 CONFIGURE ENCRYPTION FOR DATABASE ON 后仍生成明文备份，是生产环境最常踩的坑。
确认 TDE Wallet 已 OPEN，否则所有加密配置静默失效
Oracle 不会在 wallet 关闭时报错或警告，CONFIGURE ENCRYPTION FOR DATABASE ON 命令会成功返回，但后续 BACKUP DATABASE 仍输出明文文件。
- 必须先在 SQL*Plus 中执行
SELECT * FROM V$ENCRYPTION_WALLET;，确认STATUS列为OPEN（不是CLOSED或NOT_AVAILABLE） - wallet 路径由
sqlnet.ora中的ENCRYPTION_WALLET_LOCATION指定，RMAN 无法覆盖该路径 - 推荐使用
cwallet.sso（AUTO_LOGIN），避免每次数据库重启后手动执行ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY ... - 若用
ewallet.p12，权限必须是700，所有者必须是oracle用户，且不能放在$ORACLE_HOME下（升级可能覆盖）
SET ENCRYPTION ON IDENTIFIED BY 是 session 级一次性凭据，中间不能插任何其他 RMAN 命令
这个命令不是开关，而是向当前 RMAN session 注入临时解密凭据，生命周期极脆弱。
- 必须紧接在
BACKUP命令前执行，例如：SET ENCRYPTION ON IDENTIFIED BY "mypass"; BACKUP DATABASE; - 中间插入任意 RMAN 命令（如
LIST BACKUP、CROSSCHECK ARCHIVELOG ALL、甚至SHOW ALL）都会导致凭据丢失 - 同一 session 内多次执行
SET ENCRYPTION，只有最后一次生效，报错ORA-19913 - 恢复时必须先执行
SET DECRYPTION IDENTIFIED BY "mypass"，再RESTORE；漏掉这步直接失败，且不提示输入密码
AES256 算法跨版本 restore 极易失败，不能只看配置是否成功
启用 CONFIGURE ENCRYPTION ALGORITHM 'AES256' 后，备份看似成功，但目标库 restore 时可能报 ORA-28374: typed master key not found。
- 执行前务必查
SELECT * FROM V$RMAN_ENCRYPTION_ALGORITHMS;，确认IS_AVAILABLE = 'YES' - 旧版本（如未打补丁的 11.2.0.1 或 12.1）对 AES256 支持不完整，命令静默回退到 AES128，无提示
- 19c 加密的备份在 21c 上 restore 失败很常见，根源是密钥派生机制变更，不是“新版本向下兼容”
- 生产升级前必须完整走通：本地
BACKUP→ 传输备份集 → 在目标版本上RESTORE→RECOVER
真正难控的不是命令本身，而是 wallet 的隐式状态、session 凭据的瞬时性、以及算法在不同 Oracle 版本间不可见的密钥行为——这些点不验证到 restore 成功，就等于没加密。
