【知识点详解】
本文档记录了一个DBA处理的真实案例，涉及的主题是数据库运维，特别是针对Oracle的Real Application Clusters (RAC)系统。RAC是一种高可用性和负载均衡解决方案，允许多台服务器共享同一个数据库，从而提高了数据库服务的连续性和性能。
1. **RAC宕机问题**：
- 文中描述的场景是一个位于上海的RAC系统频繁发生宕机，其中一台节点经常无故停止运行，这对券商的生产系统产生了严重影响，可能导致严重的业务中断和经济损失。
- 这个问题不仅涉及到数据库层面，还包括操作系统和应用层面，使得问题分析复杂化。
2. **故障排查过程**：
- 当地的Oracle专家无法确定问题原因，DBA本人也被要求亲自介入。
- 提供的日志文件包括bdump、udump目录以及CRS_HOME下的日志，这些都是诊断RAC问题的关键数据源。
- 使用RDA (Remote Diagnostic Assistant) 收集了大量的系统信息，以协助远程诊断。
- 日志显示，宕机可能与CSS（Cluster Synchronization Services）有关，如`ocssd.log`中的错误信息。
3. **系统配置**：
- RAC系统基于Oracle 10.2.0.3版本，运行在两台配置为8个CPU和16GB内存的微机服务器上，操作系统为64位Red Hat Linux AS4 Update 4。
- CRS (Cluster Resource Manager) 已安装了BUNDLE PATCH 1，这是保持RAC集群稳定运行的重要补丁。
4. **日志分析**：
- `ocssd.log`中的`clssgmHandleDBDone()`、`clssgmReconfigThread`和`clssgmCommonAddMember`等函数调用，表明可能与集群重新配置或节点间的通信问题有关。
- 错误消息如`clscsendx: Connection not active`和`clssgmSendClient: Send failed rc 6`可能指向网络连接或GCS (Global Cache Service) 的问题，这可能影响了节点间的数据同步。
5. **故障应对策略**：
- 对于这类复杂的宕机问题，DBA通常会进行以下步骤：检查硬件稳定性，验证网络配置，审查操作系统和数据库的事件日志，分析性能指标，以及检查应用程序是否有任何异常行为。
- 如果Metalink（现为My Oracle Support）的远程分析无法解决问题，可能需要现场调查，收集更多系统和应用级别的详细信息，甚至可能需要与Oracle支持团队进一步合作。
6. **风险与后果**：
- 宕机问题可能导致业务中断，对客户造成重大影响，甚至可能引发索赔。
- 为了防止类似问题再次发生，需要快速识别问题根源并实施相应的解决方案，确保系统的高可用性和稳定性。
这个案例展示了DBA在处理RAC系统故障时所面临的挑战，以及如何通过日志分析、故障排查和现场调查来解决复杂的问题。它强调了在高可用性环境中，对数据库系统全面理解和深入分析的重要性。
