ORA-16193报错网络加密不匹配，主备库通信失败远程帮你搞定

ORA-16193报错网络加密不匹配，主备库通信失败远程帮你搞定

ORA-16193这个错误代码，对于使用Oracle Data Guard（数据卫士）来搭建主备库（主库和备用库）环境的运维人员或DBA来说，是一个比较令人头疼的问题，这个报错的核心意思是：你的主数据库和备用数据库在尝试通过网络进行通信，以同步数据时，由于双方设置的“网络加密”规则不一致，导致“握手”失败，通信连接无法建立，这就好比两个人约好都用暗语对话，但一个人用的是摩斯密码，另一个人用的是手势暗号，双方完全听不懂对方在说什么，对话自然就无法进行下去了。

这个问题的根源在于Oracle Net Services的配置，具体来说是sqlnet.ora这个配置文件中的相关参数在主库和备库服务器上设置得不一致。sqlnet.ora文件就像是数据库网络通信的“交通规则手册”，它规定了连接时需要遵循的安全标准，其中就包括加密相关的规则。

根据Oracle官方文档（例如Database Net Services Reference）中的说明，与加密相关的主要参数有以下几个：

1. SQLNET.ENCRYPTION_SERVER 和 SQLNET.ENCRYPTION_CLIENT：这两个参数分别指定服务器端和客户端（在这个场景下，主备库互相是对方的客户端）要求或允许的加密行为，它们的取值可以是：

   • accepted：允许加密但不强制要求，如果对方要求加密，则加密；如果对方不加密，也可以连接。
   • rejected：拒绝加密连接。
   • requested：请求加密连接，如果对方支持加密，则加密；如果对方不支持，仍然允许不加密连接（安全性较低）。
   • required：强制要求加密连接，如果对方不支持或拒绝加密，则连接失败。ORA-16193错误很多时候就是因为一方设置为required，而另一方却设置为rejected或未正确配置。

2. SQLNET.ENCRYPTION_TYPES_SERVER 和 SQLNET.ENCRYPTION_TYPES_CLIENT：这两个参数指定了支持的加密算法，例如AES256、AES192等，如果两端支持的算法列表没有交集，即使都要求加密，也会因为找不到共同认可的算法而失败。

   

3. SQLNET.CRYPTO_CHECKSUM_SERVER 和 SQLNET.CRYPTO_CHECKSUM_CLIENT：这两个参数用于数据完整性校验，其取值和逻辑与加密参数类似，也可以是accepted, rejected, requested, required，如果校验设置不匹配，同样会导致连接问题。

当发生ORA-16193错误时，通常会在备库的告警日志（alert log）或网络追踪文件中看到更详细的错误信息，Oracle Net Services encryption or crypto-checksumming configuration mismatch”之类的描述，这直接指明了是加密或校验和不匹配。

如何“远程帮你搞定”这个问题呢？远程解决的核心思路是：统一主库和备库服务器上sqlnet.ora文件中的加密相关参数设置。 以下是具体的排查和解决步骤，这些操作通常可以通过SSH等远程连接工具在服务器上执行：

第一步：定位并检查配置文件

需要找到主库和备库服务器上的sqlnet.ora文件，它通常位于$ORACLE_HOME/network/admin/目录下，如果设置了TNS_ADMIN环境变量，则文件位于$TNS_ADMIN目录。

第二步：对比参数设置

分别打开主库和备库的sqlnet.ora文件，仔细对比上述提到的加密和校验和参数，可以使用cat或more命令查看。

cat $ORACLE_HOME/network/admin/sqlnet.ora

重点关注：

• SQLNET.ENCRYPTION_SERVER 和 SQLNET.ENCRYPTION_CLIENT
• SQLNET.ENCRYPTION_TYPES_SERVER 和 SQLNET.ENCRYPTION_TYPES_CLIENT
• SQLNET.CRYPTO_CHECKSUM_SERVER 和 SQLNET.CRYPTO_CHECKSUM_CLIENT

第三步：分析并统一配置

对比后,你会发现不一致的地方，常见的解决方案是采用一种折中且安全的配置，一个推荐的做法是：

1. 将主备库双方的SQLNET.ENCRYPTION_SERVER和SQLNET.ENCRYPTION_CLIENT都设置为required。 这确保了所有通信都必须加密，安全性最高，如果因为某些原因暂时不能设置为required，可以暂时都设置为requested，但这会降低安全性。
2. 确保主备库双方的SQLNET.ENCRYPTION_TYPES_SERVER和SQLNET.ENCRYPTION_TYPES_CLIENT列表中有至少一个共同的加密算法。 为了兼容性和安全性，可以统一设置为一种强加密算法，

   SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
   SQLNET.ENCRYPTION_TYPES_CLIENT = (AES256)

3. 同样地，将主备库双方的SQLNET.CRYPTO_CHECKSUM_SERVER和SQLNET.CRYPTO_CHECKSUM_CLIENT也统一起来。 建议都设置为required，并确保校验和类型（如SHA256）一致。

第四步：应用配置并测试

修改完sqlnet.ora文件后，不需要重启整个数据库实例，但需要重新加载网络配置才能使更改生效，这可以通过重启数据库实例旁的监听器（Listener）来实现，或者在某些情况下，仅仅重新建立网络连接即可（下一次Data Guard尝试连接时会使用新配置）。

更稳妥的做法是重启两端的监听器：

lsnrctl stop
lsnrctl start

监听器重启后,Data Guard的MRP（Managed Recovery Process）进程或RFS（Remote File Server）进程在下次尝试连接时会使用新的加密设置，你可以观察备库的告警日志，看之前的ORA-16193错误是否消失，并出现正常的日志应用信息。

第五步：深入排查（如果问题依旧）

如果按照上述步骤统一配置后问题仍然存在,可能需要更深入的排查：

• 检查网络追踪文件：在sqlnet.ora中设置TRACE_LEVEL_SERVER=16和TRACE_DIRECTORY_SERVER，可以生成详细的网络追踪日志，帮助定位更精确的错误点。
• 检查防火墙：确保主备库之间的1521（或自定义的监听端口）端口通信畅通，防火墙没有阻断连接。
• 检查版本兼容性：极少数情况下，主备库Oracle版本差异过大可能导致加密算法支持度不同，但这种情况较为罕见。

解决ORA-16193错误是一个典型的“配置一致性”问题，通过远程登录服务器，仔细比对和修改主备库的网络配置文件，完全可以快速定位并解决这个问题，恢复主备库之间的正常数据同步，整个过程的关键在于细心和耐心，确保每一个参数在两端都保持完全一致。