启用RMAN透明加密前必须确保Oracle Wallet已正确配置并打开，否则SET ENCRYPTION IDENTIFIED BY会报ORA-19924或ORA-28365错误；该命令仅对后续BACKUP生效，且依赖wallet状态、密码一致性、Oracle主版本兼容性，不加密源数据文件。
启用RMAN透明加密前必须确认wallet是否就绪
不配好oracle wallet，set encryption identified by 会直接报错 ora-19924: encryption wallet is not open 或 ora-28365: wallet is not open。这不是密码输错了，是根本没加载加密基础设施。
实操建议：
- 先用
SELECT * FROM V$ENCRYPTION_WALLET;看状态，STATUS必须是OPEN - Wallet 路径由
ENCRYPTION_WALLET_LOCATION在sqlnet.ora中指定，不是 RMAN 命令能覆盖的 - 如果用 AUTO_LOGIN wallet（
cwallet.sso），重启数据库后自动可用；若用 PASSWORD-based（ewallet.p12），每次数据库启动后需手动执行ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "xxx";
RMAN中SET ENCRYPTION IDENTIFIED BY的实际作用范围
这个命令只对**后续执行的 BACKUP 命令生效**，不影响已存在的备份集，也不影响 CONTROLFILE COPY、ARCHIVELOG DELETE 等其他操作。它本质是给本次 RMAN session 设置一个临时加密凭据，不是全局策略。
常见错误现象：
- 执行了
SET ENCRYPTION IDENTIFIED BY "mypass"，但 backup 仍生成未加密文件 → 检查是否在 backup 前执行了该命令，且中间没执行过RESET ENCRYPTION - 备份成功但恢复时报
ORA-19913: unable to decrypt backup→ 恢复时 wallet 必须已打开，且密码和加密时完全一致（注意大小写、空格） - 用不同密码反复 set encryption → 最后一次设置生效，前面的会被覆盖，不会叠加或混用
加密备份集无法跨 Oracle 版本/平台直接还原
哪怕密码相同，用 19c 加密的备份集，在 21c 上 restore 可能失败，报 ORA-19913 或 ORA-28374: typed master key not found。根本原因是 TDE master key 的兼容性依赖 Oracle 内部密钥派生机制，版本升级可能触发密钥轮转或算法变更。
使用场景提醒：
- 生产环境做跨版本升级前，务必用目标版本验证加密备份能否 restore + recover 成功
- 不要把加密备份当“通用归档格式”——它和数据库实例强绑定，wallet 文件 + 密码 + Oracle 主版本号三者缺一不可
- 如果要长期归档，建议先解密还原到临时库，再用非加密方式备份（如压缩 tar + 外部加密）
SET ENCRYPTION IDENTIFIED BY 不等于数据落盘加密
它只加密 backupset 文件（即 RMAN 生成的 .bkp），不加密源数据文件、归档日志、闪回日志或内存中的数据块。如果你真正想防的是存储层泄露，得靠 TDE 表空间加密（CREATE TABLESPACE ... ENCRYPTION USING 'AES256'），而不是 RMAN 加密。
性能与配置差异：
- RMAN 加密在备份过程中实时加解密，CPU 开销明显，尤其 AES256；可通过
CONFIGURE DEVICE TYPE DISK PARALLELISM 4分摊压力 -
SET ENCRYPTION IDENTIFIED BY用的是 Oracle 内置的 wallet 管理的 master key，不能指定算法（固定为 AES128），也不能自定义 salt - 如果 wallet 丢失或损坏，所有用它加密的备份集将永久不可读——没有后门，没有绕过方式
最常被忽略的一点：backuppiece 加密后，LIST BACKUP 输出里不会显示“encrypted”，只能靠 RESTORE VALIDATE 或尝试 restore 才能确认是否真加密成功。别光看命令没报错就以为万事大吉。
