在某些作業系統上，當啟動資料庫或者建立資料庫時都可能出現ORA-27125錯誤，我在Oracle Linux 6上安裝Oracle 10.2.0.1，建立資料庫時就遇到了這個錯誤。

這個錯誤的解決就是修改 /proc/sys/vm/hugetlb_shm_group 檔案。
以下是老楊提到過的一個問題，解決方法相同：

幫客戶解決一個Linux上資料庫無法啟動的問題。
客戶的Linux 5.6 x86-64環境，安裝資料庫後，啟動資料庫報錯：ORA-27125。
Oracle文件上關於ORA-27125錯誤的描述為：

ORA-27125: unable to create shared memory segment
Cause: shmget() call failed
Action: contact Oracle support

查詢了一下，發現問題和linux上的hugetbl有關。
解決方法也很簡單，首先檢查oracle使用者的組資訊：

[[email protected] ~]$ id oracle
uid=500(oracle) gid=502(oinstall) groups=502(oinstall),501(dba)
[[email protected] ~]$ more /proc/sys/vm/hugetlb_shm_group
0

下面用root執行下面的命令，將dba組新增到系統核心中：
# echo 501 > /proc/sys/vm/hugetlb_shm_group

然後啟動資料庫，問題消失。

但以上這種方式在重啟作業系統後失效， /proc/sys/vm/hugetlb_shm_group又變為了0，建議採用以下方式解決：

加入vm.hugetlb_shm_group = 501 到/etc/sysctl.conf中來解決：
# vi /etc/sysctl.conf
加入如下的內容，其中501為dba組號，需要根據你實際的情況進行改變。
vm.hugetlb_shm_group = 501
# sysctl -p

那麼hugetlb_shm_group組是什麼呢？以下是解釋：
hugetlb_shm_group contains group id that is allowed to create SysV shared memory segment using hugetlb page

這裡反覆提到了HugePage，以下是關於HugePage的說明和解釋：

When a process uses some memory, the CPU is marking the RAM as used by that process. For efficiency, the CPU allocate RAM by chunks of 4K bytes (it's the default value on many platforms). Those chunks are named pages. Those pages can be swapped to disk, etc.

Since the process address space are virtual, the CPU and the operating system have to remember which page belong to which process, and where it is stored. Obviously, the more pages you have, the more time it takes to find where the memory is mapped. When a process uses 1GB of memory, that's 262144 entries to look up (1GB / 4K). If one Page Table Entry consume 8bytes, that's 2MB (262144 * 8) to look-up.

Most current CPU architectures support bigger pages (so the CPU/OS have less entries to look-up), those are named Huge pages (on Linux), Super Pages (on BSD) or Large Pages (on Windows), but it all the same thing.

轉載於http://www.eygle.com/rss/20111202.html  http://www.itpub.net/thread-1739835-1-1.html