Oracle 11g RAC启动失败报ORA-27154等错误，主因是残留IPC资源（shm/sem）未清理，需先停CRS、再按序清理oracle属主的共享内存和信号量，并验证kernel.shmmax/shmall及OCR/ASM状态。
oracle 11g rac 启动失败若报 ora-27154、ora-27300、ora-27301 或 ora-27302，且日志中出现 failed to create shared memory segment，基本可以确认是残留的 ipc 资源（尤其是共享内存段）未清理干净 —— 这不是数据库配置问题，而是操作系统级资源冲突，必须手动干预。
检查残留的 Oracle 共享内存段和信号量
Oracle 11g RAC 使用 System V IPC 资源（shm、sem），RAC 实例异常终止后常遗留这些资源。直接启动会因 key 冲突或空间不足失败。
- 用
ipcs -m查看所有共享内存段，重点关注 owner 为oracle、大小异常（如几 GB）、且无对应进程的段 - 用
ipcs -s查看信号量集，RAC 每个实例通常占用多个信号量（如 128 个），残留信号量会导致ORA-27300（OS system dependent error: No space left on device） - 配合
ps -ef | grep pmon确认当前无运行中的pmon进程，否则说明实例仍在运行，不能强行清理
安全清理 IPC 资源的顺序和命令
顺序错误会导致后续实例无法分配资源，尤其 RAC 多节点环境下，必须先停所有实例再统一清理；单节点误操作也可能引发 CRS 重启失败。
- 先停 CRS：以
root执行crsctl stop crs（确保 no CRS 进程在跑） - 再清理：用
ipcs -m | awk '$5 == "oracle" {print $2}' | xargs -I {} ipcrm -m {}清内存段；同理用ipcs -s | awk '$5 == "oracle" {print $2}' | xargs -I {} ipcrm -s {}清信号量 - 切勿使用
ipcs -a | ipcrm—— 会误删其他应用（如 PostgreSQL、WebLogic）的 IPC 资源 - 清理后务必执行
ipcs -m -s确认输出为空，再启动 CRS
启动时仍报 ORA-27154？检查 kernel 参数是否被覆盖
即使 IPC 清理干净，若系统重启后内核参数未持久生效，或 Oracle 自身调用 shmget() 时指定的 key 与当前可用 shmmax 不匹配，仍会失败。
- 检查
/etc/sysctl.conf中kernel.shmmax和kernel.shmall是否 ≥ 实例sga_max_size（单位字节），例如 SGA 设为 4GB，则kernel.shmmax至少为4294967296 - RAC 必须确保所有节点参数一致，且
sysctl -p执行后sysctl kernel.shmmax输出值与配置一致 - Oracle 11.2.0.4+ 默认启用
USE_LARGE_PAGES=only时，若大页未分配成功，也会退回到 shm，但此时对 shm 参数要求更高 —— 可临时在$ORACLE_HOME/dbs/init中加.ora use_large_pages=disabled排查
为什么 srvctl start database 总卡住或静默失败？
srvctl 依赖 OCR 和 CSSD，而 CSSD 启动前需验证 IPC 可用性。若清理不彻底或 kernel 参数未加载，CSSD 会反复尝试创建 IPC 资源并超时退出，导致 srvctl 看似“没反应”。
- 查
$GRID_HOME/log/，搜索/cssd/ocssd.log shmat、shmget、semget错误行 - 不要跳过
crsctl check crs—— 必须看到CRS-4638: Oracle High Availability Services is online才能继续 - 若 OCR 在 ASM 中，确认 ASM 实例已 up（
srvctl status asm），否则 OCR 读取失败会导致 CSSD 初始化失败，进而掩盖真实的 IPC 问题
真正麻烦的不是清理命令本身，而是判断哪些段该留、哪些该删 —— 特别是当多个 Oracle 版本共存或测试库混用时，ipcs 输出里 owner 都是 oracle，但 key 值对应不同实例。这时候得结合 oradebug ipc（在已启动的实例中）或 strings /proc/ 反向溯源，否则删错一个正在用的段，整个集群就挂了。
