因为diagwait未配置导致RAC脑裂日志记录不完整的分析案例
2015-02-23 18:35
363 查看
1、故障现象
一个RAC,CRS版本为10.2.0.4,在第二节点DOWN机后,第一节点也相继DOWN机。2、CRS日志分析
2.1 二节点日志情况
CRS_LOG[cssd(8796)]CRS-1611:node XXdb1 (1) at 75% heartbeat fatal, eviction in 14.118 seconds 2014-07-04 22:49:38.556 [cssd(8796)]CRS-1611:node XXdb1 (1) at 75% heartbeat fatal, eviction in 13.128 seconds 2014-07-04 22:49:46.561 [cssd(8796)]CRS-1610:node XXdb1 (1) at 90% heartbeat fatal, eviction in 5.128 seconds 2014-07-05 03:00:08.142 [cssd(8812)]CRS-1605:CSSD voting file is online: /dev/raw/raw18. Details in /home/oracle/product/10.2.0/crs/log/XXdb2/cssd/ocssd.log. |
2.2 一节点日志情况
2014-07-04 23:00:00.018 [cssd(27561)]CRS-1612:node XXdb2 (2) at 50% heartbeat fatal, eviction in 29.144 seconds 2014-07-04 23:00:15.017 [cssd(27561)]CRS-1611:node XXdb2 (2) at 75% heartbeat fatal, eviction in 14.144 seconds 2014-07-04 23:00:24.014 [cssd(27561)]CRS-1610:node XXdb2 (2) at 90% heartbeat fatal, eviction in 5.144 seconds 2014-07-04 23:00:25.016 [cssd(27561)]CRS-1610:node XXdb2 (2) at 90% heartbeat fatal, eviction in 4.144 seconds 2014-07-05 01:21:06.620 [cssd(31191)]CRS-1605:CSSD voting file is online: /dev/raw/raw18. Details in /home/oracle/product/10.2.0/crs/log/XXdb1/cssd/ocssd.log. |
2.3 问题小结
两个节点的重启日志都没有写完整就发生了操作系统的重启,二节点的驱促信息都没有来得及发送到一节点,致使一节点并不知道二节点已经消失,然后一节点也去通过心跳线ping二节点,发现与二节点心跳存在异常,一节点重启原因由于缺少操作系统性能监控数据支持(如服务器当时负载是否很高)以及日志的不完整难以断定重启的真正原因。3、正常日志应有情况
2014-06-24 14:53:21.258 [crsd(8825)]CRS-5504:Node down event reported for node 'tsrrac02'. 2014-06-24 14:53:21.259 [crsd(8825)]CRS-2773:Server 'tsrrac02' has been removed from pool 'ora.crmout'. 2014-06-24 14:53:21.259 [crsd(8825)]CRS-2773:Server 'tsrrac02' has been removed from pool 'Generic'. |
4、CRS配置情况检查
$ crsctl get css diagwait Configuration parameter diagwait is not defined. |
5、对diagwait未配置默认值与问题风险的官方说明
Using Diagwait as a diagnostic to get more information for diagnosing Oracle Clusterware Node evictions ( Doc ID 559365.1 ) 《==This setting will provide more time for diagnostic data to be collected by safely and will NOT increase probability of corruption. OPROCD 是用来检查节点是否hang的,当它发现节点hang后,会发起起点重启。 它有两个重要的参数: oprocd.debug -t 1000 -m 500 timeout value (-t <to-millisec>) :每次执行检查的间隔,默认为1000ms(1s). margin (-m <margin-millisec>) :允许延迟的时间,默认为500ms(0.5s)) OPROCD 进程每隔to-millisec(1s)进行一次检查,检查的时候会获取OS的时间,然后用这个时间减去上次获取的OS的时间,如果这个时间差大于to- millisec + margin-millisec,那么OPROCD会认为OS hang了,就会发起重启。简单说来,如果不改变上面两个参数的值,那么默认情况下,如果OPROCD在1.5s都无法获取到OS的时间,就认为OS hang了。 修改了diagwait为13s后,会把margin-millisec设为10s,也就是允许获取OS的时间达到11s(1s+10s). |
6、改进方案
该问题只会出现在ORACLE 11.2以前版本中,在 11G R2版本中,diagwait的值默认配置为13针对11.2以前的版本,需要手工将diagwait修改为13,以推迟重启的时间便于将缓存中的日志信息有足够的时间写入到磁盘文件中,以及减少因为与OS交互允许时间太短而造成的重启可能。
本文作者:黎俊杰(网名:踩点),从事”系统架构、操作系统、存储设备、数据库、中间件、应用程序“六个层面系统性的性能优化工作
欢迎加入 系统性能优化专业群,共同探讨性能优化技术。群号:258187244
相关文章推荐
- [Oracle 11g r2(11.2.0.4.0)]案例分析8-本地节点hang 住导致的集群重新配置
- [Oracle 11g r2(11.2.0.4.0)]案例分析7-丢失本地心跳导致的集群重新配置
- [Oracle 11g r2(11.2.0.4.0)]案例分析5-丢失网络心跳导致的集群重新配置
- [Oracle 11g r2(11.2.0.4.0)]案例分析6-丢失磁盘心跳导致的集群重新配置
- centos7线程、文件打开数等调优日志(非优化案例、仅仅是个个人记录、为把相关配置文件记录一下)
- ELK实时日志分析平台环境部署--完整记录网址
- ELK实时日志分析平台环境部署--完整记录
- ELK实时日志分析平台环境部署--完整记录
- ELK实时日志分析平台环境部署--完整记录
- 基于Spring AOP和Groovy日志模板配置的日志记录框架的二次实现与使用案例
- 日志文件分析工具—AWStats在IIS中的配置步骤
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- 用p6spy和sqlprofiler来进行jdbc sql日志记录和分析
- POSTFIX上的邮件日志分析工具(pflogsumm)安装与配置
- IIS6.0日志文件分析代码_2生成访问记录到文本文件
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- log4j配置相对路径实现日志记录
- DHCP服务器配置案例分析之一 推荐
- IIS6.0日志文件分析代码_1生成访问字段记录到数组中