故事背景:
某用户由于原有一套RAC中,node2 出现莫名其妙的网络问题,导致集群基本处于单点故障。需要用一台新pc往原有集群中增加一个新的节点。
领衔主演:
OS,redhat linux 5.4 (为什么说是领衔,且看故事主体部分),oracle 11.2.0.1. RAC
整个故事发展过程(普通的在普通的add node node to cluster 见:http://docs.oracle.com/cd/B19306_01/rac.102/b14197/adddelunix.htm#BEIJAJHH):
1. 配置安装cluster 和oracle rdbms的操作系统package、调整kernl 参数、oracle环境变量和用户及用户组等等准备工作;
2. 实用11.2.0.1 cluster 软件cluvfy 工具对集群、rdbms 、add node安装前做预检查,见 CVU实用介绍: http://blog.csdn.net/wengtf/article/details/9112565
3. 利用$GRID_HOME/bin/addnode.sh 将新节点(node 3)加入cluster 软件、$ORACLE_HOME/bin/addnode.sh将node3加入rdbms;
4. dbca 建立 instance 3(node 3 ),此过程会将asm扩展至node 3;
5. 最后一步如果成功数据库整个add node to cluster 的过程基本可以成功结束、可惜这一步始终无法完成,实例 3 无法启动,出现如下报错:
ORA-01105:mount is incompatible with mounts by other instances
ORA-01606:parameter not identical to that of another mounted instance
验证环节:
首先将节点1和2 关闭后,节点3 能够正常启动,同时1和2 启动时候出现同上错误,反之亦然。此时明确该错误确为数据库启动时检查集群间参数一致性出现问题,具体是哪个参数不得而知。
查阅MOS后,发现最有可能是由于 _gc_* 开头的几个隐含参数配置不一致所致,但是具体哪一个亦然未知。此时已经是诸多努力无果后有点胸闷,难道我是地球上第一个碰到这个问题的人???
/**说来也奇怪,今天自己的左眼一直跳,给了我灵感,偶然想到去检查了下node3 的cpu数量,惊讶地发现node3的cpu 居然有64 core,这什么情况??一个大胆而又迷信的想法,左眼跳要有戏啊,思路莫非对了?是因为cpu数量不一致引起的?因为我百度时看到过一个类似的bug ,莫非就是我也中招了???**/
MOS bug 验证:
该bug 9729692 , MOS 没有公开发布补丁,只能通过升级到11.2.0.2 才能绕过这问题,可现在停机窗口不存在,只能另想方法,从PC机本身的CPU去绕过,一台普通的PC机为何有这么多core??也咨询了O记得几个工程师,均表示该bug 得升级来解决,除非讲cpu往下降(原厂攻城师也同意我得猜测)。
大胆建议:
跟用户交代了目前的猜测和可能存在的问题,用户也表示该pc机cpu可能存在超线程,建议用户是否能将CPU 超线程(多core)的配置取消之后尝试启动节点3.
故事结局:
结果证明,我果然不是地球上遇到这问题的第一人,rac3 instance 能正常启动了...后续的消缺工作略,.故事也就讲完了。。。。 各位观众,我得感谢我的左眼......