oracle tde加密前必须正确配置wallet路径与权限，否则alter tablespace encryption将报ora-28365；wallet需持续可读、属主为oracle、权限700；加密仅对新写入数据生效，存量数据需手动重写；备份wallet比rman更关键。
oracle tde 加密前必须配好 wallet 路径和权限
没配好 wallet_root 或者 encryption_wallet_location，alter tablespace ... encryption 会直接报 ora-28365: wallet is not open，哪怕你已经执行过 administer key management set key。wallet 不是“配一次就完事”，它得被 oracle 实例持续读取——所以路径必须在所有节点（rac）上一致且可读，用户必须是 oracle（或启动实例的 os 用户），不能是 root 或其他账户。
实操建议：
-
WALLET_ROOT推荐设为独立目录（如/u01/app/oracle/admin/$ORACLE_SID/wallet），避免混在$ORACLE_HOME下导致升级误删 - 确认
sqlnet.ora中的ENCRYPTION_WALLET_LOCATION指向的是(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/path/to/wallet)))，不是软链路径 - Wallet 目录权限必须是
700，属主是oracle:oinstall；若用自动登录 wallet（cwallet.sso），文件本身也得是600 - 重启监听器或数据库后，务必手动执行
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "pwd" WITH BACKUP;再ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "pwd";，否则新加密表空间会失败
ALTER TABLESPACE … ENCRYPTION 只对新写入数据生效
TDE 表空间加密不是“一键全量重写”，它只影响后续 INSERT/UPDATE 产生的数据块。已存在的数据块不会自动加密，除非触发物理重写（比如 ALTER TABLE ... MOVE、DBMS_REDEFINITION 或在线段收缩）。这点常被误认为“加密没起作用”——查 V$ENCRYPTED_TABLESPACES 显示已启用，但 SELECT DUMP(column) FROM ... 还能看到明文十六进制值，其实是缓存或未刷盘的老块。
实操建议：
- 加密前先评估业务低峰期窗口：要真正完成全量加密，需逐个对大表执行
ALTER TABLE t MOVE TABLESPACE encrypted_ts; - 别对
SYSTEM、SYSAUX、UNDO、TEMP表空间启用加密——Oracle 明确不支持，会报ORA-44001: invalid tablespace - 加密后首次打开 wallet 时，所有依赖该表空间的对象（如物化视图日志、LOB 段）会隐式触发加密初始化，可能短暂卡住 DML，监控
V$SESSION_LONGOPS中的encryption initialization项
备份恢复时 Wallet 文件比 RMAN 备份还关键
RMAN 备份了加密表空间的数据文件，但没备份 wallet。没有对应版本的 cwallet.sso 和正确密码，恢复出来的库连 OPEN 都做不到，报 ORA-28368: cannot auto-create wallet 或更隐蔽的 ORA-28374: typed master key not found。尤其跨平台迁移（比如从 Linux 到 AIX）或升级数据库版本后，wallet 格式可能不兼容。
实操建议：
- 每次修改 wallet（如轮换主密钥、添加 backup）后，立即用
ADMINISTER KEY MANAGEMENT EXPORT KEYS WITH SECRET "xxx" TO '/backup/wallet_20240501.p12' IDENTIFIED BY "pwd";导出 P12 包，并离线存档 - RMAN 备份脚本末尾加一句：
!cp $WALLET_ROOT/cwallet.sso /backup/wallet_$(date +%Y%m%d).sso，并校验 md5 - 测试恢复流程必须包含：还原 wallet → 启动实例 → 手动
SET ENCRYPTION WALLET OPEN→ 再还原数据文件，缺一不可
查询 V$ENCRYPTED_TABLESPACES 时注意视图刷新延迟
V$ENCRYPTED_TABLESPACES 不是实时镜像，它依赖后台进程扫描数据文件头。刚执行完 ALTER TABLESPACE ts_name ENCRYPTION ON，立刻查这个视图可能仍返回空或旧状态，导致自动化脚本误判。更糟的是，如果表空间含大量小文件（比如上千个 1MB 的 autoextend 数据文件），扫描可能耗时数分钟。
实操建议：
- 检查是否生效，优先用
SELECT tablespace_name, encrypted FROM dba_tablespaces WHERE tablespace_name = 'TS_NAME';——这个字段来自数据字典，更新及时 - 验证加密块内容，不要依赖
DUMP()，改用SELECT * FROM v$encrypted_tablespaces WHERE tablespace_name = 'TS_NAME';并等 30 秒后重查 - 在 Data Guard 环境中，standby 库的
V$ENCRYPTED_TABLESPACES可能滞后于 primary，需确认APPLY_LAG为 0 后再查
Wallet 密码丢了可以导出 P12 恢复，但主密钥轮换后旧密钥没备份，那些没重写的旧数据块就真解不开——这事儿没法回滚，只能靠提前演练过的完整密钥生命周期管理流程兜底。
