ipcs、ipcrm、sysresv、kernel.shmmax

ipcs、ipcrm、sysresv、kernel.shmmax

 

1.1  BLOG文檔結構圖

 

 

 

1.2  前言部分

1.2.1  導讀和注意事項

各位技術愛好者，看完本文後，你能夠掌握以下的技能，也能夠學到一些其它你所不知道的知識，~O(∩_∩)O~：

① ipcs的使用

② ipcrm釋放oracle內存段

③ sysresv的使用

④ 內核參數kernel.shmmax

⑤ 如何快速的清理Oracle的進程

⑥ 其它維護操做

 

Tips：

① 本文在itpub（http://blog.itpub.net/26736162）、博客園(http://www.cnblogs.com/lhrbest)和微信公衆號（xiaomaimiaolhr）上有同步更新。

② 文章中用到的全部代碼、相關軟件、相關資料及本文的pdf版本都請前往小麥苗的雲盤下載，小麥苗的雲盤地址見：http://blog.itpub.net/26736162/viewspace-1624453/。

③ 若網頁文章代碼格式有錯亂，請下載pdf格式的文檔來閱讀。

④ 在本篇BLOG中，代碼輸出部分通常放在一行一列的表格中。

⑤ 本文適合於初中級人員閱讀，數據庫大師請略過本文。

⑥ 不喜勿噴。

本文若有錯誤或不完善的地方請你們多多指正，您的批評指正是我寫做的最大動力。

1.3  本文簡介

最近有朋友由於kernel.shmmax內核參數的問題致使數據庫不能啓動。小麥苗以前碰到過一次，只是沒有記錄下來，並且之前安裝數據庫的時候也沒有詳細介紹這幾個參數的含義，趁此次機會就把這個參數在詳細介紹一下吧。

 

1.4  相關文章連接

① 【故障解決】IPCS和IPCRM使用：http://blog.itpub.net/26736162/viewspace-2112518

② ORACLE內核參數：http://blog.itpub.net/26736162/viewspace-2112447/

③ sysresv：http://blog.itpub.net/26736162/viewspace-2112443/

④ 視頻講解IPCS和IPCRM使用：http://www.iqiyi.com/w_19rs33qqsp.html

⑤ 有關「TNS-12518: TNS:listener could not hand off client connection」的更多內容請參考：【故障|監聽】TNS-1251八、TNS-00517和 Linux Error：32：Broken pipe：http://blog.itpub.net/26736162/viewspace-2135468/

 

第二章 ipcs/ipcrm命令

更多內容請參考：http://blog.itpub.net/26736162/viewspace-2112518

 

unix/linux下的共享內存、信號量、隊列信息管理

在Unix或Linux下，常常有由於共享內存、信號量，隊列等共享信息沒有乾淨地清除而引發一些問題。

查看共享內存的命令是：ipcs [-m|-s|-q]。若ipcs命令不帶參數，則默認會列出共享內存、信號量，隊列信息，而-m列出共享內存，-s列出共享信號量，-q列出共享隊列。

清除命令是：ipcrm [-m|-s|-q] id，其中，-m刪除共享內存，-s刪除共享信號量，-q刪除共享隊列。

[oracle@rhel6lhr ~]$ ipcs -h ipcs provides information on ipc facilities for which you have read access. Resource Specification:         -m : shared_mem         -q : messages         -s : semaphores         -a : all (default) Output Format:         -t : time         -p : pid         -c : creator         -l : limits         -u : summary -i id [-s -q -m] : details on resource identified by id usage : ipcs -asmq -tclup         ipcs [-s -m -q] -i id         ipcs -h for help.

 

 

 

2.1  ipcs

1. 命令格式

 

ipcs [resource-option] [output-format]

ipcs [resource-option] -i id

 

2. 命令功能

 

提供IPC設備的信息

 

3. 使用方法

 

resource選項：

ipcs -m 查看系統共享內存信息

ipcs -q 查看系統消息隊列信息

ipcs -s 查看系統信號量信息

ipcs [-a] 系統默認輸出信息，顯示系統內全部的IPC信息

[martin@localhost data]$ ipcs -a   ------ Message Queues -------- key        msqid      owner      perms      used-bytes   messages      ------ Shared Memory Segments -------- key        shmid      owner      perms      bytes      nattch     status      0x00000000 229376     martin     600        4194304    2          dest         0x00000000 196609     martin     600        524288     2          dest         0x00000000 327682     martin     600        393216     2          dest         0x00000000 491525     martin     600        2097152    2          dest           ------ Semaphore Arrays -------- key        semid      owner      perms      nsems

 

輸出格式控制：

 

ipcs -c 查看IPC的建立者和全部者

ipcs -l 查看IPC資源的限制信息

ipcs -p 查看IPC資源的建立者和使用的進程ID

ipcs -t 查看最新調用IPC資源的詳細時間

ipcs -u 查看IPC資源狀態彙總信息

[martin@localhost data]$ ipcs -u --human   ------ Messages Status -------- allocated queues = 0 used headers = 0 used space = 0B   ------ Shared Memory Status -------- segments allocated 4 pages allocated 1760 pages resident  339 pages swapped   0 Swap performance: 0 attempts     0 successes   ------ Semaphore Status -------- used arrays = 0 allocated semaphores = 0

 

 

額外格式控制：

ipcs -l --human

以人類能夠閱讀的方式顯示size

[martin@localhost data]$ ipcs -l --human   ------ Messages Limits -------- max queues system wide = 3644 max size of message = 8K default max size of queue = 16K   ------ Shared Memory Limits -------- max number of segments = 4096 max seg size = 16E max total shared memory = 16E min seg size = 1B   ------ Semaphore Limits -------- max number of arrays = 128 max semaphores per array = 250 max semaphores system wide = 32000 max ops per semop call = 32 semaphore max value = 3276

 

 

 

[oracle@rhel6lhr ~]$ ipcs -l   ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 98442 max total shared memory (kbytes) = 3221512 min seg size (bytes) = 1   ------ Semaphore Limits -------- max number of arrays = 2048 max semaphores per array = 250 max semaphores system wide = 256000 max ops per semop call = 100 semaphore max value = 32767   ------ Messages: Limits -------- max queues system wide = 7643 max size of message (bytes) = 65536 default max size of queue (bytes) = 65536

 

2.2  ipcrm

1. 命令功能

經過指定ID刪除刪除IPC資源，同時將與IPC對象關聯的數據一併刪除，只有超級用戶或IPC資源建立者可以刪除

2. 使用方法

ipcrm -M shmkey

移除用shmkey建立的共享內存段

ipcrm -m shmid

移除用shmid標識的共享內存段

ipcrm -S semkey

移除用semkey建立的信號量

ipcrm -s semid

移除用semid標識的信號量

ipcrm -Q msgkey

移除用msgkey建立的消息隊列

ipcrm -q msgid

移除用msgid標識的消息隊列

 

2.3  如何快速的清理Oracle的進程？

 

真題一、 如何快速的清理Oracle的進程？

答案：若想要快速清理掉Oracle的進程，則最直接的辦法是殺pmon進程。有以下3條命令可供選擇，其中加粗的orcl替換成ORACLE_SID的值便可。

kill -9 `ps -ef|grep orcl| grep -v grep | awk '{print $2}'` ps -ef |grep orcl|grep -v grep|awk '{print $2}' | xargs kill -9 ipcs -m | grep oracle | awk '{print $2}' | xargs ipcrm shm

