天天看點

因信号量問題導緻ORA-27154無法啟動資料庫

測試庫執行startup時提示(11.2.0.1):

因信号量問題導緻ORA-27154無法啟動資料庫

查詢ORA-27154的錯誤:

提示是一個内部錯誤,多個post/wait同時請求。

df檢視磁盤空間還有很多,不存在占滿的情況。

檢視報錯中的semget含義:

因信号量問題導緻ORA-27154無法啟動資料庫

提示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的結果:

因信号量問題導緻ORA-27154無法啟動資料庫
因信号量問題導緻ORA-27154無法啟動資料庫

資料庫啟動後,需要從作業系統上配置設定共享記憶體和信号量,信号量就相當于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官方文檔看到的對于這幾個參數的推薦值:

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

<code>/proc/sys/kernel/sem</code>

SEMMNS是32000,即SEMMSI(250)*SEMMNI(128)的結果。

進而可以推斷報錯提示的sskgpcreates可能和process數量有關,kernel中和該值有關的參數是SEMMNS,和上述推測的結論相同,即PROCESS過多,但允許的最大信号量過少,兩者不比對,導緻No

space left on device提示信号量資源不足。

解決方法如MOS指點的,修改信号量參數值,可以用:

因信号量問題導緻ORA-27154無法啟動資料庫

這種方式隻是臨時修改,機器重新開機後失效,若需要持久生效,可以修改/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. 即允許的最大信号量,但這個值是用于初始安裝的最小推薦值。

借助baidu或google甚至MOS查找問題,可能找到解決方案,但更重要的是能夠知道原因,進而了解問題出現的場景,結合自己的問題,确定是同一類之後,再執行操作,一句話:要謹慎。