# CRS启动报错CRS-1656处理分享

> 作者/来源: UCloud 运营管理员
> 发布时间: 2023-01-11T05:20:00.000Z
> 分类: 其他
> 标签: AI
> 原文链接: http://117.50.162.249:3000/yun/articles/651

---

# CRS启动报错CRS-1656处理分享

> 来源: https://www.ucloud.cn/yun/130248.html
> 作者: IT那活儿
> 发布日期: 发布于2023-01-11 13:20

CRS启动报错CRS-1656处理分享

**咧咧故事：**内部转岗在很多公司其实是很平常的一件事情，但最近身边出现一件事情，让我觉得每个人的思维边界还是需要通过不断学习来扩充的。事情的经过大概是某个场地的一个员工，来了2年时间，做的事情都是一成不变，为了让他有更好的成长，leader给其安排轮岗，找他沟通安排时，该员工直接炸毛，表示这种安排对他是一种侮辱，且以离职作为抗拒的理由。

**咧咧心得：**相信每一个有点儿成长的组织都是在交付项目的同时，想方设法在交付项目的同时，提升团队的技术能力水平，毕竟自己的本事才是自己真正的衣食父母。但饭端到嘴边，连张嘴都觉得累，这事儿就没法儿玩了。由此想到我们说的焦虑，打开一个APP铺天盖地的IT40岁焦虑的文章，有段时间我也焦虑了，但发现焦虑不是没用，是没一点儿用。那与其焦虑，不如该学点儿什么学点儿什么，该让自己长点儿本事的就长点儿本事。但是，像这种饭送到你嘴边都嫌累的，更是需要多读书，多学习。我一直信奉人蠢多读书的信条，因为我是一个蠢人，但也得活不，也得养老养小不，人生别抱怨，以一份感恩的心态，干就完了。

**咧咧启示：**这个人能在这个团队呆2年，现在才被发现，说明这个团队的管理也是出了问题的。除非公司有矿，否则是不会允许一个员工一成不变只做一类事情，还这样任性的无所畏惧。这里给我们的启示是团队组建过程中的选才问题，每个成熟的团队组织选才都应该有自己的指标依据，否则天马行空，靠第六感，就像信号不稳定的导航，后果就是导到坑里去了，下面这张图是我选择团队成员时候总结的考察项，供各位看官参考：

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130248/images/130248_000.png)

---

**下面是另外的故障处理，上下无关联**

---

技术分享：

一、故障场景：

节点2因为主机出现硬件故障，硬件修复后主机启动，主机重启后CRS自动拉起失败，报错如下：

CRS alert日志：

2018-12-15 11:43:03.118

[cssd(6116)]CRS-1603:CSSD on node hneoms6 shutdown by user.

2018-12-15 11:43:03.137

[ohasd(16642)]CRS-2765:Resource ora.cssdmonitor has failed on server hneoms6.

2018-12-15 11:43:12.344

[ohasd(16642)]CRS-2767:Resource state recovery not attempted for ora.diskmon as its target state is OFFLINE

2018-12-15 11:43:25.815

[cssd(8639)]CRS-1713:CSSD daemon is started in clustered mode

2018-12-15 11:43:34.832

[cssd(8639)]CRS-1637:Unable to locate configured voting file with ID 4b5ba6dc-75f94f99-bf952ee3-24d218aa; details at (:CSSNM00020:) in /app/oracle/11203/grid/log/hneoms6/cssd/ocssd.log

2018-12-15 11:43:34.832

[cssd(8639)]CRS-1705:Found 0 configured voting files but 1 voting files are required, terminating to ensure data integrity; details at (:CSSNM00021:) in /app/oracle/11203/grid/log/hneoms6/cssd/ocssd.log

2018-12-15 11:43:34.832

[cssd(8639)]CRS-1656:The CSS daemon is terminating due to a fatal error; Details at (:CSSSC00012:) in /app/oracle/11203/grid/log/hneoms6/cssd/ocssd.log

2018-12-15 11:43:34.888

[cssd(8639)]CRS-1603:CSSD on node hneoms6 shutdown by user.

2018-12-15 11:43:34.907

[ohasd(16642)]CRS-2765:Resource ora.cssdmonitor has failed on server hneoms6.

2018-12-15 11:43:41.064

[ohasd(16642)]CRS-2771:Maximum restart attempts reached for resource ora.cssd; will not restart.

2018-12-15 14:20:26.769

[mdnsd(18163)]CRS-5602:mDNS service stopping by request.

2018-12-15 14:20:29.981

二、环境背景：

该套RAC安装时使用udev定义磁盘路径/asmdisk/下的磁盘，其软链接指向/dev/rdsk/emcpower\*下的磁盘。

后面由于ASM磁盘空间不足新加一批磁盘，此批新加磁盘未使用udev重定义磁盘路径，直接创建成新的磁盘组。

当时基于ASM需要识别新磁盘的考虑，将asm\_diskstring的值从/asmdisk/修改成/asmdisk/,/dev/rdsk/emcpower\*。

三、处理思路及过程；

1)查看CRS发现无法识别votedisk。

2)通过kfed read votedisk发现磁盘可读，并查看votedisk的权限是正确的。grid，oracle用户均可读写。

3)进一步分析发现/asmdisk/及/dev/rdsk/emcpower\*均可以读取votedisk，按正常思维来看，asm\_diskstring是完全没问题的。

换个角度思考，是不是因为这2个路径都能读取相同的votedisk导致ASM出现识别混乱呢？

4)方向有了那就开始干吧，在存活节点asm\_diskstring修改成只有一个路径的值/asmdisk/。

5)在节点2把一些已经拉起的进程宕下来，然后重新拉起CRS，发现CRS拉起成功。但是节点2由于新的ASM磁盘组由于新磁盘路径问题，

识别不到磁盘导致没有mount。将asm\_diskstring的值从/asmdisk/修改成/asmdisk/,/dev/rdsk/emcpower\*,这样就可以将新的ASM磁盘组mount起来。

四、后续如何做才能避免此类故障；

如果不修改asm\_diskstring，后面只要CRS重启都会出现CRS无法自动启动的相同故障。

后续通过将后面加入的新磁盘通过udev重定向至/asmdisk/目录下，

然后将asm\_diskstring的值从/asmdisk/,/dev/rdsk/emcpower\*修改成/asmdisk/即可永久避免此类故障。

五、使用到的命令：

1、存活节点操作

su - grid

sqlplus / as sysasm

create pfile=/grid/p.ora from spfile;

alter system set asm\_diskstring=/asmdisk/ scope=spfile;

2、宕掉节点操作

su - root

crsctl stop crs -f

crsctl start crs

su - grid

sqlplus / as sysasm

alter system set asm\_diskstring=/asmdisk/,/dev/rdsk/emcpower\* scope=both;

alter diskgroup xxx mount;

su - oracle

sqlplus / as sysdba

startup

--alter system set asm\_diskstring=/asmdisk/ scope=both;