由于问题引起信号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         Defines the maximum semaphores on the system.
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.

Parameter	Value	File
semmsl semmns semopm semmni	250 32000 100 128	/proc/sys/kernel/sem

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查找问题，可能找到解决方式，但更重要的是可以知道原因。进而了解问题出现的场景。结合自己的问题。确定是同一类之后，再运行操作，一句话：要慎重。

版权声明：本文博主原创文章。博客，未经同意不得转载。