若想要快速殺掉集羣的進程，則能夠執行以下命令：

kill -9 `ps -ef|grep d.bin| grep -v grep | awk '{print $2}'`

注意，生產庫上嚴禁使用，不然可能致使集羣不能正常啓動。

第三章 sysresv命令

3.1  如果一個主機上有多個oracle實例的話該如何肯定哪一個共享內存段屬於咱們該清掉的oracle實例的內存段？

答案：使用sysresv命令。sysresv是Oracle在Linux/Unix平臺提供的工具，用來查看Oracle實例使用的共享內存和信號量等信息。sysresv存放的路徑：$ORACLE_HOME/bin/sysresv。使用時須要設置LD_LIBRARY_PATH環境變量，用來告訴Oracle共享庫文件的位置。sysresv用法以下：

[oracle@rhel6lhr ~]$ sysresv -h sysresv: invalid option -- 'h' usage   : sysresv [-if] [-d ] [-l sid1 ...]           -i : Prompt before removing ipc resources for each sid           -f : Remove ipc resources silently, oevrrides -i option           -d : List ipc resources for each sid if on           -l sid1 .. : apply sysresv to each sid Default : sysresv -d on -l $ORACLE_SID Note    : ipc resources will be attempted to be deleted for a           sid only if there is no currently running instance           with that sid. [oracle@rhel6lhr ~]$ which sysresv /u01/app/oracle/product/11.2.0/dbhome_1/bin/sysresv

 

 

 

來看一下簡單使用：

oracle@sunvs-b@/oracle/oracle $ uname -a SunOS sunvs-b 5.10 Generic_139555-08 sun4u sparc SUNW,Sun-Fire-480R oracle@sunvs-b@/oracle/oracle $ ps -ef|grep pmon   oracle 26257     1   0   5月 24 ?         140:42 ora_pmon_H2   oracle 15479 14078   0 14:01:36 pts/4       0:00 grep pmon oracle 12449     1   0   8月 17 ?          17:44 ora_pmon_U2   oracle@sunvs-b@/oracle/oracle $ sysresv -l H2   IPC Resources for ORACLE_SID "H2" : Shared Memory: ID              KEY 1979711594      0x00000000 1979711595      0x00000000 1979711596      0x00000000 1979711597      0xce653c24 Semaphores: ID              KEY 16777316        0x25393874 Oracle Instance alive for sid "H2"   oracle@sunvs-b@/oracle/oracle $ ipcs -ms IPC status from as of 2011年08月29日 星期一 14時11分51秒 CST T         ID      KEY        MODE        OWNER    GROUP Shared Memory: m 1577058426   0xf5649758 --rw-r-----   oracle oinstall m 1577058425   0          --rw-r-----   oracle oinstall m 1577058424   0          --rw-r-----   oracle oinstall m 1577058423   0          --rw-r-----   oracle oinstall m 1979711605   0x4e65af   --rw-r--r--   oracle oinstall m 1979711604   0x3e65af   --rw-r--r--   oracle oinstall m 1979711603   0x1e65af   --rw-r--r--   oracle oinstall m 1979711602   0xe65af    --rw-r--r--   oracle oinstall m 1979711597   0xce653c24 --rw-r-----   oracle oinstall m 1979711596   0          --rw-r-----   oracle oinstall m 1979711595   0          --rw-r-----   oracle oinstall m 1979711594   0          --rw-r-----   oracle oinstall m 1979711511   0x31f4002  --rw-rw-rw-    cupsz cupucuse m  754974788   0xc93f     --rw-rw-rw-     hsm1 cupucuse m  754974787   0xc93e     --rw-rw-rw-     hsm1 cupucuse m  754974786   0xc93d     --rw-rw-rw-     hsm1 cupucuse m  754974785   0xc93c     --rw-rw-rw-     hsm1 cupucuse m  754974784   0xc93b     --rw-rw-rw-     hsm1 cupucuse m  754974783   0xc93a     --rw-rw-rw-     hsm1 cupucuse m  754974782   0xc939     --rw-rw-rw-     hsm1 cupucuse m  754974781   0xc938     --rw-rw-rw-     hsm1 cupucuse m  754974780   0xc937     --rw-rw-rw-     hsm1 cupucuse m  754974779   0xc936     --rw-rw-rw-     hsm1 cupucuse m  754974778   0xc935     --rw-rw-rw-     hsm1 cupucuse m  754974777   0xc934     --rw-rw-rw-     hsm1 cupucuse m  754974776   0xc933     --rw-rw-rw-     hsm1 cupucuse m  754974775   0xc932     --rw-rw-rw-     hsm1 cupucuse m  754974774   0xc930     --rw-rw-rw-     hsm1 cupucuse m  754974773   0xc92f     --rw-rw-rw-     hsm1 cupucuse m  754974772   0xc92e     --rw-rw-rw-     hsm1 cupucuse m  754974771   0xc92d     --rw-rw-rw-     hsm1 cupucuse m  754974770   0xc931     --rw-rw-rw-     hsm1 cupucuse m         45   0x741cc1a6 --rw-rw-rw-     root     root m         44   0x741cc1a5 --rw-rw-rw-     root     root m         43   0x741cc1a4 --rw-rw-rw-     root     root m         42   0x741cc1a3 --rw-rw-rw-     root     root m         41   0x741cc1a2 --rw-rw-rw-     root     root m         40   0x741cc1a1 --rw-rw-rw-     root     root m         39   0x741cc1a0 --rw-rw-rw-     root     root m         37   0x435dce60 --rw-rw-rw-     root     root m          0   0x22bb     --rw-rw----     root      dba Semaphores: s   16777324   0x25393ad4 --ra-r-----   oracle oinstall s   16777320   0x1e65af   --ra-ra-ra-   oracle oinstall s   16777319   0xe65af    --ra-ra-ra-   oracle oinstall s   16777316   0x25393874 --ra-r-----   oracle oinstall s   16777296   0          --ra-ra-ra-    cupst cupucuse s   16777294   0          --ra-ra-ra-    cupst cupucuse s   16777289   0          --ra-ra-ra-    cuput cupucuse s   16777287   0          --ra-ra-ra-    cuput cupucuse s   16777282   0          --ra-ra-ra-   cupvip cupucuse s   16777280   0          --ra-ra-ra-   cupvip cupucuse s   16777279   0          --ra-ra-ra-    cupfb cupucuse s   16777277   0          --ra-ra-ra-    cupfb cupucuse s   16777268   0          --ra-ra-ra-    cupuc cupucuse s   16777266   0          --ra-ra-ra-    cupuc cupucuse s   16777261   0          --ra-ra-ra-    cuphx cupucuse s   16777259   0          --ra-ra-ra-    cuphx cupucuse s   16777258   0          --ra-ra-ra-    cupsz cupucuse s   16777256   0          --ra-ra-ra-    cupsz cupucuse s          1   0x55064bec --ra-r--r--     root     root s          0   0x710644ac --ra-ra-ra-     root     root

 

 

 

說明一下：在安裝ORACLE產品前，須要設置系統的共享內存段的最大值和個數限制，實例在啓動後，應儘可能保證SGA在一個共享內存段上，這裏因爲我是在RAC的一個節點上進行的測試，因此實例內存被分配到4個共享內存段上。

 

IPC的清理可使用sysresv –if，若是實例正在運行，清理操做會被終止：

