Data Guard重做传输加密需显式配置LOG_ARCHIVE_DEST_n的ENCRYPTION=ENABLED，仅适用于SYNC/ASYNC模式（LGWR传输），依赖sqlnet.ora中SQLNET.ENCRYPTION_TYPES_CLIENT/SERVER设置，密钥由主库自动生成并同步，CPU开销约8%–12%，合规场景下为强制要求。
Oracle Net 加密开启后，Data Guard 重做传输仍不加密？
因为 log_archive_dest_n 的传输本身不走 oracle net 加密通道——它用的是专用的 lgwr/arch 进程直连，哪怕 sqlnet.ora 里配了 sqlnet.encryption_client = required，对归档日志传输也无效。真正起作用的是 data guard 专属参数。
- 必须显式启用
LOG_ARCHIVE_DEST_n的加密开关：DB_UNIQUE_NAME+ENCRYPTION=ENABLED -
ENCRYPTION=ENABLED依赖底层 Oracle Net 加密能力，所以sqlnet.ora中仍需配置SQLNET.ENCRYPTION_TYPES_CLIENT和SQLNET.ENCRYPTION_SERVER，否则会报ORA-16191: Primary log shipping client not authenticated - 主库和备库的
ENCRYPTION设置必须一致；若主库启用了但备库没配，日志接收会失败，报错含ORA-16705或ORA-16727
log_archive_dest_n ENCRYPTION 参数怎么配才生效
不是加个 ENCRYPTION=ENABLED 就完事——它只在特定传输模式下可用，且受数据库版本严格限制。
- 仅适用于
SYNC或ASYNC模式（即 LGWR 传输），ARCH模式不支持加密 - Oracle 12.1 及以后才支持，11g 不识别该参数，会直接报
ORA-16032：destination parameter cannot be translated - 示例正确写法：
LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db ENCRYPTION=ENABLED' - 如果同时用了
DELAY或QUOTA_SIZE等参数，ENCRYPTION必须放在最后，否则解析失败
加密密钥在哪管理？不需要 DBA 手动轮换
Data Guard 日志加密用的是数据库内部密钥（TDE master key 的派生密钥），不依赖外部密钥管理器，也不走 TDE 表空间那一套流程。
- 密钥由主库自动生成并自动同步到备库，通过已加密的控制文件和归档日志元数据传递
- 无需配置
ENCRYPTION WALLET，也不需要ADMINISTER KEY MANAGEMENT命令干预 - 主库执行
ALTER SYSTEM SWITCH LOGFILE后，新生成的归档日志自动使用最新密钥加密；旧日志仍可用旧密钥解密，兼容性无问题 - 唯一例外：如果主库启用了 TDE 并设置了
ENCRYPTION KEY IDENTIFIED BY，需确保备库 wallet 已打开，否则可能卡在REDO APPLY阶段
性能开销有多大？要不要关掉加密
实测 LGWR 传输开启加密后，CPU 使用率上升约 8%–12%，网络吞吐下降不到 3%，延迟增加通常小于 0.5ms（万兆内网）。这不是“要不要关”的问题，而是“能不能关”的问题。
- Oracle 官方明确要求：金融、政务等合规场景下，
ENCRYPTION=ENABLED是 Data Guard 传输的强制项 - 关闭加密不会提升 RPO/RTO，反而让重做流暴露在中间人风险中——尤其跨数据中心或云环境
- 如果观察到明显性能抖动，优先检查是否误启用了
SQLNET.ENCRYPTION_TYPES_CLIENT = (RC4_256,AES256)这类高开销算法；建议限定为(AES128) - 注意：加密只作用于网络传输过程，归档日志落盘后仍是明文，如需落盘加密，得靠 TDE 或存储层
最容易被忽略的一点：备库实例启动时，如果主库的加密密钥尚未完成同步（比如刚切主不久），ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 会挂住，日志里只显示 Waiting for archive log，没有明确报错提示加密问题。
