rman备份加密表空间无需额外操作，但恢复前必须确保keystore处于open状态，否则restore会静默失败；因rman仅复制数据块，解密依赖keystore中密钥，缺失则报ora-19913或ora-01157。
表空间加密后，RMAN 备份和恢复本身不需要额外操作，但必须确保 Oracle keystore 处于 OPEN 状态，否则 RESTORE 会直接失败。
为什么加密表空间的备份会“静默失败”
Oracle 对加密表空间（使用 ENCRYPTION USING 'AES256' 创建）的备份是透明的：RMAN 不感知加密逻辑，它只复制数据块。但恢复时，RMAN 必须能解密块才能校验或写入磁盘——这依赖 keystore 是否已打开且包含对应密钥。
常见现象是：RESTORE TABLESPACE tpm 执行后卡住数秒，然后报错：
ORA-19913: unable to decrypt backup
或者更隐蔽地跳过加密数据文件，只恢复了控制文件和归档日志，导致后续 RECOVER 报 ORA-01157: cannot identify/lock data file。
- keystore 未打开（
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "pwd";） - keystore 是软件 keystore，但数据库启动时未自动打开（缺少
WALLET_ROOT和ENCRYPTION_WALLET_LOCATION配置） - 使用了硬件安全模块（HSM），但 HSM 连接中断或认证过期
RMAN 恢复加密表空间前必做的三件事
不是“建议”，是硬性前提。缺一不可。
- 确认 keystore 已 OPEN：
SELECT STATUS FROM V$ENCRYPTION_WALLET;返回OPEN（不是OPEN_NO_MASTER_KEY） - 确保数据库实例已加载 keystore 路径：检查
ENCRYPTION_WALLET_LOCATION在sqlnet.ora中正确指向 wallet 目录，且该目录下有cwallet.sso（软件 wallet）或有效 HSM 配置 - 如果用的是 TDE 表空间加密，且恢复目标是另一台服务器，必须把源库的 wallet 完整复制过去，并在新库上执行
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "pwd"——不能只导出密钥，TDE 密钥绑定的是 wallet 文件本身
备份脚本里容易漏掉的 SET ENCRYPTION 参数
RMAN 默认不加密备份集，即使源表空间是加密的。这意味着备份集本身是明文的，存在泄露风险。要让备份集也加密，必须显式启用：
RMAN> SET ENCRYPTION ON IDENTIFIED BY "backup_key" ONLY;
注意：
-
ONLY表示只对本次会话生效；若要持久化，需CONFIGURE ENCRYPTION FOR DATABASE ON - 该加密与表空间 TDE 无关，是 RMAN 层的备份集加密，密钥由 RMAN 管理，不依赖 keystore
- 恢复时无需手动提供
"backup_key"，RMAN 自动从控制文件读取（前提是控制文件没损坏） - 若同时启用了 TDE + RMAN 备份集加密，恢复流程不变，但多了一层保护：即使备份文件被盗，没有 RMAN 密钥也无法解包
增量备份对加密表空间有没有特殊影响
没有。RMAN 的增量备份基于块级别变更检测（通过 V$BLOCK_CHANGE_TRACKING 或块更改跟踪文件），而加密发生在数据块写入磁盘前，不影响块的“是否变更”判断逻辑。
但要注意一个实际限制：
- 如果表空间加密后又执行了
ALTER TABLESPACE ... ENCRYPTION OFF，再做增量备份，RMAN 仍会把之前加密块的变更纳入增量集——因为块地址没变，只是内容解密态不同。此时恢复可能因密钥缺失而失败，除非你保留了旧 wallet 并手动打开 - Oracle 不允许对已加密表空间执行
NOLOGGING操作，所以不会出现“部分块未加密”的混合状态，这点比早期版本更可靠
最易被忽略的点：恢复加密表空间时，RESTORE 命令本身不报错不代表成功——必须紧接着执行 RECOVER 并看到 Media recovery complete，才真正验证了 keystore、密钥、归档日志三者全部就绪。任何环节断链，都会在 recover 阶段暴露。
