ORA-27300/27301/27302错误直接表明CSS因/dev/shm共享内存不足强制驱逐节点；需在/etc/fstab中永久设tmpfs /dev/shm大小为至少8G（≥128G内存建议16G），并重启CRS生效，仅调大kernel.shmmax无效。
ORA-27300、ORA-27301、ORA-27302 错误直接指向共享内存不足
这类错误在 Oracle RAC 日志（alert.log 或 ocssd.log）中频繁出现时，基本可判定是节点因无法获取足够共享内存（shm）被 CSS（Cluster Synchronization Services）强制驱逐。不是数据库实例挂了，而是集群心跳中断——CSS 认为该节点“失联”，主动踢出以保集群一致性。
/dev/shm 大小不足是最常见的根因
Linux 上 Oracle RAC 依赖 /dev/shm 作为 IPC 共享内存载体，尤其用于 CSS、CRS、ASM 等后台进程通信。默认大小通常只有 4GB，而现代 RAC 节点（尤其启用大页或高并发）很容易突破该限制。
-
df -h /dev/shm查看当前挂载大小 -
mount | grep shm确认是否已显式挂载（而非仅 tmpfs 默认值） - 生产环境建议设为至少
8G，内存 ≥128G 的节点建议16G - 修改方式：在
/etc/fstab中添加一行tmpfs /dev/shm tmpfs size=16g 0 0，然后sudo umount /dev/shm && sudo mount /dev/shm - 注意：仅修改
/etc/sysctl.conf中的kernel.shmmax不起作用——CSS 不走 sysv shm，只认/dev/shm的 tmpfs 大小
Oracle 19c+ 启用大页（HugePages）后必须同步调整 /dev/shm
启用 use_large_pages=only 或 auto 后，Oracle 实例不再使用 /dev/shm 做 SGA，但 CSS/CRS 仍强依赖它。此时若 /dev/shm 过小，反而更容易触发驱逐——因为 CSS 内部结构（如 voting disk 缓存、member heartbeat buffer）会争抢有限空间。
- 检查是否启用大页：
grep -i huge /proc/meminfo和cat $ORACLE_HOME/rdbms/admin/oraenv.sh | grep use_large_pages - 即使 SGA 已搬进大页，
/dev/shm仍需保留充足余量（≥8G），不能缩减 - 禁用大页不会自动修复
/dev/shm，必须单独调大 - 重启 CRS（
crsctl stop crs && crsctl start crs）才能让 CSS 重新加载新大小，仅重启数据库实例无效
确认 CSS 是否真因 shm 耗尽崩溃
别只看 alert.log，要交叉验证 ocssd.log 才能定位真实原因。该日志路径通常是 $GRID_HOME/log/<hostname>/cssd/ocssd.log。
- 搜索关键词：
"No space left on device"、"shmget failed"、"Unable to create shared memory segment" - 典型报错行：
ERROR: clsc_send_msg: sendmsg(23) failed with errno 28 (No space left on device) - 如果日志里出现
rebooting the node或node eviction initiated，且紧邻上述 shm 错误，则基本锁定 - 避免误判：磁盘满（
/u01或 OCR/Voting Disk 所在文件系统）、NTP 时间漂移、网络隔离也会导致驱逐，需排除
真正棘手的是多节点同时抖动时，/dev/shm 不足常和 CRS 资源争抢耦合——比如某个节点 CRS 进程异常泄漏 shm 段，会拖垮整个集群稳定性。所以调大只是第一步，后续必须用 ipcs -m 定期检查是否有未释放的共享内存段，并结合 crsctl stat res -t 观察资源状态是否持续 flapping。
