RMAN备份加密需明确区分全局配置（configure encryption for database on）与会话级设置（set encryption on identified by），前者依赖TDE wallet处于OPEN状态，后者仅对紧随其后的backup生效且支持跨机恢复；算法切换和加密模式选择须谨慎，避免兼容性问题与性能下降。
rman 备份加密不是“配了就自动生效”，必须明确区分 configure encryption for database on（全局策略）和 set encryption on identified by（会话级临时设置）——混用会导致备份未加密却误以为已保护。
configure encryption for database on 与 wallet 状态强绑定
启用该配置后，RMAN 所有 backup 操作默认走透明加密，但前提是 TDE wallet 已打开且状态为 OPEN。执行 SELECT * FROM V$ENCRYPTION_WALLET; 必须看到 STATUS = OPEN，否则备份仍为明文，不报错也不警告。
- wallet 路径由
sqlnet.ora中的ENCRYPTION_WALLET_LOCATION决定，RMAN 命令无法覆盖 - 用
cwallet.sso（AUTO_LOGIN）可避免每次重启数据库后手动开 wallet；若用ewallet.p12（PASSWORD-based），必须在数据库启动后立刻执行ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "xxx"; - 即使配置了
configure encryption for database on，wallet 关闭时 backup 仍生成未加密备份集 —— 这是静默失败，最容易被忽略
set encryption on identified by 只影响紧随其后的 backup
这个命令本质是给当前 RMAN session 注入一个一次性加密凭据，不是持久化配置。它只对下一条（或下几条，直到被 reset encryption 或新 set encryption 覆盖）backup 命令生效。
- 常见错误：先执行
set encryption on identified by "mypass"，中间穿插了list backup或crosscheck archivelog all，再执行backup database→ 加密失效，因为 session 凭据可能已被重置或覆盖 - 密码区分大小写、空格，恢复时必须一字不差；多执行几次
set encryption，只有最后一次生效 - 该方式生成的备份可在异机恢复，只要提供相同密码，不依赖源库 wallet —— 适合离线介质归档场景
AES128 / AES192 / AES256 算法切换需谨慎
算法变更本身简单：configure encryption algorithm 'AES256'; 即可。但实际影响常被低估：
- 不同 Oracle 版本对算法支持不一致：19c 默认支持全部三种，但某些旧补丁集可能不识别
AES256，导致 backup 报ORA-19913 - 加密算法变更后，新备份无法用旧版本 Oracle（如 12.1）直接 restore，即使密码正确 —— 错误通常是
ORA-28374: typed master key not found，根源是密钥派生机制不兼容 - 查看可用算法用
SELECT ALGORITHM_NAME FROM V$RMAN_ENCRYPTION_ALGORITHMS;，别依赖文档想当然
口令加密 vs 透明加密：选错模式等于白加
两种模式解决的是完全不同的问题，不能互换：
-
set encryption on identified by是口令加密，备份文件自带解密能力，适合跨平台/异机恢复，但密码管理责任全在 DBA 手中 -
configure encryption for database on是透明加密，依赖 wallet 和 master key，本机恢复无需密码，但备份集复制到其他服务器后基本不可用（除非完整迁移 wallet + master key，极不推荐） - 混合模式极少使用，且 Oracle 官方文档未明确支持跨版本混合解密，生产环境应避免
最易被忽略的一点：RMAN 加密是 CPU 密集型操作，开启后备份吞吐量可能下降 15–30%，尤其在高并发 backup 场景下。如果数据库服务器 CPU 已长期 >70%，建议先压测再上线加密策略。
