ORA-16166报错LGWR网络服务器发消息失败远程处理故障修复思路分享

ORA-16166报错，就是数据库里一个叫做LGWR（日志写入器）的关键进程，在尝试通过网络与一个远程服务器“聊天”时，话没说出去，或者对方没回应，导致沟通失败了，这个问题通常发生在Oracle数据库的高可用性环境中，比如Data Guard配置里，LGWR进程负责把数据库产生的变更记录（重做日志）写出去，当它需要实时地把这些记录发送到远端的备用数据库时，如果网络链路出问题，就可能抛出这个错误。

下面我们来分享一下解决这个问题的思路,整个过程就像医生看病，先问诊，再检查，最后开药方。

第一步：稳住局面，检查核心状态

遇到报错不要慌,首先要做的是了解当前数据库的整体健康状况，这不是直接去碰网络，而是先看大局。

• 检查Data Guard状态： 使用SQLPLUS连接到你的主数据库，执行 SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBOARD; 这个命令（来源：Oracle官方文档对V$MANAGED_STANDBOARD视图的说明），这个视图能告诉你各个与备用数据库相关的进程（包括负责传输日志的进程）在干什么，重点关注状态（STATUS）是不是“ERROR”或者有没有明显的延迟，这能帮你确认问题是不是普遍存在，还是只发生在一个特定的链路上。
• 查看警报日志： 警报日志是数据库的“黑匣子”，会记录所有重要事件和错误，仔细查看警报日志中ORA-16166错误出现时间点前后还有没有其他相关错误信息，它会给你更具体的线索，比如连接超时、认证失败等。

第二步：重点排查网络连接

既然错误明确指向网络通信,那么网络就是排查的重点，这就像怀疑电话打不通，得先检查电话线和信号。

• 基础连通性测试： 使用操作系统的工具，从主数据库服务器ping备用数据库服务器的主机名或IP地址，不仅要看能否ping通，还要观察延迟和有没有丢包，有时候能ping通但延迟巨大或偶尔丢包，也足以导致LGWR超时。重要提示： 确保你ping时使用的主机名或IP地址，与数据库配置参数（LOG_ARCHIVE_DEST_n）中写的一模一样，很多时候问题就出在这里，数据库配置用的是主机名，但DNS解析不正确或/etc/hosts文件没有正确配置。
• 端口连通性测试： 能ping通只代表网络层是通的，但Oracle网络服务使用的是特定端口（通常是1521），你需要用telnet 或 nc 命令测试这个端口是否开放。telnet <备用服务器IP> 1521，如果连接失败，说明防火墙可能阻止了连接，或者备用数据库的监听器没有正常启动。参考来源： 这是基本的TCP/IP网络故障排查方法。
• 检查监听器状态： 连接到备用数据库服务器，使用lsnrctl status命令检查监听器是否正在运行，并且是否已经注册了对应的数据库实例，如果备用库的监听器挂了，主库的LGWR自然无法与之建立连接。

第三步：深入数据库配置和日志

如果网络底层是通的,那问题可能出在数据库的“上层建筑”配置上。

• 检查归档目标参数： 查看主数据库中LOG_ARCHIVE_DEST_n参数（例如LOG_ARCHIVE_DEST_2）的配置，使用命令 SHOW PARAMETER LOG_ARCHIVE_DEST_2，你要确认几个关键属性：
  • SERVICE：指定的是否是正确的备用数据库的网络服务名（TNSNAME）。
  • LGWR：是否指定了使用LGWR进程进行实时传输（如果是异步模式，则是ASYNC）。
  • VALID_FOR：这个目标配置是否对当前的角色和日志类型有效。
  • 来源： Oracle官方文档关于LOG_ARCHIVE_DEST_n参数的详细解释。
• 检查TNSNAMES.ORA文件： 到主数据库服务器上，找到$ORACLE_HOME/network/admin/tnsnames.ora文件，检查其中为备用数据库配置的网络服务名条目，确认里面的主机名（HOST）、端口（PORT）和服务名（SERVICE_NAME）都完全正确，一个字母的错误都可能导致连接失败。
• 查看跟踪文件： 如果以上步骤还找不到原因，可以开启LGWR进程的SQLNET跟踪，这会产生非常详细的日志，记录连接建立过程中的每一步，对于诊断复杂的网络问题非常有帮助，具体方法是通过在sqlnet.ora文件中设置跟踪参数（如TRACE_LEVEL_SERVER=16, TRACE_DIRECTORY_SERVER等），但这个方法会产生大量日志，建议在Oracle支持人员指导下进行，或在问题解决后及时关闭。来源： Oracle官方文档关于配置SQLNet跟踪的部分。

第四步：尝试性恢复操作

在做了充分检查后,可以尝试一些简单的恢复操作。

• 重启监听器： 在备用数据库服务器上，尝试用lsnrctl stop和lsnrctl start重启监听器，有时候重启能解决一些临时的资源冲突或僵死状态。
• 重启MRP进程： 如果备用数据库处于托管恢复模式，其MRP（托管恢复进程）可能也受到了影响，在备用库上取消恢复（ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;），然后重新启动它（ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;），这相当于重新建立了主备之间的应用链路。
• 重新配置归档目标： 作为最后的手段，你可以先禁用出问题的归档目标（ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;），然后再启用它（ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;），这能强制LGWR重新初始化到备用库的网络连接。

总结一下思路： 解决ORA-16166的核心就是 “由广至深，由易到难” ，先从数据库整体状态和最简单的网络ping测试开始，逐步深入到端口、监听器、具体参数和配置文件的检查，超过一半的此类问题都是由基础网络不通或TNS配置错误引起的，在整个过程中，详细阅读警报日志是定位问题方向的关键，如果所有自查手段都无效，那么就需要联系Oracle原厂支持，并提供你收集到的所有日志和检查结果，以便进行更深层次的分析。