crs-4535 错误本质是 ora.crsd 资源 offline 或通信异常，需先用 crsctl stat res -t -init 确认状态，再检查 asm 磁盘组（尤其 ocr/voting）是否 mounted、ocrcheck 是否 success、节点时间差是否超 600 秒、asm 设备权限是否为 grid:asmadmin 及 /dev/shm 是否 ≥4gb，最后尝试 crsctl start res ora.crsd -init 或清理 /var/tmp/.oracle/npohasd。
CRS-4535 错误本质是 crsd 进程没起来或无法通信，不是“集群坏了”，而是 CRS 的核心服务 ora.crsd 处于 OFFLINE 或未响应状态。直接重启 crs 往往无效，必须定位具体卡点。
检查 ora.crsd 资源真实状态
运行 crsctl stat res -t -init，重点看 ora.crsd 行的 STATE 列：
- 若显示
OFFLINE，说明进程根本没启动，需进一步查日志或手动启 - 若显示
INTERMEDIATE或卡在STARTING，大概率是依赖项失败（如 ASM 磁盘组未 mount、OCR 不可用） - 若显示
ONLINE但仍有 CRS-4535，可能是进程僵死或 IPC 通信异常（常见于/var/tmp/.oracle/npohasd文件残留）
验证 ASM 磁盘组和 OCR 是否就绪
CRS 启动强依赖 ASM 存储，尤其 OCR 和 VOTING 磁盘组必须 ONLINE：
- 用
grid用户执行sqlplus / as sysasm，运行select name,state,type from v$asm_diskgroup; - 确认
STATE为MOUNTED，且TYPE包含EXTERN或NORMAL（不能是DISMOUNTED） - 运行
ocrcheck，输出必须包含STATUS: SUCCESS；若失败，需从备份还原 OCR（路径通常为$ORACLE_HOME/cdata/<cluster_name>/</cluster_name>） - 注意：即使其他磁盘组（如 DATA、FRA）Dismount，只要 OCR/VOTING 正常，
ora.crsd就应能启动
排查时间同步与权限问题
节点间时间差 >600 秒或 ASM 设备权限错误，会直接导致 crsd.bin 启动失败：
- 用
date命令比对所有节点系统时间，误差超过 10 分钟就必须校准；切勿向后跳调时间，应先停集群，再用ntpdate或chronyd同步，最后写入硬件时钟（hwclock --systohc） - 检查 ASM 设备权限：
ls -l /dev/asm*或ls -l /dev/mapper/*，确保属主是grid:asmadmin，权限至少为brw-rw----；若属主是root:disk，需用chown grid:asmadmin修正 - 检查
/dev/shm大小是否足够：Oracle 12c+ 要求 ≥ 4GB，df -h /dev/shm查看，不足则修改/etc/fstab并mount -o remount /dev/shm
尝试安全重启 ora.crsd 而非整套 CRS
强制 crsctl stop crs -f 可能破坏资源状态，优先尝试只重启关键组件：
- 先停依赖项：
crsctl stop res ora.asm -init（避免 ASM 卡住 crsd） - 再启核心：
crsctl start res ora.crsd -init；成功后立即验证crsctl check crs - 若仍失败，再清理 IPC：
rm -f /var/tmp/.oracle/npohasd，然后重试启动 - 注意：不要在节点 1 执行
crsctl start crs的同时，节点 2 还在运行 VIP 漂移逻辑——这会导致 SCAN IP 冲突，建议单节点操作并观察日志$GRID_HOME/log/<hostname>/crsd/crsd.log</hostname>
真正棘手的是那些看似都正常却仍报 CRS-4535 的情况：比如 ora.crsd 显示 ONLINE，但 ps -ef | grep crsd.bin 找不到进程，或 strace -p 跟踪发现卡在 connect(/var/tmp/.oracle/sOHASD)。这时候得盯住 ohasd 日志，而不是反复重启。
