oracle数据库出现ORA-27125: unable to create shared memory segment解决办法

本文介绍了解决Linux环境下Oracle数据库启动时报ORA-27125错误的方法,通过修改hugetlb_shm_group文件允许指定用户组创建共享内存段。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在linux中的oracle数据库出现ORA-27125: unable to create shared memory segment解决办法。

平台环境:Linux Red Hat Enterprise Linux Server release 6.0 (Santiago)

数据库版本:Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi


安装好ORALCE数据库后,启动数据库就会报如下错误

当启动数据库或者创建数据库时都可能出现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

然后启动数据库,问题消失。
那么hugetlb_shm_group组是什么呢?以下是解释:
hugetlb_shm_group contains group id that is allowed to create SysV shared memory segment using hugetlb page


另在安装过程中遇到的操作系统验证错误,可以通过如下方式解决:
在Linux系统中安装oralce的过程中,如果Linux发行版本不是oracle的推荐版本,可能会报如下错误,导致runInstaller无法完成:
Checking operating system version: must be redhat-3, SuSE-9, redhat-4, UnitedLinux-1.0, asianux-1 or asianux-2
Failed <<<<

遇到这个问题,可以通过如下三种方式解决

1、修改Linux的发行标记

如在redhat-5上安装oracle的时候,需要将文件 '/etc/redhat-release'的内容由
Red Hat Enterprise Linux Server release 5 (Tikanga)

修改为Oracle支持的版本
Red Hat Enterprise Linux Server release 4 (Tikanga)

2、runInstaller的时候加上-ignoreSysPreReqs参数,如:
./runInstaller -ignoreSysPreReqs

3.修改oraparam.ini的参数
增加你的系统版本号

 

4.设置数据库

[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


然后重启数据库,问题解决,但是我发现数据库服务器重启后,这个问题又会重现,又必须处理上述命令,才能成功启动数据库。治标不治本

参考http://wiki.debian.org/Hugepages后,其实只须在/etc/sysctl.conf下设置一下 hugetlb_shm_group即可一劳永逸的解决这个问题:

Create a group for users of hugepages, and retrieve it's GID (is this example, 2021) then add yourself to the group.
Note: this should 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 = 2021Create 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 0Reboot (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 systclt -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 should 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 should allow the process to lock a little bit more memory that just the 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).

### 解决 ORA-01034 和 ORA-27101 错误的方法 当遇到 `ORA-01034: ORACLE not available` 和 `ORA-27101: shared memory realm does not exist` 的错误时,通常意味着 Oracle 实例未能成功启动或未正常运行。以下是详细的排查和解决步骤: #### 1. 检查 Oracle 监听器和服务状态 确保 Oracle 监听器已启动并正在运行。可以通过命令行工具执行以下操作来启动监听器: ```bash lsnrctl start ``` 这一步骤可以确认监听器是否处于活动状态[^1]。 #### 2. 验证 Oracle SID 设置 确认环境变量中的 Oracle SID 是否正确指向目标数据库实例。如果不确定具体的 SID 名称,可以在安装目录下的配置文件中查找相关信息。 #### 3. 使用 OS 身份验证方式尝试启动数据库 有时即使服务看似已经开启,实际的数据库实例可能并未完全初始化。此时可尝试使用操作系统级别的权限来进行手动启动: ```bash sqlplus / as sysdba startup exit; ``` 上述 SQL*Plus 命令允许管理员绕过常规的身份认证流程直接访问并激活数据库引擎[^3]。 #### 4. 审阅日志文件获取更多信息 对于更深入的问题诊断,建议查阅位于 `$ORACLE_HOME/diag/rdbms/<dbname>/<instance_name>/trace/alert_<instance_name>.log` 下的日志条目。这些记录能够提供关于最近一次失败的具体原因说明[^4]。 #### 5. 排除资源竞争可能性 如果有其他应用程序占用了过多系统资源,则可能导致 Oracle 进程无法获得足够的内存空间完成加载过程。利用 Linux 自带的任务管理指令监控服务器上的活跃进程及其消耗情况可以帮助识别潜在冲突源: ```bash ps -eo user,pid,ppid,%mem,%cpu,comm --sort=-%mem | head ``` 这条命令会列出按内存占用量排序后的前十位程序列表[^5]。 通过遵循以上指南应该能有效处理大多数情况下由 ORA-01034 及其关联编号所引发的技术难题。不过需要注意的是,在实施任何更改之前最好先备份现有设置以防万一;另外针对特定版本特性也可能存在差异化的修复路径,请参照官方文档寻求最权威指导。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值