ORA-27125: unable to create shared memory segment的解决方法(转)

ORA-27125: unable to create shared memory segment的解决方法(转)

1. # Kernel sysctl configuration file for Red Hat Linux
2. #
3. # For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
4. # sysctl.conf(5) for more details.
5. # Controls IP packet forwarding
6. net.ipv4.ip_forward = 0
7. # Controls source route verification
8. net.ipv4.conf.default.rp_filter = 1
9. # Do not accept source routing
10. net.ipv4.conf.default.accept_source_route = 0
11. # Controls the System Request debugging functionality of the kernel
12. kernel.sysrq = 0
13. # Controls whether core dumps will append the PID to the core filename.
14. # Useful for debugging multi-threaded applications.
15. kernel.core_uses_pid = 1
16. # Controls the use of TCP syncookies
17. net.ipv4.tcp_syncookies = 1
18. # Disable netfilter on bridges.
19. net.bridge.bridge-nf-call-ip6tables = 0
20. net.bridge.bridge-nf-call-iptables = 0
21. net.bridge.bridge-nf-call-arptables = 0
22. # Controls the default maxmimum size of a mesage queue
23. kernel.msgmnb = 65536
24. # Controls the maximum size of a message, in bytes
25. kernel.msgmax = 65536
26. # Controls the maximum shared segment size, in bytes
27. kernel.shmmax = 68719476736
28. # Controls the maximum number of shared memory segments, in pages
29. kernel.shmall = 4294967296
30. ###########oracle#################
31. kernel.shmall = 2097152
32. kernel.shmmax = 2147483648
33. kernel.shmmni = 4096
34. kernel.sem = 250 32000 100 128
35. net.ipv4.ip_local_port_range = 1024 65000
36. net.core.rmem_default = 4194304
37. net.core.rmem_max = 4194304
38. net.core.wmem_default = 262144
39. net.core.wmem_max = 262144
40. vm.hugetlb_shm_group = 501

上面是我的完整的 sysctl.conf文件

ORA-27125: unable to create shared memory segment的解决方法(转)

原文：http://www.eygle.com/rss/20111202.html 
http://www.itpub.net/thread-1739835-1-1.html

在某些操作系统上，当启动数据库或者创建数据库时都可能出现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用户的组信息：

[oracle@yans1 ~]$ id oracle
uid=500(oracle) gid=502(oinstall) groups=502(oinstall),501(dba)
[oracle@yans1 ~]$ 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.