ORA-16165报错LGWR没收到网络服务器信号，远程处理故障思路分享

ORA-16165这个错误，就是在Oracle数据库的Data Guard环境下，负责把数据库变化记录（重做日志）从主库写到备库的LGWR进程，突然发现它和备库那边的网络通信服务器（LNS进程）失去了联系，或者长时间没有得到备库的确认回复，LGWR就像一个负责派送重要文件的快递员，它每次把文件交给下一个站点的接收员（LNS）时，都需要对方签收确认，现在的问题是，快递员一直没等到接收员的签收信号，它就急了，于是抛出ORA-16165错误，并可能暂停向这个站点的派送服务，导致主库和这个备库之间的数据同步中断。

遇到这个问题,远程处理起来需要一步步排查，核心思路是“由近及远，从简到繁”，因为很多时候我们无法直接登录到备库或中间网络设备上查看，所以先从主库这边能获取的信息入手。

第一步：立刻检查主库的警报日志和跟踪文件

这是最直接也是最重要的一步,当发生ORA-16165错误时，Oracle一定会在主库的警报日志（alert_.log）里记录详细的错误信息、时间戳以及可能的相关进程信息，你需要立刻去查看警报日志。

• 查找错误细节：警报日志里的错误信息可能比简单的错误编号更具体，有时会附带一些额外的提示，比如网络超时、连接被拒绝等，这些是后续排查的关键线索。
• 查看LNS进程状态：在错误发生的时间点前后，查看是否有关于LNS进程（通常是ora_lns*这样的进程名）的异常记录，比如进程异常终止，如果LNS进程本身在主库端就启动失败或崩溃，那问题很可能出在主库的配置或资源上。
• 寻找跟踪文件：错误发生时，相关的后台进程（LGWR或LNS）可能会生成详细的跟踪文件（trace file），这些文件通常位于数据库的udump或diag/rdbms/<db_name>/<instance_name>/trace目录下，跟踪文件会包含更底层的错误信息，比如网络套接字连接失败的具体系统错误码，这对于判断是网络问题还是系统配置问题非常有帮助。（参考来源：Oracle官方文档关于诊断Data Guard问题的章节）

第二步：检查主库和备库的网络连通性

既然错误本质是通信失败,网络是首要怀疑对象，虽然远程操作，但我们仍然可以在主库服务器上进行一些基本的网络测试。

• 使用TNSPING测试TNS连接：Oracle提供的tnsping工具可以测试到备库TNS服务名的网络可达性和解析情况，命令类似于 tnsping <备库的TNS服务名>，它能告诉你是否能解析主机名、是否能连接到目标监听端口，如果tnsping失败或超时，问题很可能出在网络层面或备库监听器上。
• 使用TELNET测试端口连通性：如果tnsping不通，可以尝试用操作系统的telnet命令直接连接备库的监听端口（通常是1521），命令如 telnet <备库IP地址> 1521，如果telnet也连接不上，那基本可以确定是网络防火墙、路由问题或者备库监听器根本没有在运行。
• 注意DNS解析：确保主库使用的备库连接字符串中的主机名能被正确解析，有时DNS问题会导致间歇性的连接失败，可以尝试在命令中直接使用IP地址来代替主机名进行测试，如果IP地址能通而主机名不通，就是DNS或主机文件配置的问题。（参考来源：常见的网络故障排查实践）

第三步：检查备库的状态（间接方式）

虽然不能直接登录备库,但我们可以通过主库的视图和尝试连接来间接判断备库状态。

• 查询V$ARCHIVE_DEST_STATUS视图：在主库执行 SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = <出问题的备库ID>;，这个视图能告诉你备库的当前状态（比如是VALID还是ERROR）、以及最新的错误信息，这里的ERROR信息有时比警报日志的更简洁明了。
• 尝试建立测试连接：如果网络测试（tnsping/telnet）是通的，可以尝试从主库用一个简单的数据库连接串（如sqlplus sys/password@<备库TNS> as sysdba）看是否能连接到备库，如果连不上，而网络又是通的，那问题可能出在备库的监听器配置、实例状态或者认证方式上。（参考来源：Oracle Metalink 知识库中关于Data Guard故障排除的文章）

第四步：分析可能的原因并尝试简单恢复

基于前面的排查,可以有一些初步判断。

• 网络瞬时中断：如果警报日志没有其他严重错误，且网络测试现在又是正常的，可能是暂时的网络抖动，最简单的恢复方法是尝试重启MRP进程（管理恢复进程），在备库恢复正常连接后，在备库上执行 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; 来重新启动同步，但请注意，这是需要在备库上执行的操作，如果无法远程执行，需要协调备库侧的人员。
• 备库负载过高或存储问题：如果备库服务器CPU、IO负载极高，可能导致LNS进程响应缓慢甚至无响应，引发超时，同样，如果备库的归档日志目录满了，也会导致LNS进程卡住，这些需要备库侧检查系统资源。
• 防火墙或安全策略变更：中间网络设备的防火墙规则或操作系统层面的安全策略（如iptables, selinux）发生变更，阻断了两者之间的通信，需要协调网络管理员进行检查。

总结一下远程处理的核心流程：

1. 看日志：主库警报日志和跟踪文件是第一手资料。
2. 测网络：从主库用tnsping和telnet测试到备库的网络路径。
3. 查状态：通过主库视图了解备库的概要状态。
4. 做判断：结合以上信息，判断问题是网络、备库实例、还是主库配置引起。
5. 求协作：很多深层次问题（如备库重启、网络设备检查）需要与备库所在环境的运维人员协作解决，你需要将你的排查结果（“主库到备库IP的1521端口telnet不通，疑似防火墙阻断”）清晰地告知对方，以便快速定位。

处理这类问题,保持清晰的排查思路和做好记录非常重要，尤其是在远程协作的场景下。