ORA-02735报错，shared memory创建失败，远程帮忙修复问题过程分享

ORA-02735报错，shared memory创建失败，远程帮忙修复问题过程分享

前段时间，有个朋友急匆匆地找我，说他负责的一个重要数据库突然启动不了了，屏幕上赫然显示着一个他从来没见过的错误：ORA-02735，他描述说，这个错误信息大概是“无法分配共享内存”，数据库是跑在Linux系统上的，之前一直运行得好好的，最近除了给系统打过一些补丁外,并没对数据库本身做什么大的改动。

我一听是共享内存分配失败，心里大概有了几个方向，共享内存对于Oracle数据库来说，就像是大家共用的一个“公告板”，所有数据库进程都要在这里读写数据，如果这个“公告板”建不起来，那数据库肯定无法启动，我让他先别慌，既然能远程连接上去,我们就一步步来排查。

第一步：检查操作系统内存情况

我让他首先登录到服务器上，执行我最常用的命令之一：free -g，这个命令能快速查看内存的使用情况，反馈回来的信息显示，系统的物理内存很大，还有不少空闲空间，这说明并不是整个服务器的物理内存耗尽了,问题可能出在操作系统对单个进程的内存限制上。

第二步：检查内核参数

Oracle数据库在启动时，需要向操作系统申请一大块共享内存段，这个能申请多大的内存，是由Linux系统的内核参数控制的，最主要的就是kernel.shmmax（定义单个共享内存段的最大尺寸）和kernel.shmall（定义系统中共享内存的总页数）。

我让他用sysctl -a | grep shm命令查看这些参数的当前设置，果然，发现了疑点，他系统上的kernel.shmmax值设置得偏小，小于我们数据库初始化参数文件（pfile）里设置的SGA_TARGET（系统全局区大小）的值，这就好比你想买个大沙发（SGA），但商场规定单个包裹的最大尺寸（shmmax）比沙发还小,沙发自然运不回家。

第三步：检查内存相关设置

除了共享内存参数，我还让他检查了另一个重要参数：/proc/sys/vm/hugetlb_shm_group，这个参数与Linux的大页内存有关，Oracle使用大页内存可以提升性能，但配置不当也会导致无法分配内存，他检查后发现，这个参数是0，意味着任何用户组的进程都可以使用大页，我们数据库的use_large_pages参数设置成了true，但当前系统的大页池可能是空的或者配置不对,这成了一个潜在的干扰项。

第四步：对比变化，找到根源

我问他最近到底做了什么系统补丁更新，他仔细查了操作记录，发现更新的不是普通的系统补丁，而是将操作系统内核升级到了一个新版本！这是一个关键线索，我推测，可能是新版本的内核在某些默认行为或参数上发生了变化,或者之前某些自定义的内核参数在升级后被重置了。

为了验证，我让他找找有没有备份的旧内核的启动参数配置文件（通常是/etc/sysctl.conf或其/etc/sysctl.d/目录下的文件），并与当前生效的参数进行对比，果然，在旧配置中，kernel.shmmax的值设置得非常大（比如接近物理内存大小），而新系统生效的值却是一个相对保守的默认值，问题根源找到了：操作系统内核升级覆盖了原先为Oracle优化过的内核参数。

第五步：实施修复

修复方案很明确：重新设置正确的内核参数。

1. 我让他以root用户身份，编辑/etc/sysctl.conf文件（或者在/etc/sysctl.d/下创建一个新的.conf文件，如99-oracle.conf）。
2. 根据他数据库的SGA大小，重新计算并写入了正确的参数值， kernel.shmmax = 一个大于SGA_TARGET的值 kernel.shmall = 一个足够大的值
3. 保存文件后，执行sysctl -p命令（如果是在/etc/sysctl.d/下新建的文件，可能需要指定完整路径，如sysctl -p /etc/sysctl.d/99-oracle.conf）,让新的参数立即生效。
4. 关于大页问题，为了快速恢复，我建议他先将数据库的use_large_pages参数临时改为false，并重启数据库实例，这样可以先绕过可能存在的复杂的大页配置问题，保证业务先跑起来,后续再专门研究和配置大页。

第六步：验证结果

他按照步骤修改完内核参数并生效后，再次尝试启动数据库，这次，屏幕上熟悉的启动日志一行行顺利滚动，没有再出现ORA-02735错误，数据库成功打开了！他连接上去检查,一切正常。

过程总结与建议

这次远程解决问题的过程,关键点在于：

• 思路清晰：从错误信息（共享内存分配失败）出发，由表及里,从操作系统整体内存状况查到具体的进程限制参数。
• 对比排查：敏锐地抓住了“系统内核升级”这个变化点，通过对比新旧配置，快速定位了问题根源——内核参数被重置。
• 先解决主要矛盾：在面对共享内存参数和大页配置两个可能的问题时，优先解决确定性的、主要的共享内存参数问题，对于暂时不明确的大页问题采取暂时禁用的策略,确保快速恢复。

我提醒他，在进行像操作系统升级这样重大的变更前，一定要提前备份好重要的配置文件，并且最好在测试环境先进行验证，修复后应该把配置大页内存列入后续的计划中,以充分发挥系统性能。

（注：此解决过程基于一次真实的Oracle数据库故障排查经历，具体操作步骤可能因实际环境差异而略有不同。）