ORA-16655错误导致备库连接失败，远程排查修复思路分享

ORA-16655错误导致备库连接失败，远程排查修复思路分享

当我们管理Oracle Data Guard环境时，可能会在告警日志或通过DGMGRL命令行工具看到ORA-16655错误，这个错误的信息通常是“failed to connect to standby database”，它就是告诉我们，主库想和备库“打个电话”同步数据，但“电话线”断了，或者备库那边“没人接电话”，这个问题很常见，尤其是在网络环境不稳定或备库有异常的情况下，由于是远程排查，我们无法直接登录备库服务器操作，所以思路必须清晰，一步步从主库端可以获取的信息入手,逐步缩小范围。

第一步：检查错误的具体上下文和详细信息

我们不能只看一个孤立的错误代码，ORA-16655只是一个结果，我们需要知道它发生时的具体情况，最直接的方法是查看主数据库的告警日志（alert_.log）。

（来源：Oracle官方文档关于Data Guard Broker和日志记录的描述）在告警日志中，搜索“ORA-16655”或“Error 16655”，这个错误前后会伴随更详细的错误信息，比如网络超时、连接被拒绝、或者更底层的网络错误（如ORA-12535、ORA-12170等）,这些伴随的错误代码是定位问题的关键线索。

• 如果伴随ORA-12535（TNS:操作超时），说明主库在等待备库响应时超过了规定时间，问题可能出在网络延迟、网络拥堵,或者备库主机负载过高无法及时响应。
• 如果伴随ORA-12541（TNS:无监听程序），那几乎可以肯定备库上的监听器没有启动,或者监听地址配置错误。
• 如果伴随ORA-01017（无效的用户名/密码；登录被拒绝），则说明用于重做传输的数据库用户（通常是SYS）的密码文件可能不一致,或者权限有问题。

记录下这些详细的错误信息,它们是后续排查的方向盘。

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

既然错误是连接失败，网络是首要怀疑对象，虽然无法直接登录备库网络设备,但我们可以从主库服务器进行简单的网络测试。

（来源：常规网络故障排查方法）在主库所在的操作系统上，使用tnsping命令来测试到备库的连接。tnsping工具是Oracle提供的，专门用于检查Oracle Net连接的可用性，命令格式是tnsping，其中standby_service_name是你在主库tnsnames.ora文件中配置的备库服务名。

执行这个命令,观察结果：

• 如果能够成功解析并显示连接时间,说明基础网络和监听器基本是通的。
• 如果显示“TNS-12541: TNS:no listener”，说明网络能通,但备库监听器没起来。
• 如果显示“TNS-12535: TNS:operation timed out”,说明网络请求超时。
• 如果根本解析不了主机名,可能是DNS问题或主机名配置错误。

如果tnsping不通，问题大概率出在网络层面或备库的监听器配置上，如果tnsping是通的，说明底层连接没问题，问题可能更深层,比如数据库实例状态或归档日志应用问题。

第三步：检查备库的监听器状态和实例状态

由于是远程，我们无法直接操作备库，但可以通过Data Guard Broker（如果使用了Broker的话）或尝试在主库端进行更深入的诊断。

（来源：Oracle Data Guard Broker管理指南）如果你使用了Data Guard Broker，可以使用DGMGRL命令行工具连接到主库，然后执行SHOW CONFIGURATION或SHOW DATABASE <standby_db_name>命令，Broker会尝试与备库通信并返回其状态，如果Broker能显示备库的状态（即使是DISCONNECTED），也说明Broker进程能联系上备库的某个服务，如果Broker也完全无法连接,那会进一步印证网络或监听器的问题。

可以尝试从主库创建一个到备库的数据库链接（database link），并使用该链接在备库上执行一个简单查询（如SELECT NAME FROM V$DATABASE;），如果这个查询能成功，说明不仅网络和监听器是通的，数据库实例也是打开的，并且身份验证通过，这能极大地缩小问题范围——如果数据库链接能工作，但重做传输仍然报ORA-16655，那么问题可能就非常具体地出在重做传输服务相关的参数或进程上，比如LOG_ARCHIVE_DEST_n参数的配置。

第四步：检查主库的重做传输配置

这是非常关键的一步，主库通过LOG_ARCHIVE_DEST_n参数（例如LOG_ARCHIVE_DEST_2）来定义如何将日志发送到备库。

（来源：Oracle Data Guard概念与管理手册）连接到主库，检查这个参数的配置：SHOW PARAMETER LOG_ARCHIVE_DEST_2,重点关注以下几个属性：

• SERVICE：指向的备库服务名是否正确？是否和之前tnsping用的服务名一致？
• LGWR ASYNC/SYNC：是否正确指定了日志写入进程的传输模式？
• VALID_FOR：参数配置是否确保了在正确角色下向正确的目标发送日志？
• NET_TIMEOUT：这个参数设置了LGWR进程在中断连接前等待备库响应的秒数，如果网络较慢，默认的30秒可能不够,可以适当增大此值来应对短暂的网络波动。

一个常见的错误是，备库的TNS服务名在操作系统层面用tnsping测试是好的，但在数据库内部的网络配置（sqlnet.ora, tnsnames.ora）可能因为路径问题而解析错误，确保Oracle数据库软件读取的tnsnames.ora文件包含了正确的备库连接描述符。

第五步：请求远程协助检查备库端

经过以上四步，如果还不能解决问题，就需要联系能在备库现场操作的同事或供应商进行协助了，你可以将你排查到的线索（比如tnsping结果、伴随的错误代码）提供给他们,让他们重点检查：

1. 备库监听器状态：执行lsnrctl status，检查监听器是否运行，是否在监听正确的端口,以及服务是否已经注册。
2. 备库数据库实例状态：检查备库是否处于MOUNT状态或READ ONLY WITH APPLY状态，如果备库意外打开了（OPEN），或者处于非归档模式,重做传输是无法进行的。
3. 备库的警报日志：这是最重要的，备库的告警日志会记录它是否接收到了来自主库的连接请求，以及连接失败的具体原因,这往往是解决问题的最终钥匙。
4. 备库的网络防火墙：确认备库服务器的防火墙或中间的网络设备没有阻断主库IP到备库监听端口的连接。

远程排查ORA-16655错误，是一个由外到内、由浅入深的逻辑过程，从主库告警日志的详细错误信息出发，先用tnsping验证基础网络，再用Broker或数据库链接判断实例可达性，最后仔细核对主库的配置参数，每一步的结果都为下一步提供了方向，保持耐心，系统性地逐一排除可能的原因，最终就能找到并解决这个“连接失败”的问题，恢复Data Guard的正常运行。