因信号量问题导致ORA-27154无法启动数据库

测试库执行startup时提示(11.2.0.1)：

查询ORA-27154的错误：

Error:  ORA-27154
Text:   post/wait create failed 
---------------------------------------------------------------------------
Cause:  internal error, multiple post/wait creates attempted simultaneously 
Action: check errno and contact Oracle Support

提示是一个内部错误，多个post/wait同时请求。

df查看磁盘空间还有很多，不存在占满的情况。

查看报错中的semget含义：

提示segmet的含义是get a semaphore set identifier，即获取一个信号量集标识符。说明此错误可能和未获得信号量有关，No space left on device不是指存储空间，而是指信号量资源。

从MOS的介绍看(949468.1)，一系列的报错出现10.1.0.2到11.2.0.2的范围内。给出了示例：

$ ipcs -ls

------ Semaphore Limits --------

max number of arrays = 128

max semaphores per array = 250

max semaphores system wide = 32000

max ops per semop call = 100

semaphore max value = 32767

产生的原因是，从原理上看，32000信号量可用，一个信号量标识符能包含最大250个信号量。但是ipcs命令展示每个信号量标识符仅能让Oracle包含最大156个信号量。

$ ipcs <<这个示例中没有启动额外实例的前提下，大约包含100个信号量字符集

..

------ Semaphore Arrays --------

key semid owner perms nsems

0x450e15bd 0 root 666 1

0x0000cace 32769 root 666 1

0x358b172c 327683 oracle 660 104

0x9053d038 11075588 oracle 660 156

0x9053d039 11108357 oracle 660 156

0x9053d03a 11141126 oracle 660 156

0x9053d03b 11173895 oracle 660 156

..

那么可用的最大信号量就是156*128=19968，不是32000。

解决方法增加可包含的信号量，这里根据SEMMNI参数来调整设置。

1. 查询当前kernel的信号量参数值。

# /sbin/sysctl -a | grep sem

2. 修改/etc/sysctl.conf文件的SEMMNI参数。

从kernel.sem = 250 32000 100 128修改为kernel.sem = 250 32000 100 200

3. 使用# /sbin/sysctl -p让修改生效。

结合到我这里的情况，首先查看ipcs的结果：

数据库启动后，需要从操作系统上分配共享内存和信号量，信号量就相当于OS的内存锁，类似于Oracle的latch(注意Oracle的锁和latch的区别)，每个进程需要获取操作系统内存时，需要先获得信号量才能申请内存。

从上述指令可以看到最大可用的信号量是100，信号量标识符集最大是128，呃，这里失误，当时没有查看到ipcs实际的信号量标识符集。这里4个参数的含义：

SEMMSL         100        Defines the minimum recommended value,for initial installation only

The maximum number of sempahores that can be in one semaphore set. It should be same size as maximum number of Oracle processes.

一个信号量集中允许的最大信号量数。需要和Oracle的process个数相同。

SEMMNS        100

This setting is a minimum recommended value, for initial installation only. The SEMMNS parameter should be set to the sum of the PROCESSES parameterfor each Oracle database, adding the largest one twice, and then adding an additional 10 for each database.

系统允许的最大信号量数，SEMMNS参数应设置为最大的PROCESSES值，再加上额外的10，算出来的总和。(注意这里说明该值是最小的建议值)

SEMOPM        32          Defines the maximum number of operations for each semop call

每次信号量调用的最大操作数。

SEMMNI        128         Defines the maximum number of semaphore sets in the entire system

系统中信号量集的最大值。

可以推测SEMMNS=SEMMSL * SEMMNI。

但上述示例中：100<>100 * 128，SEMMNS最大允许的信号量(建议最小值)只有100，显然不能满足计算结果的数量。而且从Oracle官方文档看到的对于这几个参数的推荐值：

Configuring Kernel Parameters

Verify that the kernel parameters shown in the following table are set to values greater than or equal to the recommended value shown. The procedure following the table describes how to verify and set the values.

SEMMNS是32000，即SEMMSI(250) *SEMMNI(128)的结果。

进而可以推断报错提示的sskgpcreates可能和process数量有关，kernel中和该值有关的参数是SEMMNS，和上述推测的结论相同，即PROCESS过多，但允许的最大信号量过少，两者不匹配，导致No space left on device提示信号量资源不足。

解决方法如MOS指点的，修改信号量参数值，可以用：

这种方式只是临时修改，机器重启后失效，若需要持久生效，可以修改/etc/sysctl.conf对应的参数值。

总结：

1. 错误提示No space left on device未必表示存储空间不足，本例中就是指的信号量资源。

2. kernel.sem中四个参数的含义，以及SEMMNS(允许的最大信号量)=SEMMSL(一个信号量集允许包含的信号量) * SEMMNI(系统允许包含的最大信号量集)的计算关系，还有就是SEMMNS定义的是Defines the maximum semaphores on the system. This setting is a minimum recommended value,for initial installation only.，但这个值是用于初始安装的最小推荐值。

3. 借助baidu或google甚至MOS查找问题，可能找到解决方案，但更重要的是能够知道原因，进而了解问题出现的场景，结合自己的问题，确定是同一类之后，再执行操作，一句话：要谨慎。