SHOUG成员 – ORACLE ACS高级顾问罗敏
Oracle公司自10g版本开始就推出了集群管理软件CRS，以后又升级改造成Clusterware，到11g版本之后更是大动干戈，内部架构进行了大幅度改造，并与ASM技术整合在一起，称之为GI（Grid Infrastructure）。Clusterware替代了硬件厂商和第三方厂商的集群软件功能，也使得Oracle RAC与Clusterware集成为一体，在产品的整体性、服务支持一体化等方面具有显著优势。
作为新产品、新技术，稳定性、成熟性略差，情有可原。但到了11g仍然如此，则让人难以理解了。
本人最近在Windows 2012平台实施了2节点11.2.0.4 RAC，并通过增加节点方式扩展到了4节点RAC，在国内实属罕见案例。期间一些波折，表明 Clusterware产品仍然不成熟。
话说那天我在实施节点扩展操作之前，先花费了半天时间进行了新节点的环境准备之后，并通过如下命令进行了环境检查：
cluvfy stage -pre nodeadd -n hsedb3 –verbose
… …
节点 “hsedb3” 上的共享存储检查成功
硬件和操作系统设置 的后期检查成功。
哟，一切都“成功”，开练了！于是，我按照Oracle文档标准流程在节点1开始运行AddNode.bat脚本了，一切“正常”！我继续在节点3运行了gridconfig.bat等脚本。
待所有脚本顺利运行完之后检查环境时，却发现节点3根本没有加入到集群环境中，节点3上的Clusterware服务也根本没有启动。—– 这就是产品的严重不成熟，明明出问题了，所有脚本却不显示任何一条返回错误，显示一切正常！更可气的是，AddNode.bat脚本的日志文件（addNodeActions2014-09-07_04-52-22PM.log）也居然显示一切正常，最后还来一句：
*** 安装 结束 页***
C:\app\11.2.0\grid 的 添加集群节点 已成功。
我知道Oracle支持在Windows平台进行RAC加节点操作，但现在没有成功，一定是我犯什么错误了，也肯定知道有什么错误信息藏在什么鸟日志文件里了。无奈天色已晚，忙乎一天了，于是先打道回府了。
隔日，待我回到现场仔细分析各类Clusterware日志文件信息时，首先在alerthsedb3.log文件中大海捞针般地发现了出错信息：
[cssd(4484)]CRS-1649:表决文件出现 I/O 错误: \\.\ORCLDISKORADG0; 详细信息见 (:CSSNM00059:) (位于 C:\app\11.2.0\grid\log\hsedb3\cssd\ocssd.log)。
于是，按图索骥继续去查询ocssd.log文件中的信息。又像侦探一样，在ocssd.log文件8千多行的日志信息中发现了如下错误信息：
2014-09-07 17:00:06.192: [ SKGFD][4484]ERROR: -9(Error 27070, OS Error (OSD-04016: 异步 I/O 请求排队时出错。
O/S-Error: (OS 19) 介质受写入保护。)
此时，其实本人已经觉察出问题了：可能是节点3对存储设备只有读权限，连表决盘（Voting Disk）都没有写入功能，从而导致失败了。为保险期间，还是根据上述出错信息在Metalink中进行了一番搜索，果然如此！《Tablespace (Datafile) Creation On ASM Diskgroup Fails With “[ORA-15081: Failed To Submit An I/O Operation To A Disk] : [ O/S-Error: (OS 19) The media Is Write Protected]” On Windows. ( Doc ID 1551766.1 )》详细描述了原委和解决方案。于是，按照该文档的建议，我将节点3对所有共享存储设备的权限从只读状态修改为可读、可写的联机状态。也明白一个细节：新节点对共享存储设备的权限缺省为只读状态。无论如何，安装之前没有仔细检查共享存储设备的权限是我犯的一个错误。
接下来该是重新进行节点增加操作了。且慢！因为前面已经错误地进行了节点增加操作，而且居然显示成功了，那么运行AddNode.bat脚本的节点1肯定已经在OCR、Voting Disk等集群文件中写入节点3不正确的信息了。因此，需要先实施从集群中删除节点3的操作，但是发现Oracle标准文档中的删除节点操作的如下第一条命令有错误！
C:\>Grid_home\perl\bin\perl -I$Grid_home\perl\lib -I$Grid_home\crs\install
Grid_home\crs\install\rootcrs.pl -deconfig -force
又是一番折腾，将上述命令修改如下：
cd \app\11.2.0\grid
C:\>perl\bin\perl -I perl\lib -I crs\install crs\install\rootcrs.pl -deconfig –force
终于顺利删除了节点3！
现在可以重新来一遍了。这次一马平川地成功增加了节点3的Clusterware以及RAC，还有节点4的Clusterware和RAC。
感悟之一：明明节点3对共享存储只有读权限，而cluvfy却说：节点 “hsedb3” 上的共享存储检查成功！一定是cluvfy只检查了读权限，而没有检查写权限。很可能是cluvfy的Bug!
感悟之二：明明增加节点3的操作失败了。但不仅AddNode.bat没有在命令行及时显示错误，而且对应的日志文件还显示“添加集群节点已成功”。极大地误导客户！罪不可恕！
感悟之三：诊断Clusterware问题太难了！Oracle公司没有告诉客户Clusterware问题的诊断思路，特别是日志文件太多了，不知道先看哪个日志文件，后看哪个日志文件。此次本人完全是凭经验，先看了alerthsedb3.log文件，才找到问题的蛛丝马迹，进而逐步确认问题并加以解决。
… …
总之，Clusterware仍然是一个非常不成熟的产品！
Leave a Reply