点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
故障介绍
由于业务量增长，生产环境的数据库服务器需要扩容，需要把原本512GB 的内存扩大到了1024GB, 在此基础上需要 调整SGA 的大小和连接数，以便分配更多的缓存。计划调整SGA为400g,PGA调整为250g，连接数调整为40000。
首先是按照要求把SGA 从调整到400g, ,PGA调整为220g 这样一个服务器，oracle就占用660GB, 还有350GB 的空余。其次保证另一个节点故障转移之后，先修改一个节点，启动成功后，再修改另外一个节点。最后参数修改完成后准备重启数据库1节点的时候，报了下面的错误：
SQL> startup
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semget failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpsemid2
ORA-27303: additional information: maxsems = 304, verify_semcnt = 0
显示的是空间的问题，我检查了空间情况，没有发现什么异常。用 free -m 检查内存的使用情况，还有很多的空余内存。
故障处理
2.1 错误分析
检查数据库日志：
Errors in file u01/app/oracle/diag/rdbms/orc19/orc19/trace/orc19_ora_3994.trc:
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semget failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpsemid2
ORA-27303: additional information: maxsems = 304, verify_semcnt = 0
查看trc文件,从trc文件看不出问题，尝试一个参数一个参数的修改，检查到底是哪个参数在设置后出现问题。
2.2 逐一检查参数检查
参数总共修改了3个，先恢复原样，可以正常启动数据库，那就可以确认数据库参数原本是正常的。只修改SGA，数据库可以正常启动。只修改PGA，数据库可以正常启动。只修改processes，数据库不可以正常启动。看来这个参数设置后，需要修改系统层面的参数。
2.3 MOS资料查找
在MOS上查找相关错误资料，找到如下文档（Doc ID 2789636.1）
Changes
Attempted startup of a newly created database instance.
Cause
The error occurs due to the exhaustion of total number of semaphore sets/arrays.
Solution
Overview
Semaphores are an interprocess communication (IPC) locking/synchronisation mechanism allowing processes/threads to interoperate and coordinate their activity.
Various processes on a system require and utilise semaphores, therefore sufficient semaphores must be configured for the intended use case.
One kernel parameter, kernel.sem, is used to configure multiple system semaphore settings i.e.
kernel.sem =
大概意思，信号量是一种进程间通信(IPC)锁定/同步机制，允许进程/线程互操作和协调它们的活动。系统上的各种进程需要和使用信号量，因此必须为预期的用例配置足够的信号量。一个内核参数，kernel.Sem，用于配置多个系统信号量设置。
2.4 测试验证参数
为验证确实为processes参数值受kernel.Sem影响，我们在虚拟机上先设置processes为20000，kernel.Sem设置为默认：
[root@localhost ~]# cat /etc/sysctl.conf |grep sem
kernel.sem = 250 32000 100 128
SQL> alter system set processes=20000 scope=spfile;
System altered.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORA-00838: Specified value of MEMORY_TARGET is too small, needs to be at least 4288M
ORA-01078: failure in processing system parameters
由于虚拟机内存分配较小，导致启动失败，调整虚拟机内存参数，再次尝试启动。在修改虚拟机内存大小后数据库可以正常启动。尝试把sem信号量调小，看数据库能否正常启动：
[root@localhost ~]# cat /etc/sysctl.conf |grep sem
kernel.sem = 250 1200 100 128
SQL> startup nomount pfile='/home/oracle/pfile.ora'
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semget failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpcreates
此时数据库启动失败，再调大一些，测试结果：
[root@localhost ~]# cat /etc/sysctl.conf |grep sem
kernel.sem = 250 3000 100 128
SQL> startup nomount
ORACLE instance started.
Total System Global Area 3925867552 bytes
Fixed Size 8903712 bytes
Variable Size 2147483648 bytes
Database Buffers 1761607680 bytes
Redo Buffers 7872512 bytes
[root@localhost ~]# ipcs -s
------ Semaphore Arrays --------
key semid owner perms nsems
0x5381ac88 557056 oracle 600 250
0x5381ac89 589825 oracle 600 250
0x5381ac8a 622594 oracle 600 250
0x5381ac8b 655363 oracle 600 250
0x5381ac8c 688132 oracle 600 250
0x5381ac8d 720901 oracle 600 250
0x5381ac8e 753670 oracle 600 250
0x5381ac8f 786439 oracle 600 250
0x5381ac90 819208 oracle 600 250
可以看到的确这个sem信号量和processes有着某种关联，而且此时启动到nomount状态，实际并没有用户连接，说明信号量是预先分配的，可以看到，NSEMS值为250，一共9组，此时可以满足2000的processes。后面再次调整sem信号量到2000，数据库启动失败，不再列图，看来sem信号量必须要大于process才能启动。
总 结：
通过这个案例，可以知道ipcs看的那个信号量和process之间有直接的关联。咨询我司专家，这之间还存在某种算法，并不是一对一的关系，此处不再深究。
END
本文作者：胡 伟 (上海新炬中北团队）
本文来源：“IT那活儿”公众号
