你的Oracle RAC是真集群还是伪集群？高可用失效风险提醒
你的Oracle RAC是真的数据库集群么？还是一个伪集群呢？
换句话说:
当Oracle RAC集群中的一个节点所在的分区/服务器宕掉的时候，你是否可以和领导拍着胸脯说，“没事，这是ORACLE RAC，还有一个节点呢！只要该节点可以抗住负载，完全可以正常对外提供服务！”
如果你再把上面那段话读一遍，是否有开始犹豫的感觉了呢？
再换个方法来问一下这个话题：
虽然系统上线前做过RAC高可用测试，但是当集群中的一个节点长时间运行，包括CPU、内存、进程数在内的负载在不断变化，并且又经历了一些列变更后，期间又没有再做过高可用测试，这样的情况下，如果RAC一个节点所在的分区/服务器宕掉的时候，你是否依然可以拍着胸脯坚定的说，“我的Oracle RAC其他的节点一定可以正常对外提供服务！”?
同样的问题，当多了一些话语的铺垫后，再次听到这个问题的你，答案是否又更加犹豫了呢？
今天就为大家奉献一个“RAC高可用丢失”的真实案例其实完整、真实的分析过程。报告中将对Oracle数据库稳定运行的共性风险和隐患作出提醒。
分享本案例的意义：
估计不少朋友的系统中依然还存在类似的问题，建议参考本案例进行细致检查,排除隐患。如果有朋友反馈查到类似的隐患，那么就没有浪费笔者的一片苦心了。
本案例精彩看点：
这个案例会有不小的难度，客户为了分析该问题发生的根因，投入了大量的人力和时间，一度没有结果。笔者接手该case后，在缺少信息的情况下，问题的分析也一度陷入僵局。不过最终还是通过反复梳理所有线索，从一个和数据库毫不相关的小细节中找到了突破口，成功定位到了问题原因，实属不易。
1 故障描述
现象：Oracle RAC高可用丢失。表现如下：
1）下午16点1分左右，XX系统数据库RAC集群节点2所在的P595 发生硬件故障，导致节点2 数据库所在的分区不可用。
2）但从16点1分开始，应用程序无法连接到数据库RAC集群中存活的节点1。
ORACLE数据库RAC集群未能发挥高可用架构的作用！
客户指示，务必找到问题根因，以便对系统高可用架构提出改进意见。
笔者很理解，出了这样的大事，对于一个运行着几百套RAC的数据中心而言，是一个巨大的风险，其他系统是否也还存在这样的问题？什么时候会再发生？如果不找到问题根因，又如何做到由点带面全面全面梳理、检查和预防呢？
所以，接到该case时，还是有很大压力的。在开始分析前，得到了以下信息：
1）故障时运维DBA在RAC存活节点1通过sqlplus “/as sysdba”连接到数据库挂起
2）故障时运维DBA在RAC存活节点1通过sqlplus -prelim “/as sysdba”连接到数据库挂起,加了-prelim参数连接到数据库也hang,这是很罕见的情况
3）在存活的节点1上通过 crsctl stop crs -f停止crs无法停止,命令挂起无法结束
4）在存活的节点1上通过shutdown –Fr重启操作系统，命令挂起无法结束，最终通过hmc重启分区，业务恢复正常
2 分析过程
2.1 故障分析思路
集群中一个节点宕掉，其他节点无法对外提供服务。
通常情况下，是因为当中的集群软件没有完成对整个集群状态、数据的重组，
因此数据未达到一致，所以集群其他节点无法对外提供服务。
这个环境中部署在IBM小机上，其中用到的集群软件有：
ORACLE RAC/ORACLE CRS/IBM HACMP
因此，需要分别查看这三个集群是否完成了重组、重新配置
2.2 确认ORACLE RAC是否完成重组
查看一节点数据库alert日志,可以看到，RAC集群在16点1分32秒就完成了重组。
可排除该问题。
2.3 确认ORACLE CRS是否完成重组
可以看到，从16:01开始网络心跳超时，开始对节点2进行剔除的动作，最终在16:01:27节点2离开集群。可排除该问题。
2.4 确认IBM hacmp是否完成重组
经AIX专家分析，未发现HACMP中出现异常
整个检查下来，没有发现异常。
既然节点2数据库所在的Lpar宕了，那么节点2的vip应该会漂移到节点1上，接下来通过netstat –in命令检查，发现节点1上居然没有节点2飘过来的VIP ！
接管VIP的动作最终将由CRSD进程来完成，因此检查CRSD.log,以便查看是否在接管过程中发生了什么异常。
2.5 检查1节点crs日志确认节点2 vip的接管情况
2.6 节点1 crs日志总结
可以看到：
1）节点2当掉后，节点1的CRS要把节点2的vip、db等资源接管过来，在节点1启动，但是调用脚本racgwarp来做check/start/stop时均出现了超时timeout,从而把子进程终止了。
2）并且节点1 本身自己的 vip检测中也出现了超时，如下所示
/oracle/app/oracle/product/10.2.0/crs/bin/racgwrap(check) timed out for ora.node1.vip! (timeout=60)
3） 因此，CRS在资源管理上也出现了一定的异常，主要是调用脚本racgwrap时出现了超时异常。
Racgwrap脚本出现timeout,通常是因为：
- 操作系统性能缓慢，如内存大量换页
- 脚本执行过程出现命令挂起的情况
2.7 检查nmon数据以获得操作系统性能
可以看到,5月20日的nmon居然停止在了故障时间点16点1分，这说明NMON执行到某个命令可能出现了挂起等异常
另外，从监控软件来看，操作系统未出现内存、CPU的告警。
2.8 确定分析方向
那么，接下来，我们的分析重点到底是放在数据库还是操作系统层面呢？
通过上面的线索梳理，我们有理由相信：
操作系统在当时出现了某些异常!因此后续把分析的重点方向放在操作系统层面！
2.9 汇总并梳理所有线索
1）存活节点Sqlplus –prelim无法attach到共享内存
2）Kill -9 无法杀掉部分进程
进程处于一个原子级的调用，例如一个IO，必须在两个调用之间才可以接受进程终止的信号，说明某个原子调用无法结束导致无法被kill -9终止
3）CRS通过脚本无法接管故障节点vip,出现超时
4）CRS通过脚本无法检测存活节点本身的vip/监听等资源，均出现超时
5）存活节点Nmon故障点后无输出
2.10 问题分析一度陷入僵局
虽然把方向放在操作系统上，但AIX专家未检查到异常。
AIX专家的结论是操作系统当时是没有异常的！
因为他们检查了一些crontab的脚本，是有输出的，说明OS还在工作。
如下图所示
2.11 如何找到突破口
笔者把方向定到了操作系统，但是操作系统专家检查并否认操作系统有异常。
对于存活节点nmon为什么停止写入的问题，双方持不同意见。
至此，问题分析陷入僵局，该如何继续往下分析呢？怎么能证明操作系统的异常呢？
1)如果没有给到操作系统一个明确的点，那么操作系统是很难查到到底有哪些异常的问题
2)问题分析陷入僵局，该如何找到突破口成为关键
3)坚信操作系统异常这个方向是正确的
回到原点，重新梳理和验证每个线索，会不会漏掉了什么重要线索
重新检查之前的线索，有重大发现！
可以看到：
从16点02分以及后续的的采样可以看到，到了” The file system result is as follows”的检测就停止了，没有写SYSTEM.SH_RUN_COMPLETE关键字来表示脚本执行完成.这说明操作系统在执行非数据库命令时也遇到了异常！
2.12 确认shell脚本出现异常时调用的具体命令
检查shell脚本,发现脚本挂在” The file system result is as follows:”的地方，事实上是调用了df命令来查看文件系统。
那么这个操作在什么情况会出现HANG的情况呢。
答案是使用nfs文件系统的时候。
XX系统数据库集群中使用了NFS文件系统，将节点2的/arch2文件系统通过NFS挂载到了节点1的/arch2文件系统上。当节点2出现硬件故障后，导致节点1无法与节点2的nfs server通讯，继而导致节点1上，df命令查看文件系统时挂起。
由此来看，节点1 nmon数据停止的原因是df命令hang住了
但是这和节点1无法连接数据库又有什么关系呢？
当笔者看到df命令时，泪奔了！
所有现象都可以得到解释了！当所有现象都得到解释的时候，心里就踏实了！这意味着你找到了问题的根因，那么预防措施就万无一失了！
2.13 Nfs mount点丢失和无法连接数据库的关系
执行连接数据库操作时，需要获取当前工作目录(pwd)
但是由于AIX某些版本操作系统内部实现pwd过程的缺陷,导致必须递归到根目录/下检查目录或文件的权限、类型.
当检查到nfs时，由于nfs 以hard/background方式挂载，当nfs server不可用时，必然导致检查nfs目录时出现挂起，继而导致了无法获得pwd的输出结果，继而导致无法连接数据库!
2.14 解开所有谜团
1） 存活节点Sqlplus –prelim无法attach到共享内存
获取当前工作目录时，由于nfs mount点丢失，get_cwd(pwd)挂起
2） Kill -9 无法杀掉部分进程
进程对nfs mount点进行IO操作，挂起，因此没有机会收到进程终止信号
3） CRS通过脚本无法接管故障节点vip,出现超时
Racgwrap脚本中调用了pwd命令
4） CRS通过脚本无法检测存活节点本身的vip/监听等资源，均出现超时
Racgwrap脚本中调用了pwd命令
5） 存活节点Nmon故障点后无输出
Nfs mount点丢失导致nmon调用df命令时挂起
2.15 再往前一步的分析
1.该机制下，如果根目录/小文件或目录很多，则pwd(get_cwd)的性能会很差
2.测试环境重现过程
节点2 mount /testfs到节点1的/testfs,停止节点2 nfs服务，未能重现。原因在于pwd的输出为/oracle, 首字母o比t要小，因此未检测到/testfs就获得pwd结果而退出了
节点2 mount /aa到节点1的/aa,停止节点2 nfs服务，未能重现。原因是通过truss命令对比，发现生产和测试环境检索/根目录下的行为不一致，继而检查OS版本，发现测试环境OS版本较高
3.高版本的OS无法重现，低版本的操作系统可以重现，说明操作系统做了修正和增强，在ibm.com上已nfs hang搜索，可以发现IBM发布了APAR来修复该问题
3 原因总结和建议
3.1 原因总结
RAC集群节点2所在的P595 发生硬件故障，导致节点2 LPAR不可用。继而导致Nfs mount点丢失。
登陆数据库时，需要获取当前工作目录(pwd)。
但是由于AIX某些版本操作系统内部实现pwd过程的缺陷,导致必须递归到根目录/下检查目录或文件的权限、类型。
当检查到nfs挂载点目录/arch2时，由于nfs 以hard/background方式挂载，当nfs server不可用时，必然导致检查nfs目录时出现挂起，继而导致了无法获得pwd的输出结果，继而导致无法连接数据库!
以hard/background挂载的NFS server丢失是导致RAC成为伪集群的根本原因！
所有故障现象都可以得到解释，如下：
1）存活节点Sqlplus –prelim无法attach到共享内存
获取当前工作目录时，由于nfs mount点丢失，get_cwd(pwd)挂起
2）Kill -9 无法杀掉部分进程
进程对nfs mount点进行IO操作，挂起，因此没有机会收到进程终止信号
3）CRS通过脚本无法接管故障节点vip,出现超时
Racgwrap脚本中调用了pwd命令
4）CRS通过脚本无法检测存活节点本身的vip/监听等资源，均出现超时
Racgwrap脚本中调用了pwd命令
5）存活节点Nmon故障点后无输出
Nfs mount点丢失导致nmon调用df命令时挂起
3.2 问题解决方案和建议
1） 如果需要实用nfs,则mount到二级目录，比如mount到/home /arch2而不是/arch2
2） 使用gpfs代替nfs
3） 提供故障线索时，请勿根据个人经验过滤掉认为不重要的信息
4） 安装AIX APAR，改变操作系统get_cwd(pwd)调用的内部实现方式
5）处理故障时Df命令hang的情况如果一开始就反馈，那么这个case直接就解开了，就不需要查了！
6）只在上线前做高可用测试是不够的，因为上线后系统会经历一系列的变更，可能某些因素会报纸RAC冗余性丢失，建议定期做高可用测试，可以选择在变更窗口选择逐个重启实例、服务器的方式来进行验证。
原题：我和数据中心的故事——Oracle RAC高可用失效风险提醒
作者：黄远邦（曾用笔名小y）,就职于北京中亦安图科技股份有限公司，任数据库团队技术总监。长期活跃于国内多家银行总行生产数据中心，提供Oracle第三方服务，解决过无数疑难问题，在业内具有极佳的口碑。
本文地址：http://www.aixchina.net/Article/177843
长按下图二维码关注“AIX专家俱乐部”公众号
也可以直接搜索公众号名称“AIX专家俱乐部”或微信号“AIXChina”关注