oracle@sunvs-b@/oracle/oracle $ sysresv -fi -l H2   IPC Resources for ORACLE_SID "H2" : Shared Memory: ID              KEY 1979711594      0x00000000 1979711595      0x00000000 1979711596      0x00000000 1979711597      0xce653c24 Semaphores: ID              KEY 16777316        0x25393874 Oracle Instance alive for sid "H2" SYSRESV-005: Warning         Instance maybe alive - aborting remove for sid "H2"

 

另外若是須要清理內存段和信號量，而sysresv發現實例是alive的，可使用ipcrm命令：

ipcrm -m ipcrm -s

 

 

3.1.1  實驗

[ZFXDESKDB2:oracle]:/oracle>ps -ef|grep ora_pmon_   oracle 12255344 21626964  0 17:43:01  pts/0  0:00 grep ora_pmon_   oracle 17629238       1  0 18:57:42     -  0:09 ora_pmon_raclhr2   oracle 20250806       1  0 18:57:42     -  0:10 ora_pmon_oraESKDB2 [ZFXDESKDB2:oracle]:/oracle>which sysresv /oracle/app/oracle/product/11.2.0/db/bin/sysresv [ZFXDESKDB2:oracle]:/oracle>ORACLE_SID=raclhr2 [ZFXDESKDB2:oracle]:/oracle>sysresv   IPC Resources for ORACLE_SID "raclhr2" : Shared Memory: ID             KEY 5242886        0xffffffff 5242883        0xffffffff 1048583        0xd92489e0 Oracle Instance alive for sid "raclhr2" [ZFXDESKDB2:oracle]:/oracle>ipcs IPC status from /dev/mem as of Wed Jun  1 17:43:47 BEIST 2016 T       ID    KEY       MODE      OWNER   GROUP Message Queues: q        0 0x9283a0d2 -Rrw-------    root  system q        1 0xffffffff -----------    root  system   Shared Memory: m  1048576  00000000 --rw-r-----    grid     dba m  1048577  00000000 --rw-r-----    grid     dba m  1048578 0x210000aa --rw-rw----    root  system m  5242883  00000000 --rw-r-----  oracle asmadmin m  1048580  00000000 --rw-r-----  oracle asmadmin m  1048581  00000000 --rw-r-----  oracle asmadmin m  5242886  00000000 --rw-r-----  oracle asmadmin m  1048583 0xd92489e0 --rw-r-----  oracle asmadmin m  1048584 0xd1a4a5d8 --rw-r-----    grid     dba m  8388617 0x3f516768 --rw-r-----  oracle asmadmin m 759169034 0x21000148 --rw-rw----  oracle     dba Semaphores: s  3145728 0x0100324a --ra-ra-r--    root  system s        1 0x620025b4 --ra-r--r--    root  system s        2 0x02001958 --ra-ra-ra-    root  system s        3 0x01001958 --ra-ra-ra-    root  system s        9 0x010024be --ra-------    root  system s  1048590 0x410000a8 --ra-ra----    root  system s  11534361 0x41000147 --ra-ra----  oracle     dba [ZFXDESKDB2:oracle]:/oracle>ipcs -m IPC status from /dev/mem as of Wed Jun  1 17:43:56 BEIST 2016 T       ID    KEY       MODE      OWNER   GROUP Shared Memory: m  1048576  00000000 --rw-r-----    grid     dba m  1048577  00000000 --rw-r-----    grid     dba m  1048578 0x210000aa --rw-rw----    root  system m  5242883  00000000 --rw-r-----  oracle asmadmin m  1048580  00000000 --rw-r-----  oracle asmadmin m  1048581  00000000 --rw-r-----  oracle asmadmin m  5242886  00000000 --rw-r-----  oracle asmadmin m  1048583 0xd92489e0 --rw-r-----  oracle asmadmin m  1048584 0xd1a4a5d8 --rw-r-----    grid     dba m  8388617 0x3f516768 --rw-r-----  oracle asmadmin m 759169034 0x21000148 --rw-rw----  oracle     dba [ZFXDESKDB2:oracle]:/oracle>ipcrm -m 5242886 [ZFXDESKDB2:oracle]:/oracle>ipcrm -m 5242883 [ZFXDESKDB2:oracle]:/oracle>ipcrm -m 1048583 [ZFXDESKDB2:oracle]:/oracle>sysresv   IPC Resources for ORACLE_SID "raclhr2" : Shared Memory ID             KEY No shared memory segments used Oracle Instance not alive for sid "raclhr2" Oracle Instance not alive for sid "raclhr2" [ZFXDESKDB2:oracle]:/oracle>ps -ef|grep ora_pmon_   oracle 17629238       1  0 18:57:42     -  0:09 ora_pmon_raclhr2   oracle 20250806       1  0 18:57:42     -  0:10 ora_pmon_oraESKDB2   oracle 23330844 21626964  0 17:44:46  pts/0  0:00 grep ora_pmon_ [ZFXDESKDB2:oracle]:/oracle>sqlplus / as sysdba   SQL*Plus: Release 11.2.0.4.0 Production on Wed Jun 1 17:44:52 2016   Copyright (c) 1982, 2013, Oracle.  All rights reserved.   Connected to an idle instance.   SYS@raclhr2> shutdown abort ORACLE instance shut down. SYS@raclhr2> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options

 

 

 

第四章 Oracle內核參數

查看：more /proc/sys/kernel/shmmax

臨時生效：echo 3145728 > /proc/sys/kernel/shmmax

永久生效，修改文件：/etc/sysctl.conf，並使修改參數當即生效：/sbin/sysctl -p

重要的幾個參數以下所示：

kernel.shmall = 2097152 kernel.shmmax = 1054472192 kernel.shmmni = 4096 kernel.sem = 250 32000 100 128

其含義分別以下所示：

（一）kernel.shmall = 2097152 # kernel.shmall參數是控制共享內存頁數。Linux 共享內存頁大小爲4KB，共享內存段的大小都是共享內存頁大小的整數倍。若是一個共享內存段的最大大小是16G，那麼須要共享內存頁數是 16GB/4KB = 16777216KB/4KB = 4194304（頁），也就是64Bit系統下16GB物理內存，設置kernel.shmall = 4194304才符合要求（幾乎是原來設置2097152的兩倍）。簡言之，該參數的值始終應該至少爲： ceil(SHMMAX/PAGE_SIZE)。這個值過小有可能致使數據庫啓動報錯（ORA-27102: out of memory）。

（二）kernel.shmmax = 1054472192  #定義一個內存段最大能夠分配的內存空間，單位爲字節。若是定義過小，那麼會致使啓動實例失敗，或者SGA就會被分配到多個共享內存段。那麼內存中的指針鏈接會給系統帶來必定的開銷，從而下降系統性能。這個值的設置應該大於SGA_MAX_TARGET或MEMORY_MAX_TARGET的值，最大值能夠設置成大於或等於實際的物理內存。若是kernel.shmmax爲100M，sga_max_size爲500M，那麼啓動Oracle實例至少會分配5個共享內存段；若是設置kernel.shmmax爲2G，sga_max_size爲500M，那麼啓動Oracle實例只須要分配1個共享內存段。

（三）kernel.shmmni = 4096 #設置系統級最大共享內存段數量，該參數的默認值是4096。這一數值已經足夠，一般不須要更改。。

