oracle data guard日志加密必须显式配置log_archive_dest_n的encryption=enabled，仅适用于lgwr传输的sync/async模式，依赖sqlnet.ora中sqlnet.encryption_types_client/server设置，密钥自动同步，cpu开销约8%–12%。
Oracle Data Guard 传输加密不能靠 sqlnet.ora 里的 SQLNET.ENCRYPTION_CLIENT 自动生效，必须显式配置 LOG_ARCHIVE_DEST_n 的 ENCRYPTION=ENABLED，且仅对 LGWR 传输模式（SYNC/ASYNC）有效。
LOG_ARCHIVE_DEST_n 必须显式启用 ENCRYPTION=ENABLED
即使主备库 sqlnet.ora 都配了 SQLNET.ENCRYPTION_TYPES_SERVER=(AES256) 和 SQLNET.ENCRYPTION_CLIENT=required，归档日志传输仍走明文——因为 DG 日志传输不走通用 Oracle Net 连接，而是由 LGWR/ARCH 进程直连，绕过 sqlnet 加密栈。
-
ENCRYPTION=ENABLED只在SYNC或ASYNC模式下生效；ARCH模式不支持，会直接报ORA-16032 - 参数位置敏感：必须放在
LOG_ARCHIVE_DEST_n字符串末尾，若前面有DELAY=30或QUOTA_SIZE=1G，ENCRYPTION=ENABLED要排在最后，否则解析失败 - 示例正确写法：
LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db ENCRYPTION=ENABLED' - 主备库该参数值必须一致，否则备库接收日志时会报
ORA-16705或ORA-16727
sqlnet.ora 是前置依赖，不是可选配置
虽然 ENCRYPTION=ENABLED 是开关，但底层加密能力由 sqlnet.ora 控制。缺任一配置，ALTER SYSTEM SWITCH LOGFILE 后会直接报 ORA-16191: Primary log shipping client not authenticated。
- 主备库
sqlnet.ora必须都包含：SQLNET.ENCRYPTION_TYPES_CLIENT=(AES256)、SQLNET.ENCRYPTION_TYPES_SERVER=(AES256)、SQLNET.ENCRYPTION_SERVER=required - 版本限制：Oracle 12.1+ 才识别
ENCRYPTION=ENABLED；11g 解析该参数会报ORA-16032 - 密钥完全自动管理：主库生成密钥，通过加密的控制文件和归档头同步到备库，无需手动操作
ADMINISTER KEY MANAGEMENT或配置 wallet
常见静默降级：抓包看到明文 TCP 流量
最典型的失败现象是“看起来一切正常”，SELECT STATUS FROM V$ARCHIVE_DEST 显示 VALID，但 tcpdump -i any port 1521 抓到的归档传输包全是明文——说明加密根本没启用。
- 根本原因：只配了 sqlnet.ora 加密，漏掉
LOG_ARCHIVE_DEST_n的ENCRYPTION=ENABLED - 或误用于
ARCH模式（如LGWR SYNC ARCH组合非法），此时参数被忽略，无报错但不加密 - 验证是否真加密：在备库执行
SELECT * FROM V$DATAGUARD_STATS WHERE NAME LIKE '%encrypt%';，返回非空才表示正在使用加密通道 - CPU 开销实测约 +8%–12%，网络吞吐下降
真正麻烦的不是配错参数，而是误以为“配了 sqlnet 就等于 DG 加密了”。DG 传输加密是独立机制，ENCRYPTION=ENABLED 是唯一入口，且必须和传输模式、版本、sqlnet 基础配置三者对齐，缺一不可。
