Oracle启用SQLNET加密必须同时配置三项：加密策略（SERVER/CLIENT=REQUIRED）、算法类型（ENCRYPTION_TYPES）和完整性校验（CRYPTO_CHECKSUM），缺一不可。
sqlnet.ora 里启用加密必须配齐这三项
只设 sqlnet.encryption_server=required 不起作用——oracle 要求加密策略、算法、验证三者同时显式声明，缺一不可。常见错误是只开服务端强制，但没配 sqlnet.encryption_types_server 或漏掉 sqlnet.encryption_client，结果连接直接拒绝。
实操建议：
-
SQLNET.ENCRYPTION_SERVER=REQUIRED和SQLNET.ENCRYPTION_CLIENT=REQUIRED必须成对出现，否则客户端和服务端协商失败 -
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192)至少指定一个算法，且必须和服务端 Oracle 版本支持范围匹配（如 12cR1 不支持 AES256-GCM） - 务必同步配置
SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED和对应SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER，否则即使加密了也无完整性校验
ORA-12650 报错本质是加密能力不匹配
这个错误不是“没开加密”，而是客户端与服务端在 SQLNET.ENCRYPTION_TYPES 列表中找不到交集算法。比如服务端只允许 (AES256)，但客户端（如旧版 sqlplus 或 JDBC 12.1 驱动）默认只支持 AES128，就会握手失败。
排查要点：
- 用
tnsping -v查看实际协商出的加密类型（需开启TRACE_LEVEL_CLIENT=16） - 确认客户端 Oracle Home 下
sqlnet.ora是否覆盖了服务端设置（尤其多版本共存时） - JDBC 连接串需显式加
&oracle.net.encryption_client=REQUIRED&oracle.net.encryption_types_client=(AES256)，驱动不会自动读取本地 sqlnet.ora
sqlnet.ora 加密配置不生效的隐藏原因
最常被忽略的是文件加载顺序和权限：Oracle 只读取第一个找到的 sqlnet.ora，且要求该文件属主为 Oracle 用户、权限 ≤644。如果放在 $ORACLE_HOME/network/admin 之外（如自定义 TNS_ADMIN），而 TNS_ADMIN 环境变量未被所有进程继承（比如 systemd 服务或 crontab），配置就等于没写。
检查动作：
- 运行
lsnrctl status后查看日志路径，确认监听器实际加载的sqlnet.ora位置 - 用
strace -e trace=openat sqlplus /@mydb 2>&1 | grep sqlnet直接看进程打开了哪个文件 - 修改后必须重启监听器（
lsnrctl reload不够，得stop+start）和数据库连接池（如 WebLogic 的数据源要重连）
加密对性能和兼容性的实际影响
AES256 加密在千兆内网下平均增加约 3%–5% CPU 开销，但若启用了 SQLNET.ENCRYPTION_TYPES_SERVER=(RC4_256)（已废弃），反而可能因软件实现缺陷导致更高延迟。更关键的是兼容性断层：Oracle 19c 默认禁用 RC4，而某些老旧中间件（如 WebSphere 8.5.5）仍硬编码依赖它。
稳妥做法：
- 生产环境优先选
AES192：比 AES256 略快，又比 AES128 更安全，且 11gR2+ 全系列支持 - 禁用
RC4和3DES，它们已被 NIST 和 Oracle 官方标记为不安全 - 如果必须兼容老系统，用
SQLNET.ENCRYPTION_TYPES_SERVER=(AES192,RC4_256)并严格限制客户端 IP 段，而非降级全局策略
加密配置真正难的不是写几行参数，而是确认每条连接路径——应用直连、DB Link、调度作业、甚至 expdp——都经过同一套协商逻辑。一个没覆盖到的环节，就等于留了一扇没锁的门。