（四）kernel.sem = 250 32000 100 128 #信號燈的相關配置，信號燈semaphores是進程或線程間訪問共享內存時提供同步的計數器。能夠經過命令「cat /proc/sys/kernel/sem」來查看當前信號燈的參數配置，以下所示：

[root@edsir4p1 ~]# cat /proc/sys/kernel/sem 250     32000   100     128

其4個值的含義分別以下：

① 250表示SEMMSL，設置每一個信號燈組中信號燈最大數量，推薦的最小值是250。對於系統中存在大量併發鏈接的系統，推薦將這個值設置爲PROCESSES初始化參數加10。

② 32000表示SEMMNS，設置系統中信號燈的最大數量。操做系統在分配信號燈時不會超過LEAST(SEMMNS,SEMMSL*SEMMNI)。事實上，若是SEMMNS的值超過了SEMMSL*SEMMNI是非法的，所以推薦SEMMNS的值就設置爲SEMMSL*SEMMNI。Oracle推薦SEMMNS的設置不小於32000。

③ 100表示SEMOPM，設置每次系統調用能夠同時執行的最大信號燈操做的數量。因爲一個信號燈組最多擁有SEMMSL個信號燈，所以有推薦將SEMOPM設置爲SEMMSL的值。Oracle驗證的10.2和11.1的SEMOPM的配置爲100。

④ 128表示SEMMNI，設置系統中信號燈組的最大數量。Oracle10g和11g的推薦值爲142。

 

4.1  kernel.shmmax參數

4.1.1  實驗1

下面臨時設置kernel.shmmax爲3M，會致使Oracle不能啓動，設置sqlplus不能進入：

[root@edsir4p1 ~]# echo 3145728 > /proc/sys/kernel/shmmax  <<<====  臨時設置3M [oracle@edsir4p1- ~]$ more /proc/sys/kernel/shmmax <<<==== 查看是否生效 3145728 [root@edsir4p1 ~]# /sbin/sysctl -a | grep shm vm.hugetlb_shm_group = 0 kernel.shmmni = 4096 kernel.shmall = 2097152 kernel.shmmax = 3145728 [root@edsir4p1 ~]# more /etc/sysctl.conf | grep kernel.shm kernel.shmall = 2097152 kernel.shmmax = 2147483648 kernel.shmmni = 4096 [root@edsir4p1 ~]# su - oracle [oracle@edsir4p1- ~]$ . PROD1_env [oracle@edsir4p1-PROD1 ~]$ sqlplus / as sysdba   SQL*Plus: Release 11.2.0.1.0 Production on Tue Nov 14 10:09:08 2017   Copyright (c) 1982, 2009, Oracle.  All rights reserved.   ERROR: ORA-12547: TNS:lost contact     Enter user-name:     [oracle@edsir4p1-PROD1 ~]$ oerr ora 12547 12547, 00000, "TNS:lost contact" // *Cause: Partner has unexpectedly gone away, usually during process // startup. // *Action: Investigate partner application for abnormal termination. On an // Interchange, this can happen if the machine is overloaded.

 

告警日誌：

Linux Error: 32: Broken pipe Tue Nov 14 10:00:38 2017 14-NOV-2017 10:00:38 * (CONNECT_DATA=(SID=PROD1)(CID=(PROGRAM=emagent)(HOST=edsir4p1.us.oracle.com)(USER=oracle))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.190.104.111)(PORT=26305)) * establish * PROD1 * 12518 TNS-12518: TNS:listener could not hand off client connection TNS-12547: TNS:lost contact   TNS-12560: TNS:protocol adapter error    TNS-00517: Lost contact     Linux Error: 32: Broken pipe

 

 

 

或啓動報錯：

SYS@PROD1> startup ORA-00443: background process "PMON" did not start SYS@PROD1> startup ORA-12547: TNS:lost contact SYS@PROD1>

 

有關「TNS-12518: TNS:listener could not hand off client connection」的更多內容請參考：

【故障|監聽】TNS-1251八、TNS-00517和 Linux Error：32：Broken pipe：http://blog.itpub.net/26736162/viewspace-2135468/

 

 

4.1.2  實驗2

下面臨時設置kernel.shmmax爲100M，sga_max_size爲500M，則至少須要5個共享內存段，查看臨時段的個數：

[root@edsir4p1 ~]# echo 104857600 > /proc/sys/kernel/shmmax [root@edsir4p1 ~]# more /proc/sys/kernel/shmmax 104857600 [root@edsir4p1 ~]# su - oracle [oracle@edsir4p1- ~]$ . PROD1_env [oracle@edsir4p1-PROD1 ~]$ sysresv   IPC Resources for ORACLE_SID "PROD1" : Shared Memory ID              KEY No shared memory segments used<<<==== 無實例的共享內存段 Semaphores: ID              KEY 98304           0xa3dda878 Oracle Instance not alive for sid "PROD1" [oracle@edsir4p1-PROD1 ~]$ ipcs   ------ Shared Memory Segments -------- key        shmid      owner      perms      bytes      nattch     status      0x00000000 32768      vncuser   644        790528     2          dest         0x00000000 65537      vncuser   644        790528     2          dest         0x00000000 98306      vncuser   644        790528     2          dest           ------ Semaphore Arrays -------- key        semid      owner      perms      nsems     0xa3dda878 98304      oracle    660        154         ------ Message Queues -------- key        msqid      owner      perms      used-bytes   messages    [oracle@edsir4p1-PROD1 ~]$ sqlplus / as sysdba   SQL*Plus: Release 11.2.0.1.0 Production on Tue Nov 14 10:29:07 2017   Copyright (c) 1982, 2009, Oracle.  All rights reserved.   Connected to an idle instance. SYS@PROD1> startup     ORACLE instance started.   Total System Global Area  313860096 bytes Fixed Size                  1336232 bytes Variable Size             251661400 bytes Database Buffers           54525952 bytes Redo Buffers                6336512 bytes Database mounted. Database opened. SYS@PROD1>  show parameter sga   NAME                                 TYPE        VALUE ------------------------------------ ----------- ------------------------------ lock_sga                             boolean     FALSE pre_page_sga                         boolean     FALSE sga_max_size                         big integer 500M sga_target                           big integer 300M SYS@PROD1> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options [oracle@edsir4p1-PROD1 dbs]$ [oracle@edsir4p1-PROD1 ~]$ sysresv   IPC Resources for ORACLE_SID "PROD1" : Shared Memory: ID              KEY 1245194         0x00000000 1277963         0x00000000 1310732         0x00000000 1343501         0x00000000 1376270         0x00000000 1409039         0x90c3be20 Semaphores: ID              KEY 917504          0xa3dda878 Oracle Instance alive for sid "PROD1" [oracle@edsir4p1-PROD1 ~]$ ipcs   ------ Shared Memory Segments -------- key        shmid      owner      perms      bytes      nattch     status      0x00000000 32768      vncuser   644        790528     2          dest         0x00000000 65537      vncuser   644        790528     2          dest         0x00000000 98306      vncuser   644        790528     2          dest         0x00000000 1245194    oracle    660        8388608    30                      <<<==== 該共享內存段爲8M 0x00000000 1277963    oracle    660        104857600  30                      0x00000000 1310732    oracle    660        104857600  30                      0x00000000 1343501    oracle    660        104857600  30                      0x00000000 1376270    oracle    660        104857600  30                      0x90c3be20 1409039    oracle    660        100663296  30                      <<<==== 每一個共享內存段爲100M   ------ Semaphore Arrays -------- key        semid      owner      perms      nsems     0xa3dda878 917504     oracle    660        154         ------ Message Queues -------- key        msqid      owner      perms      used-bytes   messages

 

