There is a CentOS machine installed Oracle, the error when starting the instance ORA-27125
Sql> Startup
Ora-27125:unable to create shared memory segment
linux-x86_64 error:1: Operation not permitted
The Linux detailed version is
# cat/proc/version
Linux version 2.6.32-358.14.1.el6.x86_64 (mockbuild@c6b10.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)) #1 SMP Tue 23:51:20 UTC 2013
0. Solutions
Querying the ID of the DBA user group
# ID Oracle
uid=502 (Oracle) gid=503 (oinstall) group =503 (Oinstall), 502 (DBA)
To add a DBA user group ID to a file/proc/sys/vm/hugetlb_shm_group
# echo 502 >/proc/sys/vm/hugetlb_shm_group
Startup database Instance
Sql> Startup
ORACLE instance started.
Total System Global Area 2147483648 bytes
Fixed Size 2022144 bytes
Variable Size 486540544 bytes
Database buffers 1644167168 bytes
Redo buffers 14753792 bytes
Database mounted.
Database opened.
1. Related explanation
For reference to the relevant concepts related to the Hugetlb file, refer to this article
When a process uses some memory, the CPU was 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 spaces 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 for your have, the more time it takes to find where the memory is mapped. When a process uses 1GB of the 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 Cpu/os have less entries to look-up) those are named Hug e pages (on Linux), Super pages (in BSD) or Large pages (on Windows), but it all same thing.