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