下面臨時設置kernel.shmmax爲2G，sga_max_size爲500M，則只須要1個共享內存段，查看臨時段的個數：

[oracle@edsir4p1-PROD1 ~]$ ss   SQL*Plus: Release 11.2.0.1.0 Production on Tue Nov 14 10:49:21 2017   Copyright (c) 1982, 2009, Oracle.  All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options   SYS@PROD1> select 2*1024*1024*1024 from dual;   2*1024*1024*1024 ----------------       2147483648   SYS@PROD1> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options [oracle@edsir4p1-PROD1 ~]$ sudo echo 2147483648 > /proc/sys/kernel/shmmax -bash: /proc/sys/kernel/shmmax: Permission denied [oracle@edsir4p1-PROD1 ~]$ su - root Password: [root@edsir4p1 ~]# echo 2147483648 > /proc/sys/kernel/shmmax [root@edsir4p1 ~]# exit logout [oracle@edsir4p1-PROD1 ~]$ ipcs -m   ------ Shared Memory Segments -------- key        shmid      owner      perms      bytes      nattch     status      0x00000000 32768      vncuser   644        790528     2          dest         0x00000000 65537      vncuser   644        790528     2          dest         0x00000000 98306      vncuser   644        790528     2          dest         0x00000000 1245194    oracle    660        8388608    30                      0x00000000 1277963    oracle    660        104857600  30                      0x00000000 1310732    oracle    660        104857600  30                      0x00000000 1343501    oracle    660        104857600  30                      0x00000000 1376270    oracle    660        104857600  30                      0x90c3be20 1409039    oracle    660        100663296  30                      <<<==== 須要重啓數據庫，從新分配共享內存段   [oracle@edsir4p1-PROD1 ~]$ ss   SQL*Plus: Release 11.2.0.1.0 Production on Tue Nov 14 10:50:23 2017   Copyright (c) 1982, 2009, Oracle.  All rights reserved.     Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options   SYS@PROD1> startup force ORACLE instance started.   Total System Global Area  523108352 bytes Fixed Size                  1337632 bytes Variable Size             343934688 bytes Database Buffers          171966464 bytes Redo Buffers                5869568 bytes Database mounted. Database opened. SYS@PROD1> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options [oracle@edsir4p1-PROD1 ~]$ sysresv   IPC Resources for ORACLE_SID "PROD1" : Shared Memory: ID              KEY 1474570         0x90c3be20 Semaphores: ID              KEY 1081344         0xa3dda878 Oracle Instance alive for sid "PROD1" [oracle@edsir4p1-PROD1 ~]$ ipcs   ------ Shared Memory Segments -------- key        shmid      owner      perms      bytes      nattch     status      0x00000000 32768      vncuser   644        790528     2          dest         0x00000000 65537      vncuser   644        790528     2          dest         0x00000000 98306      vncuser   644        790528     2          dest         0x90c3be20 1474570    oracle    660        528482304  31                      <<<====共享內存段爲500M   ------ Semaphore Arrays -------- key        semid      owner      perms      nsems     0xa3dda878 1081344    oracle    660        154         ------ Message Queues -------- key        msqid      owner      perms      used-bytes   messages

 

4.2  kernel.shmall

該參數設置太小，有可能致使數據庫啓動報錯。不少人調整系統內核參數的時候只關注SHMMAX參數，而忽略了SHMALL參數的設置。

[root@edsir4p1 ~]# echo 10 > /proc/sys/kernel/shmall [root@edsir4p1 ~]# [root@edsir4p1 ~]# [root@edsir4p1 ~]# [root@edsir4p1 ~]# [root@edsir4p1 ~]# more /proc/sys/kernel/shmall 10 [oracle@edsir4p1-PROD1 ~]$ ss   SQL*Plus: Release 11.2.0.1.0 Production on Tue Nov 14 11:13:53 2017   Copyright (c) 1982, 2009, Oracle.  All rights reserved.   Connected to an idle instance.   SYS@PROD1> startup ORA-27102: out of memory Linux Error: 28: No space left on device SYS@PROD1>

 

 

 

4.3  其它博客內容

4.3.1  原文地址：ORACLE內核參數 做者：it_newbalance

服務器內存爲4G的狀況下 

修改/etc/sysctl.conf文件 (ROOT帳戶) 

 

kernel.shmmax = 2147483648 

//公式:2G*1024*1024*1024=2147483648(字節) 

//表示最大共享內存，若是小的話能夠按實際狀況而定，通常爲物理內存的一半（單位:字節） 

 

kernel.shmmni=4096 

//表示最小共享內存固定4096KB（因爲32位操做系統默認一頁爲4K） 

 

kernel.shmall=1048576 

//公式:4G*1024*1024/4K = 1048576(頁) 

//表示全部內存大小（單位：頁） 

 

kernel.sem=250 32000 100 128 

//4個參數依次是SEMMSL：每一個用戶擁有信號量最大數，SEMMNS：系統信號量最大數，SEMOPM：每次semopm系統調用操做數，SEMMNI：系統辛苦量集數最大數。這4個參數爲固定內容大小 

 

fs.file-max=65536 

//file-max固定大小65536 

 

net.ipv4.ip_local_port_range=1024 65000 

//ip_local_port_range表示端口的範圍，爲指定的內容 

 

以上步驟作完執行 /sbin/sysctl -p 使內核生效 

 

驗證參數（root帳戶執行）： 

#/sbin/sysctl -a | grep shm 

#/sbin/sysctl -a | grep sem 

#/sbin/sysctl -a | grep file-max 

#/sbin/sysctl -a | grep ip_local_port_range

 

最近解決了一些這方面的問題，並在網絡上查詢了一些相關資料終於發現一個比較全面解釋這類問題的官方文檔。原本打算當一次活雷鋒全文翻譯的，後來考慮本身英文通常，而且對於其中一些OS相關的知識也沒有深刻了解。就保留英文你們本身去領會其中的要領，本身簡單總結了一下解決這類問題的關鍵點並整理一下英文原文。這個文檔是oracle官方技術支持網站Metalink的資料，裏面引用了一些其它的文檔例如NOTE:115235.1 。

    對於unix操做系統中Semaphores問題只是針對和oracle相關問題做一些解釋。對於信號量和共享內存段參數在不一樣的系統中可能有不一樣的參數對應，具體你去查詢對應的OS文檔。

在解決這類問題的時候我發現大部分問題都是由於在安裝oracle時沒有仔細閱讀針對指定OS的安裝說明形成安裝實例失敗，通常oracle的官方文檔都詳細說明在對應操做系統上如何設置這些內核參數。還有就是由於其餘緣由OS管理人員調整了參數，可是沒有通知DBA，一旦oracle崩潰再次從新啓動的時候就可能由於新的內核參數不合適而沒法啓動。 若是是oracle意外停機以後從新啓動不成功，並出現相似ora-27123的錯誤那麼必定要詢問是否有其餘人修改過內核參數，有時候你沒有修改並不表明其餘人沒有修改喲，我遇到過很多這樣的狀況！

 

 

 

