重启数据库遇到错误ORA-27154,ORA-27300,ORA-27301,ORA-27302
重启数据库遇到错误ORA-27154,ORA-27300,ORA-27301,ORA-27302
事情是这样的，新装了一套 Linux 环境下的 19.9 RAC 环境，应用方要求关闭归档。本身此机器上有三个实例，均是近期新建的实例并安装 RU 19.9，先将节点二的实例关闭然后在节点一上关闭归档，前两个实例都完成了且正常启动，当第三个实例关闭归档时，在节点一上是正常启动了，但是在节点二启动数据库则报错了，如下图：
节点2
sqlplus / as sysdba
shutdown immediate;
节点1
sqlplus / as sysdba
archive log list;
alter system switch logfile；
关闭归档
shutdown immediate;
startup mount;
--开启归档模式：
--alter database archivelog;
关闭归档模式：
alter database noarchivelog;
alter database open;
archive log list;
节点2
sqlplus / as sysdba
startup
使用操作系统自带的帮助命令没有查到想要的信息。
网络上搜索则说是由于内核参数 kernel.sem 的问题， 而且与 process 有关，在安装多实例数据库时也会出现如下的错误。第一次在创建多实例时居然没有报错，而且当时也是设置了每个实例的 process 为 8000 重启实例并没有问题，那么 kernel.sem 到底是个什么参数，与 process 有什么样的关系，这引起了我的好奇：
kernel.sem = 250 32000 100 128
SEMMSL: 每个信号集的最大信号数量
SEMMNS：用于控制整个 Linux 系统中信号的最大数
SEMOPM：内核参数用于控制每个 semop 系统调用可以执行的信号操作的数量
SEMMNI ：内核参数用于控制整个 Linux 系统中信号集的最大数量
SEMMSL * SEMMNI = SEMMNS 即 250 * 128 = 32000
网络上给出的错误原因：processes 总数超出操作系统信号量总大小。
而我的实际配置是 kernel.sem = 10240 32767 10240 32767
内核参数显示如下: kernel.sem = 10240 32767 10240 32767 ----------->>>> This indicates that 10240 semaphores can be accomodated in an array and maximum of 32767 arrays can be in the system. 这表明一个阵列可以容纳 10240 个信号量，系统中最多可以容纳 32767 个阵列。
这里也可称之为数组，表示每个数组中有 10240 个信号量，总共有 32767 个数组。 So, in total, 335534080 (10240X32767) semaphores can present in the system. 所以，总共有 10240X32767=335534080 个信号量 。
[root@JiekeXu ~]$ ipcs
...
----- Semaphore Arrays --------
key semid owner perms nsems
0x21b9674c 196610 oracle 660 127
0x21b9674d 229379 oracle 660 127
0x21b9674e 262148 oracle 660 127
...
If we assume this is the case here.
假如我们遇到的是这种情况，
So, here, the actual semaphore accommodated per array is not 250, it is 127.
这说明每个数组中不是250，而是127，
So, practically, only 16256 (128*127) can present in the server.
所以只有16256个可用的信号量，这也就是我们计算processes总量远远未达到32000，但是依旧报错的原因，
Solution
解决方案：
kernel.sem = 250 32000 100 128 ---- >>>> This indicates that 250 semaphores can be accomodated in an array and maximum of 128 arrays can be in the system.
So, in total, 32000 (250X128) semaphores can present in the system.
Thus We need to increase the maximum number of arrays that can be present on the server.
Kindly follow the below steps :
-----------------------------------
1. Query the current semaphore values in the kernel
# /sbin/sysctl -a | grep sem
2. Modify SEMMNI value in the /etc/sysctl.conf.
From
kernel.sem = 250 32000 100 128
To
kernel.sem = 250 32000 100 200
3. # /sbin/sysctl -p
这里建议的是将kernel.sem修改为250X200,，但是中间的32000未改变，
但是根据在support.redhat.com 上的文档
How to increase the number of semaphores：
将sysctl.conf中设置为
kernel.sem = 250 64000 100 256
并sysctl -p ,解决该问题。根据此文档建议将 kernel.sem 设置为 10240 335534080 10240 32767 然后 sysctl -p 生效后重启数据库便可以正常启动了。
当然，根据网络上的建议将 process 重新改小也可以启动，但是改多小不好评估，由于时间关系这里便没有展开测试。最后看一下各个内核参数的大概意义：
[root@JiekeXu ~]# sysctl -p
fs.aio-max-nr = 1048576 #异步IO请求数目 推荐值是：1048576 其实它等于 1024*1024 也就是 1024K 个
fs.file-max = 6815744 #打开的文件句柄的最大数量,防止文件描述符耗尽的问题
kernel.shmall = 2097152 #共享内存总量 页为单位,内存除以4K所得
kernel.shmmax = 4294967295
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128 #SEMMSL: 每个信号集的最大信号数量 SEMMNS：用于控制整个 Linux 系统中信号的最大数
# SEMOPM：内核参数用于控制每个 semop 系统调用可以执行的信号操作的数量 SEMMNI ：内核参数用于控制整个 Linux 系统中信号集的最大数量
net.ipv4.ip_local_port_range = 9000 65500 #用于向外连接的端口范围
net.core.rmem_default = 262144 #套接字接收缓冲区大小的缺省值
net.core.rmem_max = 4194304 #套接字接收缓冲区大小的最大值
net.core.wmem_default = 262144 #套接字发送缓冲区大小的缺省值
net.core.wmem_max = 1048576 #套接字发送缓冲区大小的最大值
fs.file-max = 6815744
kernel.watchdog_thresh = 30当semmni和semmns参数值是官方文档默认值时，按业务要求设置process为8000，无法启动实例。将semmni和semmns参数值都设置为二倍值之后，再测试将process设置为16000时，同样无法启动实例。可以看到的确这个sem信号量和processes有着某种关联，而且此时启动到nomount状态，实际并没有用户连接，说明信号量是预先分配的。
设置 processes 值为默认值 150 时，ipcs 可以看到 NSEMS 的数值是 154，此时可以满足 150 的 processes；设置 processes 值为默认值 300 时，ipcs 可以看到 NSEMS 的数值是 152，此时可以满足 300 的 processes；设置 processes 值为 8000 时， ipcs 可以看到 NSEMS 的数值是 8004，此时可以满足 8000 的 processes；设置 processes 值为 16000 时，启动数据库则报错 ORA-27154,ORA-27300,ORA-27301,ORA-27302；根据这个也没法确定两者的关系，但确实两者之间有所关联，而且算法还不简单，现在已经太晚了，只能等后续有时间再看了，晚安，小伙伴们！
参考链接：
https://blog.csdn.net/dsc1245/article/details/80743753
https://www.cnblogs.com/jyzhao/p/9124373.html
Instance Startup Fails With Error ORA-27154,ORA-27300,ORA-27301,ORA-27302 (Doc ID 314179.1)
Database Startup Fails with ORA-27300: OS system dependent operation:semget failed with status: 28 (Doc ID 949468.1)
好咯，今天的分享就到这里了，如果本文对您有一丁点儿帮助，请多支持“在看”与转发，不求小费了哪怕是一个小小的赞，您的鼓励都将是我熬夜写文章最大的动力，让我有一直写下去的动力，最后一起加油,奥利给！