安装集群GRID/GI一般包括三个过程：首先，运行OUI/RunInstaller输入集群配置信息，其次，拷贝/编译集群文件，最后，以root用户运行root.sh脚本配置集群/启动集群，其中运行root.sh脚本是最关键的阶段。接触过很多SR case都是在这个阶段出现错误导致安装失败。如果问题修复后，需要先deconfigure 已有的配置，然后再运行root.sh。从11.2.0.2版本开始支持重复运行root.sh脚本，也就是说修复问题后，可以直接再运行root.sh，并且从上次失败的地方继续安装（类似”断点续传”）。这个特性在12c中又得到增强。实现这个功能主要是通过将安装阶段信息记录到checkpoint文件和OCR文件来实现：
11.2 checkpoint文件位置
$ORACLE_BASE/Clusterware/ckptGridHA_${nodename}.xml
12c checkpoint文件位置
$ORACLE_BASE/crsdata/$hostname/crsconfig/ckptGridHA_${nodename}.xml
下面分享一个安装12.1.0.2 集群GRID/GI, 运行root.sh 脚本失败的案例。
案例分享
=========
在Linux系统上安装12.1.0.2 集群GRID/GI软件，节点2运行root.sh失败，屏幕的错误信息：
OLR initialization - successful
2015/12/15 13:16:55 CLSRSC-507: The root script cannot proceed on this node rac2 because either the first-node operations have not completed on node rac1 or there was an error in obtaining the status of the first-node operations.
以上错误说明节点2无法确认节点1安装状态是否完成。Root.sh是如果来确认节点1安装是否完成呢？需要检查日志：
$GRID_HOME>/cfgtoollogs/crsconfig/rootcrs_rac2_2015-12-18_09-41-53PM.log
2015-12-18 21:42:39: Trying to get the value of key: SYSTEM.rootcrs.checkpoints.firstnode in OCR.
2015-12-18 21:42:39: setting ORAASM_UPGRADE to 1
2015-12-18 21:42:39: Check the existence of key pair with key name: SYSTEM.rootcrs.checkpoints.firstnode in OCR.
2015-12-18 21:42:39: setting ORAASM_UPGRADE to 1
2015-12-18 21:42:39: Invoking "/u01/gridsoft/12.1.0/bin/cluutil -exec -keyexists -key checkpoints.firstnode"
2015-12-18 21:42:39: trace file=/u01/gridbase/crsdata/rac2/crsconfig/cluutil9.log
2015-12-18 21:42:39: Running as user grid: /u01/gridsoft/12.1.0/bin/cluutil -exec -keyexists -key checkpoints.firstnode
2015-12-18 21:42:39: s_run_as_user2: Running /bin/su grid -c ' echo CLSRSC_START; /u01/gridsoft/12.1.0/bin/cluutil -exec -keyexists -key checkpoints.firstnode '
2015-12-18 21:42:39: Removing file /tmp/filexr1WwO
2015-12-18 21:42:39: Successfully removed file: /tmp/filexr1WwO
2015-12-18 21:42:39: pipe exit code: 256
2015-12-18 21:42:39: /bin/su exited with rc=1
2015-12-18 21:42:39: oracle.ops.mgmt.rawdevice.OCRException: PROC-32: Cluster Ready Services on the local node is not running Messaging error [gipcretConnectionRefused] [29]
2015-12-18 21:42:39: Cannot get OCR key with CLUUTIL, try using OCRDUMP.
2015-12-18 21:42:39: Check OCR key using ocrdump
2015-12-18 21:42:54: ocrdump output: PROT-302: Failed to initialize ocrdump
2015-12-18 21:42:54: The key pair with keyname: SYSTEM.rootcrs.checkpoints.firstnode does not exist in OCR.
以上信息说明节点2首先执行cluutil -exec -keyexists -key checkpoints.firstnode命令来查看OCR中的key: SYSTEM.rootcrs.checkpoints.firstnode，失败后又尝试执行OCRDUMP命令，但是OCRDUMP命令也失败。接下来分析OCRDUMP命令也失败的原因：
$GRID_BASE/diag/crs/<node>/crs/trace/ocrdump_13146.trc
2015-12-18 21:42:48.098879 : OCRASM: ASM Error Stack : ORA-29701: unable to connect to Cluster Synchronization Service
2015-12-18 21:42:48.098885 : OCRASM: proprasmo: ASM instance is down. Proceed to open the file in dirty mode.
CLWAL: clsw_Initialize: Error [32] from procr_init_ext
CLWAL: clsw_Initialize: Error [PROCL-32: Oracle High Availability Services on the local node is not running Messaging error [gipcretConnectionRefused] [29]] from procr_init_ext
2015-12-18 21:42:48.101773 : GPNP: clsgpnpkww_initclswcx: [at clsgpnpkww.c:351] Result: (56) CLSGPNP_OCR_INIT. (:GPNP01201: )Failed to init CLSW-OLR context. CLSW Error (3): CLSW-3: Error in the cluster registry (OCR) layer. [32] [PROCL-32: Oracle High Availability Services on the local node is not running Messaging error [gipcretConnectionRefused] [29]]
2015-12-18 21:42:48.112746 : OCRASM: proprasmo: Error [13] in opening the GPNP profile. Try to get offline profile
2015-12-18 21:42:48.220769 : OCRRAW: kgfo_kge2slos error stack at kgfolclcpi1: AMDU-00210: No disks found in diskgroup OCR_VOTING
以上信息提示无法连接ORA-29701 CSS和PROCL-32 OHASD这些都是正常的，因为节点2集群没有启动，这些错误可能会干扰我们分析问题。关键的错误信息是AMDU-00210: No disks found in diskgroup OCR_VOTING，也就是说节点2没有找到ASM disk导致OCRDUMP失败，因此无法确认节点1安装的状态是否完成。接下来我们执行kfed确认ASM disk是否有问题：
节点1查看disk /dev/raw/raw1
$ /u01/gridsoft/12.1.0/bin/kfed read /dev/raw/raw1
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD <=========disk raw1类型是KFBTYP_DISKHEAD，是正常的asm disk
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: blk=0
kfbh.block.obj: 2147483648 ; 0x008: disk=0
kfbh.check: 420965027 ; 0x00c: 0x19176aa3
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
...
kfdhdb.vfstart: 128 ; 0x0ec: 0x00000080 <=========vfstart 值说明这个disk是vote file
kfdhdb.vfend: 160 ; 0x0f0: 0x000000a0 <=========vfend 值说明这个disk是vote file
节点2查看disk /dev/raw/raw1
$ /u01/gridsoft/12.1.0/bin/kfed read /dev/raw/raw1
kfbh.endian: 0 ; 0x000: 0x00
kfbh.hard: 0 ; 0x001: 0x00
kfbh.type: 0 ; 0x002: KFBTYP_INVALID<=========节点2上查看raw1类型是无效的KFBTYP_INVALID
kfbh.datfmt: 0 ; 0x003: 0x00
kfbh.block.blk: 0 ; 0x004: blk=0
kfbh.block.obj: 0 ; 0x008: file=0
kfbh.check: 0 ; 0x00c: 0x00000000
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
000000000 00000000 00000000 00000000 00000000 [................]
Repeat 255 times
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
在节点1查看/dev/raw/raw1显示disk 类型是KFBTYP_INVALID，并且kfdhdb.vfstart有值，说明raw1在节点1是正常的asm disk，并且是vote disk。但是节点2查看相同的disk，显示完全不同的信息。正常情况下，配置的共享设备raw1在节点1和节点2看到的信息应该是一致的，但是这个case中节点1和节点2看到的是不同的信息，说明共享disk配置是不正确的。
同时，在节点1手动执行OCRDUMP确认key SYSTEM.rootcrs.checkpoints.firstnode是存在的，并且状态是” SUCCESS”
su – root
ocrdump /tmp/ocrdump1.out
more /tmp/ocrdump1.out
[SYSTEM.rootcrs.checkpoints.firstnode]
ORATEXT : SUCCESS
最后，修改UDEV配置文件(/etc/udev/rules.d/99-oracle-asmdevices.rules)后问题解决。