UX平台Oracle启动实例遭遇:ORA


环境:HP-UX 11.31 + Oracle 11.2.0.4
现象:在hpux安装Oracle,按业务需求配置参数后,无法启动实例。
 报错如下:
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

1.初步定位
2.验证猜想
3.深入分析

1.初步定位

快速判定这是实例就无法启动,也就是nomount这一阶段就无法成功,首先想到的是参数配置不合理。
 经过尝试,最终发现是processes参数设置过高,导致无法启动实例,当前期望设置8000,测试调整为7000就可以成功启动。

去MOS搜索hpux平台这个错误没有找到结果,但是却有其他平台的匹配结果:
•Database Startup Fails with ORA-27300: OS system dependent operation:semget failed with status: 28 (文档 ID 949468.1)

•Instance Startup Fails With Error ORA-27154,ORA-27300,ORA-27301,ORA-27302 (文档 ID 314179.1)

而这些文档的原因基本定位在sem相关的内核参数调整上。

2.验证猜想

找到HPUX关于sem内核参数的当前设置:
kctune -h -B semmni=4096
kctune -h -B semmns=8192
kctune -h -B semmnu=4092
kctune -h -B semvmx=32767

这些都是Oracle官方文档建议的设置值,但现在看来,目前这些内核参数的设置不能满足此时用户业务所要求的processes值。

网上搜索到这些内核参数值的说明:

UX平台Oracle启动实例遭遇:ORA

种种迹象都表明和sem参数有关,那么尝试将semmni和semmns参数都修改为2倍值,即8192和16384。
kctune -h -B semmni=8192
kctune -h -B semmns=16384

--重启操作系统生效:
shutdown -ry 0

之后再次将processes设置为8000,已经可以正常启动实例,问题解决。

3.深入分析

当semmni和semmns参数值是官方文档默认值时,按业务要求设置process为8000,无法启动实例。将semmni和semmns参数值都设置为二倍值之后,再测试将process设置为16000时,同样无法启动实例。
 可以看到的确这个sem信号量和processes有着某种关联,而且此时启动到nomount状态,实际并没有用户连接,说明信号量是预先分配的,下面来具体验证。
 以下所有测试都是启动数据库到nomount:

3.1 设置processes值为默认值150
此时ipcs观察到的结果:
Superdome10@oracle[/oradata/orcl]ipcs -as
IPC status from /dev/kmem as of Fri Jun  1 16:57:15 2018
T                  ID    KEY        MODE        OWNER    GROUP  CREATOR    CGROUP NSEMS  OTIME    CTIME
Semaphores:
s                    0 0x4f1c06da --ra-------      root      root      root      root    1 11:44:05 11:44:05
s                    1 0x411c01b6 --ra-ra-ra-      root      root      root      root    1 11:44:07 11:44:05
s                    2 0x4e0c0002 --ra-ra-ra-      root      root      root      root    2 11:44:07 11:44:05
s                    3 0x41203bb5 --ra-ra-ra-      root      root      root      root    2 no-entry 11:44:05
s                    4 0x01090522 --ra-r--r--      root      root      root      root    1 no-entry 11:44:11
s                8197 0x00a5c581 --ra-------    sfmdb    users    sfmdb    users    17 11:44:13 11:44:13
s                8198 0x00a5c582 --ra-------    sfmdb    users    sfmdb    users    17 11:44:13 11:44:13
s                8199 0x00a5c583 --ra-------    sfmdb    users    sfmdb    users    17 11:44:13 11:44:13
s                8200 0x00a5c584 --ra-------    sfmdb    users    sfmdb    users    17 11:44:13 11:44:13
s                8201 0x00a5c585 --ra-------    sfmdb    users    sfmdb    users    17 11:44:13 11:44:13
s                8202 0x00a5c586 --ra-------    sfmdb    users    sfmdb    users    17 11:44:13 11:44:13
s                8203 0x00a5c587 --ra-------    sfmdb    users    sfmdb    users    17 16:32:32 11:44:13
s                  12 0x4914942f --ra-r--r--      root      root      root      root    1 11:44:32 11:44:32
s                  13 0x410c030b --ra-ra-ra-      root      root      root      root    1 11:44:33 11:44:33
s              196622 0x5c23a1bc --ra-r-----    oracle      dba    oracle      dba  154 no-entry 16:47:46

可以看到NSEMS的数值是154,此时可以满足150的processes。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/f5589b09f64dad4f9174132ccdbf2b6d.html