某数据库pmon进程无法正常工作导致宕机的事故
2010-09-02 22:28
381 查看
数据库环境为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%。
[故障过程]
某天下午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%。
相关文章推荐
- 简说一下coffeescript的constructor是如何导致Backbone.View的事件无法正常工作的.
- centos 7.2系统bug导致HGDB后台进程崩溃,数据库无法访问
- 先安装SQL2008 R2后安装AD导致无法正常登陆数据库(无法启动MSSQLSERVER)
- 解决"System.AccessViolationException”类型的未经处理的异常在 未知模块(IIS Worker Process 已停止工作)导致无法连接远程数据库的问题
- oracle 异常关闭操作 导致数据库无法正常关闭 也无法启动
- MSSQL 2005数据库不能正常连接:客户端无法建立连接,因为在登录前连接初始化进程中发生错误
- 创新谈-如何处理DataGuard环境中万一网络失败将导致的Primary库短时间内无法正常工作的问题-张乐奕
- 解决oracle数据库TNSLSNR.exe进程占用8080端口,导致tomcat无法正常启动问题
- manifest文件导致,网狐无法正常工作问题.
- oralce10g 归档目录空间满导致归在线重做日志文件无法归档。最后数据库不能正常使用
- Windchill10.0升级到10.2版本导致Jersey-1.17无法正常工作的解决办法
- 基于WEB服务器导致消息中心各组件之间无法正常工作的问题分析与解决
- SQL - 先安装SQL2008 R2后安装AD导致无法正常登陆数据库(无法启动MSSQLSERVER)
- mysql 崩溃导致无法正常工作
- 解决设备应用程序无法申请到内存,导致设备无法正常工作的问题---优化设备虚拟内存使用
- 压测xx业务数据库资源大量等待,存在表锁问题,导致数据库无法正常执行解决办法
- libmemcached 1.0.10 SUSE 10 下无法正常工作的原因
- centOS下无法正常获取数据库表数据的问题
- SQL Server 2008R2 数据库出现“可疑”导致无法访问解决办法
- "最大工作进程数"导致的WCF调用失败