环境配置
服务器配置：

数据库配置：

1.问题描述

问题发生过程描述：
神龙Oracle rac由于空间问题希望扩容根目录，扩容失败，导致相关的asm磁盘组多路径映射出现问题导致集群挂起，经过确认是由于该规格的神龙服务器不支持在线扩容，因此重新恢复到原始状态以后，rac集群只有节点2可以正常启动，节点1无法启动；

2.问题分析

由于存储相关内容丢失，联系阿里存储同学恢复到原来神龙主机状态后，asm相关的映射连接也恢复了回来；
但是整个映射的dm顺序两个节点不同，故而怀疑是否是存储顺序挂载顺序错乱导致？
但是经过对比虽然dm顺序不同，但是实际的对应划分磁盘的uuid是一致的；

所以排除了是由于顺序错乱问题导致集群启动异常；
尝试去启动节点1集群，启动以后自动就关闭了集群服务，再次查看集群服务无法查看如下图报错；

查看集群状态发现除了磁盘组相关的asm服务外，监听，vip等相关的节点1服务相应也都启动了起来，所以从这里判断还是和磁盘组有关系。
但是我们来查看节点1的asm的alert日志发现并未有新的asm日志写入到alert log当中，从现象看好像asm磁盘组在节点1上直接被集群没有再识别到，换句话说集群的启动并未把asm服务纳入到启动序列里；
Ps：排查日志是2020-10-20

检查相关的crs的alert日志发现报错无法识别asm，无法读取相应的磁盘，ocr磁盘组不可访问；
进而查看相关的trc文件日志内容如下报错：
报错的主要内容就是相关的olr文件，磁盘组等读取没有权限；
less /u01/app/grid_base/diag/crs/ora12c1/crs/trace/crsd_oraagent_oracle.trc

less /u01/app/grid_base/diag/crs/ora12c1/crs/trace/ocrcheck_73764.trc
因此就对比了两侧的磁盘组相关的文件权限情况发现两端完全一致，grid用户测试磁盘的读写也可以进行；
所以考虑重新reload一下asm磁盘组在试试看能否解决；
所以执行了reload操作；

再次启动节点1集群发现启动后crs服务还是无法通信，但是ocr心跳盘可以看到了，并且和节点2对比相应的id都是一致的；
问题排查到这里感觉已经没有可以排查的方向了；
既然这里ocr已经启动正常，那么就可以尝试去启动asm实例和数据库实例看看；
果然asm实例可以正常启动成功，磁盘组正常挂载，数据库实例也可以正常启动；


但是奇怪的是，虽然这些实例及磁盘组可以正常启动，但是查看集群状态节点1依然不可看，节点2看到的是依然磁盘组是offline，rac1的db实例也未正常启动；

但是到了这里希望已经很大了，既然手动可以拉起所有的服务，那么就可以再次尝试重启集群看看能不能将所有的服务拉起来；
因此重新关闭节点1集群并重启，果然集群被正常拉了起来；

查看集群状态已经完全恢复正常

3.问题解决

重新做磁盘组映射的reload，手动尝试启动asm及db实例，重启集群；
ps：其中对于内部实现原理和运行机制还有些模糊，各位看官请多指教；