为什么Oracle 21c RAC实例频繁重启

Oracle 21c RAC实例频繁重启几乎总是由ocssd.bin失稳引发，需优先检查其进程稳定性及ocssd.log中CRS-1611/1610、IPC超时或磁盘心跳失败；同时核查gipcd.log中的gipcretTimeout、私网MTU一致性、OCR磁盘组状态及CTSSD时间同步。

Oracle 21c RAC实例频繁重启，**几乎总是由底层集群服务（尤其是ocssd.bin）失稳引发，而非数据库自身崩溃**。直接查alert.log或trace文件容易误判——真正驱逐节点的指令来自CSSD，不是DB或ASM。

先确认ocssd是否真稳定

CRSD和ASM都依赖ocssd.bin提供集群成员状态和心跳仲裁。它一抖，整个节点就可能被驱逐。

1. 执行ps -ef | grep ocssd：看进程是否存在、运行时长是否持续超过几分钟（刚启动几秒就消失是典型抖动）
2. 检查/u01/app/19c/grid/log/<hostname>/cssd/ocssd.log（21c默认路径类似，非11g旧路径）中是否密集出现CRS-1611、CRS-1610或IPC Send timeout detected
3. 若ocssd.log里有disk heartbeat failed，但crsctl query css votedisk显示路径可读，说明ASM磁盘组没mount或OCR所在DG状态为DISMOUNTED，不是磁盘物理故障

gipcd超时和MTU不一致是21c高频诱因

21c默认启用GIPC（Grid IPC）替代旧版UDP心跳，对网络参数更敏感。私网MTU不一致会导致gipcretTimeout反复报错，最终触发驱逐。

1. 在所有节点执行ip link show <private_if> | grep mtu，确保私网接口MTU完全一致（推荐统一设为9000，禁用jumbo frame则用1500）
2. 查/u01/app/19c/grid/log/<hostname>/gipcd/gipcd.log，搜索gipcretTimeout或gipc network disconnect，时间点要与节点重启严格对齐
3. 不要只改Linux内核参数；AIX或OEL需同步检查ndd或sysctl.conf中net.ipv4.ip_forward、net.ipv4.conf.<if>.arp_ignore等关联项

ora.asm卡在ONLINE INTERMEDIATE时别硬启DB

CRSD启动后卡住，常见于ASM起来了但OCR磁盘组无法mount。此时强行srvctl start database会触发资源注册冲突，导致CRSD反复清理自身状态后崩溃重启。

1. 运行crsctl stat res -t | grep -E "(ora.cssd|ora.asm|ora.storage)"，确认ora.cssd必须为ONLINE，否则CRSD根本无法初始化
2. 若ora.asm是ONLINE INTERMEDIATE，进asmcmd执行lsdg，看OCR所在DG（通常是+OCR或+GRID）状态是否为MOUNTED；若为DISMOUNTED，查asmcmd lsdsk输出设备权限（应为grid:oinstall，裸设备660）
3. 多路径环境下，重点核对/dev/mapper/<wwid>在各节点是否指向同一LUN——scsi_id -g -u -d /dev/sdX比ls -l /dev/dm-*更可靠

ORA-29740不是原因，是驱逐结果

看到alert_<inst>.log里大量ORA-29740，别在DB层调优。它只说明“本节点已被踢出”，根因一定在ocssd.log或gipcd.log里。

1. ORA-29740总伴随this node was evicted by node X或evicting instance Y from cluster，往前翻日志至少10分钟，定位第一个gipc超时或disk heartbeat failed时间点
2. 若ocssd.log里同时出现Authentication OSD error, op: scls_auth_response_prepare loc: mkdir，检查/u01/app/19c/grid/css/auth/目录空间是否满（21c默认路径已变，非11g的/u01/oracle/product/.../css/auth/）
3. 时间不同步在21c仍会引发驱逐，但CTSSD日志（ctssd.log）报错比NTP offset值更关键；ctssctl check输出ACTIVE:yes才算真正稳住

复杂点在于：21c的GIPC和CSSD日志分散在多个子目录（gipcd/、cssd/、ohasd/），且错误传播链长——一个MTU不匹配，可能先在gipcd.log报超时，再触发ocssd.log丢心跳，最后才让CRSD崩溃。漏掉任一层日志，就会绕远路。