1、與oracle相關的信號量和共享內存段參數

   通常unix系統中和信號量相關的是三個參數SEMMNI SEMMSL SEMMNS。他們相互關聯決定系統能夠分配的信號量。Oracle使用信號量完成內部進程之間的通訊。

   關於共享內存段使用shmmx參數進行整體控制。它指定了系統能夠分配的共享內存段最大大小，實際並無分配那麼多隻是給出一個可使用的最大限制。

   對於類核參數的修改必需要從新啓動系統以後纔會生效。

2、出現信號量和共享內存段相關問題的狀況

  oracle只有在startup nomount的時候纔會請求os的這些資源，用於創建SGA和啓動後臺進程。

   有些狀況下由於oracle崩潰以後os沒有清除oracle分配的SGA，也可能形成共享內存段不足，須要人工清除。

3、如何解決相關的問題

   你能夠簡單的修改init參數減小oracle對共享內存段和信號量的需求。

   對於控制信號量的三個參數SEMMNI SEMMSL SEMMNS 。最終可使用的信號量由下面公式 提取 (semmsl * semmni) 或者 semmns中最小的值。

    例如在linux下. 進入目錄/proc/sys/kernel；用cat命令或more命令查看semaphore當前參數的值： 

cat sem 

命令運行後將會出現以下的結果： 

250 32000 32 128 

其中, 250 是參數SEMMSL的值,32000是參數SEMMNS的值, 32是參數SEMOPM的值，而128則是參數SEMMNI的值。250*128=32000

對於oracle7須要信號量的設置等於init中processes的設置。對於8i 9i須要等於processes*2。

對於信號量參數的設定必定要當心，由於不正確的設置可能會讓系統使用默認值。這個值通常比oracle系統要求的低。在HP unix上遇到過這樣的問題，當時在參數配置的時候指定兩個不一樣的sem-mni形成系統使用默認的設置。

對於共享內存段，系統的設置至少要等於SGA的大小。

 

Semaphores and Shared Memory

 

BULLETIN Status: PUBLISHED Content Type: TEXT/PLAIN Creation Date: 05-AUG-2001

Last Revision Date: 05-AUG-2002

PURPOSE-------

To provide an overview of shared memory and semaphores, answer common questions related to these OS resources and provide links to more detailed information.

SCOPE & APPLICATION

-------------------

This document is intended for anyone who is responsible for creating or

administering an Oracle Database. It is intended to compliment the semaphore and

shared memory information already provided in the Oracle Installation Guides.

 

關於信號量和共享內存段的背景知識

----------------------------------------------------------------------------------

Semaphores and shared memory are two very distinct sets of Operating System

resources. Semaphores are a system resource that Oracle utilizes for interprocess

communication and they occupy a relatively small memory space, while shared memory is utilized to contain the SGA and can garner a large portion of physical memory.

How many of these resources are available and how they are allocated is controlled

by the configuration of the operating system kernel('kernel' referring to the

centralized core components of the underlying operating system).

 

There are three OS kernel parameters that work together to limit semaphore

allocation and one OS kernel paramater that dictates the maximum size of a shared

memory segment.

 

Operating System kernel parameters generally cannot be tuned on the fly. If they

are modified, the changes will not take place until the system is rebooted.

 

Remember also that the kernel parameters related to semaphores and shared memory represent 'high-water' marks. Meaning that the OS will not automatically

allocate a given amount, but will allow up to that given amount to be available

upon request.

 

 

何時信號量和共享內存段問題最有可能發生

----------------------------------------------------------------------------------

 

Both semaphore or shared memory errors appear primarily at instance startup (The

'startup nomount' stage specifically). This is the only time that Oracle tries to

acquire semaphores and shared memory for the instance. Errors related to

semaphores or shared memory rarely appear during normal database operations.

 

The most common circumstance in which these errors occur is during the creation of

a new database.

Sometimes when an Oracle instance crashes, however, it's shared memory segments may not be released by the OS. This limits the overall amount of shared memory available for the instance to start up again. In this case, you will need to remove those segments manually.

 

如何解決信號量和共享內存段問題：

How to resolve semaphore and shared memory errors:

----------------------------------------------------------------------------------

In addressing both semaphore and shared memory errors at instance startup, there

are two separate areas that should be considered for reconfiguration.

 

The first and most simple fix is to modify the init.ora to reduce the number of semaphores or the amount of shared memory Oracle will try to grab at instance startup.

 

If your situation requires that you not reduce the appropriate init.ora

parameters, you will have to modify the operating system kernel to allow the OS to

provide more semaphores or allow larger shared memory segments.

 

SEMAPHORES

================================================== ================================

IMPORTANT NOTE: ORACLE DOES NOT UTILIZE SEMAPHORES ON AIX OR DIGITAL/TRU64.

 

與信號量相關的的ORA錯誤

What kind of ORA errors are related to semaphores?

----------------------------------------------------------------------------------

'Out of memory' type errors are seldom related to semaphores. Error messages which reference a 'SEMM*****' function are related to semaphores.

 

IMPORTANT NOTE: THESE ERRORS ONLY OCCUR AT INSTANCE STARTUP.

 

ORA-7250 "spcre: semget error, unable to get first semaphore set."

ORA-7279 "spcre: semget error, unable to get first semaphore set."

ORA-7251 "spcre:semget error, could not allocate any semaphores."

ORA-7252 "spcre: semget error, could not allocate any semaphores."

ORA-7339 "spcre: maximum number of semaphore sets exceeded."

 

[NOTE:115235.1] Resolving ORA-7279 or ORA-27146 errors when starting instance

VERY COMMON On Oracle8i and Oracle9i:

ORA-3113 "end-of-file on communication channel" at instance startup.

ORA-27146 "post/wait initialization failed"

 

[NOTE:115235.1] Resolving ORA-7279 or ORA-27146 errors when starting instance

 

If you want a very specific explanation of causes for the above errors, refer to:

[NOTE:15566.1] TECH Unix Semaphores and Shared Memory Explained

 

However, while their exact cause varies, all these error messages indicate that

your init.ora is configured to grab more semaphores than the OS has available.

 

If you configure your OS as indicated in the following sections, you will not get any of the errors indicated above.

 

成功配置信號量的步驟

The Basic Steps to Semaphore Success:

----------------------------------------------------------------------------------

1. Understand The Basic Concept Behind Semaphores

2. Understand How Many Semaphores Your Oracle Instance(s) Will Attempt to Grab

From The Operating System.

3. Configure Your OS Kernel To Accomodate all Your Oracle Instance(s) And also

Allow For Future Growth.

 

[STEP 1] How are semaphores released by the OS for use by an application?

----------------------------------------------------------------------------------

There are 3 OS kernel parameters that work together to limit semaphore allocation.

When an application requests semaphores, the OS releases them in 'sets'.

Illustrated here as 2 sets: +---+ +---+

| | | |

| | | |

+---+ +---+

 

Controlled by SEMMNI -->OS limit on the Number of Identifiers or sets.

Each set contains a tunable number of individual semaphores.

Illustrated here as 2 semaphores per semaphore set: +---+ +---+

| S | | S | S | | S |

+---+ +---+

 

Controlled by SEMMSL -->The number of semaphores in an identifier or

set.(Semaphore List)

 

Ultimately however, the OS can limit the total number of semaphores available

from the OS. Controlled by:

SEMMNS --> The total Number of Semaphores allowed system wide.

 

For instance: Let's say SEMMNI = 100000000 and SEMMSL= 100000000 while SEMMNS=10

