ORA-27125: unabletocreatesharedmemorysegment

This article introduces a ORA-27125 about oracle Database in linux: unabletocreatesharedmemorysegment solution.

This article introduces a ORA-27125: unable to create shared memory segment solution for oracle databases in linux.

This article introduces a ORA-27125: unable to create shared memory segment solution for oracle databases in linux.

Platform environment: Linux Red Hat Enterprise Linux Server release 6.0 (Santiago)

Version: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0-64bi

After the ORALCE database is installed, the following error will be reported when the database is started.

A ORA-27125 error may occur when you start a database or when creating a database. I installed Oracle 10.2.0.1 on Oracle Linux 6 and encountered this error when creating a database.

The solution to this error is to modify the/proc/sys/vm/hugetlb_shm_group file.
The following is a problem that Lao Yang mentioned. The solution is the same:

It helps the customer solve the problem that the database cannot be started on Linux.
The customer's Linux 5.6 x86-64 environment, after the database is installed, the database startup error: ORA-27125.
The description of ORA-27125 errors in the Oracle document is:

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

After a query, the problem found to be related to hugetbl on linux.
The solution is also simple. First, check the oracle user group information:

[Oracle @ yans1 ~] $ Id oracle
Uid = 500 (oracle) gid = 502 (oinstall) grou = 502 (oinstall), 501 (dba)
[Oracle @ yans1 ~] $ More/proc/sys/vm/hugetlb_shm_group
0

Run the following command as root to add the dba group to the system kernel:

# Echo 501>/proc/sys/vm/hugetlb_shm_group

Then start the database and the problem disappears.
So what is the hugetlb_shm_group group? The following is an explanation:
Hugetlb_shm_group contains group id that is allowed to create SysV shared memory segment using hugetlb page

In addition, the operating system verification errors encountered during installation can be solved through the following methods:
In the process of installing oralce in Linux, if the Linux release version is not the recommended version of oracle, the following error may be reported, causing the runInstaller to fail:
Checking operating system version: must be redhat-3, SuSE-9, redhat-4, UnitedLinux-1.0, asianux-1 or asianux-2
Failed <

You can solve this problem in the following three ways:

1. Modify the Linux release tag

For example, when installing oracle on a redhat-5, you need to change the contents of the '/etc/redhat-release' file from
Red Hat Enterprise Linux Server release 5 (Tikanga)

Changed to a version supported by Oracle
Red Hat Enterprise Linux Server release 4 (Tikanga)

2. Add the-ignoreSysPreReqs parameter to runInstaller, for example:
./RunInstaller-ignoreSysPreReqs

3. Modify oraparam. ini Parameters
Add your system version number

4. Set the database

[Root @ DB-Server ~] # Id oracle
Uid = 501 (oracle) gid = 502 (oinstall) groups = 502 (oinstall), 501 (dba)

[Root @ DB-Server ~] # Echo 501>/proc/sys/vm/hugetlb_shm_group

Then restart the database and solve the problem. However, after the database server is restarted, the problem will reappear and the above commands must be processed before the database can be started successfully. Permanent cure

After you refer to http://wiki.debian.org/hugepages, you only need to set hugetlb_shm_group under /etc/sysctl.confto solve this problem once and for all:

Create a group for users of hugepages, and retrieve it's GID (is this example, 2021) then add yourself to the group.
Note: this shoshould not be needed for libvirt (see/etc/libvirt/qemu. conf)

% Groupadd my-hugetlbfs

% Getent group my-hugetlbfs
My-hugetlbfs: x: 2021:

% Adduser franklin my-hugetlbfs
Adding user 'franklin' to group 'my-hugetlbfs '...
Adding user franklin to group my-hugetlbfs
Done. Edit/etc/sysctl. conf and add this text to specify the number of pages you want to reserve (see pages-size)

# Allocate 256 * 2MiB for HugePageTables (YMMV)
Vm. nr_hugepages = 256

# Members of group my-hugetlbfs (2021) can allocate "huge" Shared memory segment
Vm. hugetlb_shm_group = 2021 Create a mount point for the file system

% Mkdir/hugepagesAdd this line in/etc/fstab (The mode of 1770 allows anyone in the group to create files but not unlink or rename each other's files.1)

Hugetlbfs/hugepages hugetlbfs mode = 1770, gid = 2021 0 0 Reboot (This is the most reliable method of allocating huge pages before the memory gets fragmented. you don't necessarily have to reboot. you can try to run your CLT-p to apply the changes. if grep "Huge"/proc/meminfo don't show all the pages, you can try to free the cache with sync; echo 3>/proc/sys/vm/drop_caches (where "3" stands for "purge pagecache, dentries and inodes") then try sysctl-p again. 2)

Limits. conf
You shoshould configure the amount of memory a user can lock, so an application can't crash your operating system by locking all the memory. note that any page can be locked in RAM, not just huge pages. you shoshould allow the process to lock a little bit more memory that just the space for hugepages.

# Get huge-page size:
% Grep "Hugepagesize:"/proc/meminfo
Hugepagesize: 4096 kB

# What's the current limit
% Ulimit-H-l
64

# Just add them up... (how many pages do you want to allocate ?) See Limits (ulimit-l and memlock in/etc/security/limits. conf ).