ORA-27149错误咋整，远程帮你快速定位修复方案分享

ORA-27149错误咋整，远程帮你快速定位修复方案分享

碰到ORA-27149错误，别急着慌，这个错误信息通常跟Oracle数据库实例的内存分配有关，简单点说，就是数据库启动时想用的那块共享内存（SGA）或者进程私有内存（PGA）的大小，超出了操作系统当时能允许的单个进程最大内存限制，这就像你想在一个只能装1升水的杯子里，硬倒进去1.5升水，那肯定得溢出来，数据库也就启动失败了。

下面我就结合一些常见的处理思路和远程排查的经验,帮你一步步把这个错误给整明白，并且解决掉。

第一步：先看懂错误日志，别瞎猜

错误信息本身会给你最重要的线索,ORA-27149的错误信息通常会附带更详细的描述，你一定要把完整的错误日志找出来看，这个日志一般在Oracle的跟踪文件目录（udump 或 diag/rdbms/<数据库名>/<实例名>/trace 目录下）里，文件名字可能类似 alert_<实例名>.log。

你会看到类似这样的完整信息： ORA-27149: text of error message Linux-x86_64 Error: 22: Invalid argument

或者更具体的： ORA-27149: 指定的 SGA 大小过大 ORA-27149: size of shared memory region is greater than allowed

后面这个“Linux Error: 22”或者“greater than allowed”就是关键，它告诉你，操作系统拒绝了这次内存分配请求。

第二步：检查最直接的嫌疑犯——数据库内存参数

既然是内存大小超标,那我们第一个要查的就是数据库自己的内存设置，用SQL*Plus或者其他工具，以非启动状态（nomount状态可能进不去，那就直接查参数文件）查看以下关键参数：

1. SGA_TARGET 和 SGA_MAX_SIZE：这是SGA（系统全局区）的总大小，是不是设得特别大？比如在你一台只有8G物理内存的机器上，你设了个16G的SGA。
2. PGA_AGGREGATE_TARGET：这是PGA（程序全局区）的总大小上限。
3. MEMORY_TARGET 和 MEMORY_MAX_TARGET：如果你用了自动内存管理，这个参数定义了Oracle实例能使用的总内存（SGA+PGA）的上限，这个参数是重点怀疑对象。

怎么查？ 如果数据库还能启动到nomount状态，可以连接上去执行： SHOW PARAMETER TARGET 如果数据库完全起不来，你需要查看你的初始化参数文件（SPFILE或PFILE），可以用 strings 命令查看SPFILE内容（strings spfile<实例名>.ora | grep TARGET）。

修复行动： 如果发现这些参数值确实设得过高，远远超过了你服务器可用物理内存（比如70%-80%以上），那基本就是它了，你需要创建一个临时的PFILE来修改这些参数。

1. 根据SPFILE创建PFILE：CREATE PFILE FROM SPFILE;（如果实例起不来，可能需要用原始PFILE修改，或者用 strings 导出SPFILE内容再修改）。
2. 编辑PFILE,把 MEMORY_TARGET, SGA_TARGET 等参数调到一个合理的值，这个合理值需要根据你的物理内存来定，一般建议留给操作系统和其他应用一些内存，比如总内存的20%左右。
3. 使用修改后的PFILE启动实例：STARTUP PFILE='<你的pfile路径>'。
4. 启动成功后,再根据这个PFILE重建SPFILE：CREATE SPFILE FROM PFILE='<你的pfile路径>';。

第三步：操作系统层面的限制检查

你的数据库参数设得并不过分,但操作系统层面有个“天花板”，你设置的参数值可能碰触到了这个天花板，这个天花板就是Linux系统的内核参数。

重点检查以下两个内核参数：

1. shmmax：这个参数定义了单个共享内存段的最大尺寸，你的SGA大小不能超过这个值，检查命令：sysctl kernel.shmmax 或 cat /proc/sys/kernel/shmmax。
2. shmall：这个参数定义了系统范围内共享内存页的总量上限，检查命令：sysctl kernel.shmall 或 cat /proc/sys/kernel/shmall。

怎么判断？ 如果你的 SGA_MAX_SIZE 设置是2G（也就是2147483648字节），但你的 kernel.shmmax 值只有1073741824（1G），那显然SGA的大小就超过了单个共享内存段的上限，就会报错。

修复行动： 以root用户身份，临时修改这些内核参数（重启后会失效，用于测试）： echo 2147483648 > /proc/sys/kernel/shmmax （将shmmax设置为2G） sysctl -w kernel.shmmax=2147483648

如果临时修改后数据库能正常启动了,证明就是这个限制导致的，你需要永久修改这些参数，编辑 /etc/sysctl.conf 文件，添加或修改以下行： kernel.shmmax = 2147483648 kernel.shmall = 2097152 （这个值通常是物理内存的页数，计算方式复杂些，可以设大点） 然后执行 sysctl -p 使配置生效。

第四步：检查是否有残留的共享内存段

这是一种不太常见但确实会发生的情况,比如数据库实例异常崩溃后，之前分配的共享内存段可能没有被操作系统正常释放，当你再次启动实例时，Oracle尝试分配同样大小的内存，可能会遇到冲突或失败。

检查命令： 使用 ipcs -m 命令，查看当前系统中存在的共享内存段，重点关注那些由Oracle软件安装用户（通常是oracle）拥有的、但已经没有对应进程的共享内存段。

修复行动： 如果确认是残留的共享内存段，可以用 ipcrm 命令将其删除，首先确保没有任何Oracle进程在运行（ps -ef | grep ora_），然后使用 ipcrm -m <shmid> 命令删除对应的共享内存段，删除后再尝试启动数据库。

远程排查的心得

在远程协助别人处理这个问题时,我一般会遵循这个顺序来问和操作：

1. “先把完整的错误日志贴给我看。” —— 确认错误细节。
2. “服务器物理内存多大？看看 free -g。” —— 了解硬件基础。
3. “查一下数据库的内存参数设了多少？strings spfile... | grep TARGET” —— 对比硬件和参数设置。
4. “再查一下操作系统的 shmmax 是多少？” —— 检查操作系统限制。
5. “最后看一眼 ipcs -m，有没有奇怪的东西？” —— 排除残留内存干扰。

绝大多数情况下,问题都出在第二步和第三步，要么是DBA设置参数时手滑多打了个零，要么是系统管理员安装完操作系统后没有根据Oracle的建议优化内核参数，按照这个流程走一遍，ORA-27149这个错误基本上都能被快速定位并解决掉，希望这个分享对你有帮助！