Even though SEMMNI is 100000000 and SEMMSL is 100000000, the max # of semaphores available on your system will only be 10, because SEMMNS is set to 10.

 

Inversely: Let's say SEMMNI = 10 and SEMMSL = 10 while SEMMNS=

100000000000000000000000000 Because SEMMNI is 10 and SEMMSL is 10, the max # of semaphores avail on your system will only be 100 or (10 X 10), despite what SEMMNS is set too.

 

THIS NOTION CAN BE SUMMARIZED BY THE FOLLOWING STATEMENT:

 

The max # of semaphores that can be allocated on a system will be the lesser of:

(semmsl * semmni) or semmns.

On HP: semmsl is hardcoded to 500. [NOTE:74367.1] HP-UX SEMMSL Kernel Parameter

SEMMNI, SEMMSL & SEMMNS are the basic names for OS semaphore kernel parameters,the full name may vary depending on your OS. Consult your OS specific Oracle Install guide.

 

[NOTE:116638.1] Understanding and Obtaining Oracle Documentation)

 

[STEP 2] How many semaphores will my Oracle instance(s) require?

----------------------------------------------------------------------------------

With Oracle7: The number of semaphores required by an instance is equal to the

setting the 'processes' parameter in the init.ora for the instance.

 

With Oracle8, Oracle8i and Oracle9i: The number of semaphores required by an

instance is equal to 2 times the setting of the 'processes' parameter in the init.ora for the instance. Keep in mind, however, that Oracle only momentarily grabs 2 X 'processes' then releases half at instance startup. This measure was apparently introduced to ensure Oracle could not exhaust a system of semaphores.

 

Oracle may also grab a couple of additional semaphores per instance for internal

use.

[STEP 3] Configure your OS kernel to accomodate all your Oracle instances.

----------------------------------------------------------------------------------

 

There seems to be some confusion of how to deal with lack of semaphore errors. The

popular theory being that if Oracle cannot find enough semaphores on a system,

increase semmns. This is not always the case, as illustrated in [STEP 1].

Once you have determined your semaphore requirements for Oracle and compensated for future growth, contact your System Administrator or OS vendor for assistance in modifying the OS kernel.

 

What should I set 'semmni', 'semmsl' & 'semmns' to?

----------------------------------------------------------------------------------

Oracle Support typically does not recommend specific values for semaphore kernel

parameters. Instead, use the information provided in this document to set the parameters to values that are appropriate for your operating environment.

 

For more info please look at the following note : [NOTE:15654.1] TECH: Calculating

Oracle's SEMAPHORE Requirements

 

快速解決信號量問題

Quick fix for resolving lack of semaphore errors:

----------------------------------------------------------------------------------

Reduce the number of semaphores Oracle requires from the OS.

 

The first and most simple fix is to modify the init.ora to reduce the

number of semaphores or the amount of shared memory Oracle will try to grab at

instance startup.

Keep in mind, with Oracle8, we grab 2 X 'processes' then release half. This measure

was apparently introduced to ensure Oracle could not exhaust a system of semaphores.

如何查找OS配置的信號量

How can I find out how my OS kernel is configured for semaphores?

----------------------------------------------------------------------------------

 

The files that are used to tune kernel parameters varies depending on your

Operating System. Consult your system administrator or OS vendor, because viewing the system file may not show accurate information about the runtime values.

However, an important point to remember is that if a typographical error is made

while editing these files, the OS will defer to a default value which is usually to low to accomodate Oracle. So it's a good idea to check runtime values with utilities like '/etc/sysdef'.

 

 

I've tuned my OS kernel parameters, but I am still having semaphore problems....

----------------------------------------------------------------------------------

常見問題！！

This may mean that you made a typographical error or did not rebuild your

Operating System kernel correctly(if a typographical error is made while editing these files, the OS will defer to a default value which is usually to low to accomodate Oracle).

 

On Solaris, check current OS kernel values with this command:

> /etc/sysdef|grep -i semm

If these values do not reflect what you put in your 'system' file, you likely made a typographically error.

 

On HP, be sure the OS kernel was rebuilt correctly and that the OS was booted off the correct file. Contact your System Administrator or HP for more information.

在Linux系統上

進入目錄/proc/sys/kernel；用cat命令或more命令查看semaphore當前參數的值： 

cat sem 

命令運行後將會出現以下的結果： 

250 32000 32 128 

其中, 250 是參數SEMMSL的值,32000是參數SEMMNS的值, 32是參數SEMOPM的值，而128則是參數SEMMNI的值。250*128=32000

 

如何得到當前正在使用的信號量

How can I determine how many semaphores are currently being utilized?

----------------------------------------------------------------------------------

On most Unix systems, current semaphore allocation can be displayed with the OS

command 'ipcs -s'. 

% ipcs -s

While good to know, this command is seldom used as part of troubleshooting semaphore errors.

 

 

SHARED MEMORY

==================================================

OS如何分配共享內存段

How is shared memory allocated by the OS?

----------------------------------------------------------------------------------

 

This process varies slightly depending on Unix platform, but the basic premise is this:

 

An application requests a given amount of contiguous shared memory from the OS. The OS dictates how large of a shared memory segment it will allow with the kernel

parameter SHMMAX(Shared Memory Maximum). If the amount of shared memory requested by the application is greater than SHMMAX, the OS may be granted the shared memory in multiple segments. Ideally, however, you want the amount requested by the application to be less than SHMMAX so that the application's request can be fulfilled with one shared memory segment.

 

SHMMAX和SGA的關係

How does SHMMAX relate to my SGA?

----------------------------------------------------------------------------------

Since the SGA is comprised of shared memory, SHMMAX can potentially limit how large your SGA can be and/or prevent your instance from starting.

 

What limits the size of my SGA?

----------------------------------------------------------------------------------

 

In no particular order.

5. The amount of Physical Memory and Swap space available on your system.

6. The kernel paramater SHMMAX.

7. Other OS specific limitations on shared memory.

 

Memory SHMMAX OS Limits +----------+ +----------+ +----------+

| | | | | | +------+

| | | | | | | S |

| | | | | | > | G |

| | | | | | | A |

| | | | | | +------+

+----------+ +----------+ +----------+

 

Some OS specific limitations are discussed in the following documents:

 

"Oracle Administrator's Reference" available on the Oracle Install CD

 

Additionallly:

 

HP-UX: [NOTE:77310.1] HP-UX Large SGA support for HP, Memory Windows

[NOTE:69119.1] HP-UX SGA Sizing Issues on HP-UX 

Solaris: [NOTE:61896.1] SOLARIS: SGA size, sgabeg attach address and Sun

與共享內存當相關的錯誤

What kind of ORA errors are related to shared memory?

----------------------------------------------------------------------------------

 

Error Messages referencing a 'SHMM****' function are related to shared memory.

 

ORA-7306, ORA-7336, ORA-7329, ORA-7307, ORA-7337, ORA-7320, ORA-7329, ORA-7334

 

VERY COMMON IN 8i: ORA-27100 "shared memory realm already exists" ORA-27102 "out of memory"

ORA-27125 "unable to create shared memory segment" and/or "linux 43 identifier removed"

ORA-27123 "unable to attach to shared memory segment"

 

[NOTE:115753.1] UNIX Resolving the ORA-27123 error

 [NOTE:1028623.6] SUN SOLARIS: HOW TO RELOCATE THE SGA

如何設置SHMMAX

What should I set 'shmmax' to?

