Oracle RAC Database 11.1.0.6监听故障案例

晚上接到电话，客户的一套核心Oracle RAC数据库连接不上，连接时报无监听程序，客户的Oracle RAC版本为11.1.0.6，平台为AIX 6.1.05，使用了IBM HACMP 5.5.0.8。 　　当我远程过去的时候，发现节点2已经没有任何oracle用户的进程，且concurrent的vg没有激活，HACMP的服务也offline。 　　另一个节点Oracle的实例是正常的，且有部分服务器进程依然在工作，但是本地监听器出现了故障，导致新的连接无法连接到实例，通过crs_stat -t看到两个实例的监听也都是OFFLINE状态。 　　在节点上并没有发现有LISTENER进程， Oracle RAC（Real Application Clusters）数据库是一种高可用性解决方案，允许多个实例共享同一数据库，以提高业务连续性和性能。在这个特定的11.1.0.6版本中，我们遇到一个监听器故障的问题，这直接影响了客户端的连接能力。 问题描述提到客户在尝试连接Oracle RAC数据库时收到“无监听程序”的错误。监听器是Oracle数据库系统的关键组件，它负责接收来自客户端的连接请求，并将这些请求路由到适当的数据库实例。当监听器出现问题时，新的数据库连接将无法建立。 在这个案例中，故障发生在两个方面。一方面，节点2的所有Oracle用户进程都已消失，同时concurrent的卷组（vg）未激活，而IBM HACMP（High Availability Cluster Multiprocessing）服务也处于离线状态。这表明可能有更广泛的服务或硬件问题影响了这个节点。另一方面，虽然另一个节点的Oracle实例正常运行，但本地监听器存在故障，导致新连接无法建立。`crs_stat -t`命令显示两个实例的监听器状态均为OFFLINE，进一步证实了问题的严重性。 当尝试手动启动监听器时，错误提示"Address already in use"出现，这意味着监听器试图绑定到已经在使用的端口1521。端口1521是Oracle默认的监听端口，通常用于TCP/IP通信。这个错误可能由于多个监听器进程运行、端口被其他服务占用或者是网络配置问题导致。 在排查此类问题时，通常需要检查以下几个关键点： 1. **监听器配置**：检查`listener.ora`文件，确认监听器配置是否正确，包括端口设置、服务名定义等。 2. **网络配置**：确保VIP（虚拟IP）配置无误，与集群资源管理（如CRS）同步，并且网络接口状态正常。 3. **进程状态**：验证是否有其他监听器进程在运行，或者端口被其他非监听器进程占用。 4. **HACMP状态**：检查HACMP配置和服务状态，确保集群资源能够正常迁移和管理。 5. **操作系统日志**：分析操作系统日志，寻找可能的错误或警告信息。 6. **重启服务**：尝试重启Oracle相关服务，如节点应用（nodeapps）服务，以释放资源或恢复集群状态。 在本案例中，停掉节点的nodeapps服务后，VIP在主机层面消失，这可能意味着监听器依赖的资源没有正确配置或集群状态需要修复。解决这个问题可能需要进一步的诊断，如检查CRS日志、HACMP日志以及网络配置，以确定故障的根本原因并采取相应的恢复步骤。 Oracle RAC监听器故障是一个复杂的问题，可能涉及多个层面，包括软件配置、集群服务、网络配置和操作系统。有效的故障排除需要对整个系统有深入的理解，并且需要仔细分析和测试不同的解决方案。