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

作者：袖梨 2026-08-15

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。

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

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

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

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

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

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

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

ORA-29740总伴随this node was evicted by node X或evicting instance Y from cluster，往前翻日志至少10分钟，定位第一个gipc超时或disk heartbeat failed时间点
若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/）
时间不同步在21c仍会引发驱逐，但CTSSD日志（ctssd.log）报错比NTP offset值更关键；ctssctl check输出ACTIVE:yes才算真正稳住