数据库环境为oracle9.2.0.8的RAC，使用HP小型机两台，两个节点为为a1和a2，，
[故障过程]
某天下午3点收到应用方的反映，a1节点数据库无法正常访问。登陆数据库进行检查，发现a1节点的监听日志中不断报出TNS-12520，监听程序不能处理应用的新建连接请求，这些请求全部转移到a2节点，a2节点的压力突然增大，导致内存不足，同时由于HPUX内存分配方面的BUG，OS hang住，随后a2自动重启。
在发现a1的监听不能提供服务后，重启监听尝试解决问题，但是重启后，数据库服务无法正常注册到监听进程，应用仍然无法正常连接。
最后决定重新启动a2节点，重启主机后打开a2节点数据库，应用连接恢复正常，随后重启a1数据库，后也恢复正常。
[故障分析]
某天下午3点DBA接到应用方的反馈后，查看a1数据库监听，发现监听日志中不断出现TNS-12520，监听程序不能处理应用的新建连接请求。重启监听后，数据库服务无法注册到监听，监听仍然无法处理新的应用连接请求。
事后查看当时的监听日志，怀疑是Oracle pmon进程有异常(Metalink上有Pmon无法重新注册service的相关bug：[ID 760948.1]) ，导致数据库服务无法注册到监听，监听无法处理应用新建连接的请求。我们很大可能遇到了Oracle的bug。
同时在日志里发现，外贸有几台index和pop服务器的连接请求非常多，在a1无法提供服务后，所有的应用压力到了a2节点。
HP分析了a2 down机时候的日志，确认a2节点当时内存不足，加上hpux的内存分配bug，导致a2节点down机。
和应用方看了下几台有大量连接的服务器的连接池配置，发现initialSize=1, maxIdle=2，到数据库只保持了2个连接，这种配置已经不适合这个应用目前大压力的业务场景。业务压力大的时候，一天有4万多次
连接。改成initialSize=10，maxIdle=20，连接请求数马上降下来。
[故障总结]
这套数据库前一天凌晨刚完成搬迁切换，监控没有及时部署上，15号中午就出现了问题。如果在14号完成监控部署，就可以今早发现问题，及时处理，而不用等到15点应用方来反馈。
处理过程中，在重启监听但数据库服务无法手工注册服务时，应该及时反馈给DBA Team，大家一起解决，减少故障时间。出现问题后，如何第一时间通知应用、服务接口人，目前这个流程不够明确，需要确认。
Hpux主机参数需要重新再review一下，据HP分析，a2 hang住时，filesystem-cache占了近一半内存，需要降低filecache_max参数到5%-10%，之前用了默认配置是50%。
阅读(2059) | 评论(0) | 转发(0) |