----------------------------------------------------------------------------------

 

On some Unix platforms, the Install Guide recommends specific values. Previous

versions of the Install Guide recommended setting SHMMAX to .5 *(physical memory present in machine). Most recently it's been suggested SHMMAX be set to 4294967295 (4GB). This may not seem appropriate, particularly if the system has considerably less physical memory available, but it does prevent you from having to modify your system kernel everytime a new instance is created or additional physical memory is added to the system. Remember that SHMMAX is a high water mark, meaning that the OS will attempt to allow up to that amount for an application.

解決缺乏共享內存段的問題

Quick fix for resolving lack of shared memory errors:

-----------------------------------------------------------------------------------

 

NOTE: If you have never configured your OS kernel for shared memory, you cannot employ this 'Quick Fix'. You will have to first configure the OS kernel. The amount of shared memory Oracle requests is roughly equal to the size of the SGA. The first and most simple fix is to modify the init.ora to reduce the amount of shared memory Oracle will try to grab at instance startup.

 

This document lists the init.ora parameters that contribute to the size

of the SGA:

 

[NOTE:1008866.6] HOW TO DETERMINE SGA SIZE (8.0, 8i, 7.x)

 

oracle崩潰以後從新啓動失敗的問題

My instance crashed. When I try to restart it, I receive errors related to shared

memory. What should I do?

-----------------------------------------------------------------------------------

This may indicate that the shared memory segment associated with the SGA of the crashed instance is still in memory. In this case it may be appropriate to manually remove the segment using OS commands.

 

THIS PROCESS SHOULD NOT BE ATTEMPTED UNLESS YOU FULLY UNDERSTAND THE CONCEPTS BEHIND IT!!!

 

The basic steps are:

1. Identify the shared memory segment that is 'stuck' in memory.

2. Remove the 'stuck' shared memory segment using the OS command 'ipcrm'.

 

[NOTE:68281.1] DETERMINING WHICH INSTANCE OWNS WHICH SHARED MEMORY & SEMAPHORE SEGMENTS

[NOTE:69642.1] also describes this process - Step 9.

[NOTE:123322.1] SYSRESV UTILITY: This note describes the new 8i 'sysresv' utility that can be used on Solaris to associate a given ORACLE_SID with it's shared memory segment(s). .

 

4.3.2  Oracle 性能優化以內核的shmall 和shmmax 參數

1. 內核的 shmall 和 shmmax 參數

 

SHMMAX= 配置了最大的內存segment的大小 ——>這個設置的比SGA_MAX_SIZE大比較好。

 

SHMMAX參數：Linux進程能夠分配的單獨共享內存段的最大值。通常設置爲內存總大小的一半。這個值的設置應該大於SGA_MAX_TARGET或MEMORY_MAX_TARGET的值，所以對於安裝Oracle數據庫的系統，shmmax的值應該比內存的二分之一大一些。

SHMMIN= 最小的內存segment的大小 。

 

SHMMNI= 整個系統的內存segment的總個數 。設置系統級最大共享內存段數量。Oracle10g推薦最小值爲4096，能夠適當比4096增長一些。

 

SHMSEG= 每一個進程可使用的內存segment的最大個數

 

shmall=是所有容許使用的共享內存大小，shmmax 是單個段容許使用的大小。這兩個能夠設置爲內存的 90%。例如 16G 內存，16*1024*1024*1024*90% = 15461882265，shmall 的大小爲 15461882265/4k(getconf PAGESIZE可獲得) = 3774873。

 

shmall設置共享內存總頁數。這個值過小有可能致使數據庫啓動報錯。不少人調整系統內核參數的時候只關注SHMMAX參數，而忽略了SHMALL參數的設置。

－

 

2.配置信號燈（ semphore ）的參數

 

信號燈semaphores是進程或線程間訪問共享內存時提供同步的計數器。

SEMMSL= 設置每一個信號燈組中信號燈最大數量，推薦的最小值是250。對於系統中存在大量併發鏈接的系統，推薦將這個值設置爲PROCESSES初始化參數加10。

 

SEMMNI= 設置系統中信號燈組的最大數量。Oracle10g和11g的推薦值爲142。

 

SEMMNS=設置系統中信號燈的最大數量。操做系統在分配信號燈時不會超過LEAST(SEMMNS,SEMMSL*SEMMNI)。事實上，若是SEMMNS的值超過了SEMMSL*SEMMNI是非法的，所以推薦SEMMNS的值就設置爲SEMMSL*SEMMNI。Oracle推薦SEMMNS的設置不小於32000，假如數據庫的PROCESSES參數設置爲600，則SEMMNS的設置應爲：

 

SQL> select (600+10)*142 from dual;

 

(600+10)*142

------------

      86620

1

2

3

4

5

SEMOPM參數：設置每次系統調用能夠同時執行的最大信號燈操做的數量。因爲一個信號燈組最多擁有SEMMSL個信號燈，所以有推薦將SEMOPM設置爲SEMMSL的值。Oracle驗證的10.2和11.1的SEMOPM的配置爲100。

 

經過下面的命令能夠檢查信號燈相關配置：

 

# cat /proc/sys/kernel/sem

250 32000 100 128

1

2

對應的4個值從左到右分別爲SEMMSL、SEMMNS、SEMOPM和SEMMNI

 

－

 

3.修改 /etc/sysctl.conf

 

kernel.shmmax=15461882265

kernel.shmall=3774873

kernel.msgmax=65535

kernel.msgmnb=65535

 

執行 sudo sysctl -p

 

可使用 ipcs -l 看結果,ipcs -u 能夠看到實際使用的狀況

 

-------------------------------------------------------------------------

---

---

About Me

............................................................................................................................................. ● 本文做者：小麥苗，部份內容整理自網絡，如有侵權請聯繫小麥苗刪除 ● 本文在itpub（http://blog.itpub.net/26736162/abstract/1/）、博客園（http://www.cnblogs.com/lhrbest）和我的微信公衆號（xiaomaimiaolhr）上有同步更新 ● 本文itpub地址：http://blog.itpub.net/26736162/viewspace-2147273/ ● 本文博客園地址：http://www.cnblogs.com/lhrbest/p/7838547.html ● 本文pdf版、我的簡介及小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/ ● 數據庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA寶典今日頭條號地址：http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826 ............................................................................................................................................. ● QQ羣號：230161599（滿）、618766405 ● 微信羣：可加我微信，我拉你們進羣，非誠勿擾 ● 聯繫我請加QQ好友（646634621），註明添加原因 ● 於 2017-11-01 09:00 ~ 2017-11-30 22:00 在魔都完成 ● 文章內容來源於小麥苗的學習筆記，部分整理自網絡，如有侵權或不當之處還請諒解 ● 版權全部，歡迎分享本文，轉載請保留出處 ............................................................................................................................................. ● 小麥苗的微店：https://weidian.com/s/793741433?wfr=c&ifr=shopdetail ● 小麥苗出版的數據庫類叢書：http://blog.itpub.net/26736162/viewspace-2142121/ ............................................................................................................................................. 使用微信客戶端掃描下面的二維碼來關注小麥苗的微信公衆號（xiaomaimiaolhr）及QQ羣（DBA寶典），學習最實用的數據庫技術。    小麥苗的微信公衆號      小麥苗的DBA寶典QQ羣2     《DBA筆試面寶典》讀者羣       小麥苗的微店 .............................................................................................................................................