ORA-07265报错，信号量加不动了，远程帮忙修复故障方案分享

ORA-07265报错，信号量加不动了，远程帮忙修复故障方案分享

（引用来源：某Oracle技术社区资深DBA故障处理实录）

那天晚上快十一点,我正准备休息，手机突然急促地响了起来，一看是值班同事的电话，心里就咯噔一下，接起来一听，果然是生产数据库出问题了，应用大面积告警，核心系统几乎停摆，同事在电话那头语气焦急，说数据库日志里疯狂刷ORA-07265错误，后面还跟着一句“smon timer wait”，他们尝试重启了数据库实例，但问题依旧，甚至重启过程都变得异常缓慢。

我立刻打开电脑,通过VPN连上公司的跳板机，再登录到出问题的Linux服务器上，ORA-07265这个错误，我有点印象，通常和操作系统的信号量（Semaphore）有关，信号量是操作系统提供的一种进程间通信机制，Oracle数据库用它来协调多个后台进程（比如DBWn写数据文件、LGWR写日志文件等）之间的工作，防止出现“踩踏”事件，确保数据一致性，你可以把它想象成一个大楼里的钥匙盘，每个进程要操作关键资源前，必须先申请一把“钥匙”（信号量），用完了再还回去，如果钥匙被借光了，后续的进程就只能排队干等着，这就是所谓的“信号量加不动”。

我用了最直接的命令来查看当前的信号量使用情况：ipcs -s，这个命令列出了系统里所有信号量集的详细信息，果然，一眼就看到了大量属于Oracle用户的信号量，状态大多都是“等待中”（waiting），而且很多看起来已经存在了很长时间，这不正常，正常情况下，信号量应该是被进程快速获取和释放的。

紧接着,我查看了信号量系统的内核参数限制，命令是sysctl -a | grep sem，重点看四个参数：

• semmni：整个系统允许的信号量集的最大数量。
• semmsl：每个信号量集允许的最大信号量个数。
• semmns：整个系统允许的信号量总数。
• semopm：每次semop系统调用可以执行的信号量操作的最大数量。

（引用来源：Oracle官方文档中关于UNIX/Linux系统配置的部分）将查到的参数值与Oracle安装文档中推荐的值进行对比，发现semmns（系统信号量总数）这个参数设置得过低了，根据当前数据库的进程数和并发需求，这个限额显然不够用，导致可用的“钥匙”总数太少，很快就被耗尽了，新的进程自然就“加不动”信号量了。

找到根本原因后,修复方案就清晰了，但修改内核参数需要root权限，而且修改后必须重启服务器才能生效，这可是生产系统，不能草率行事，我的处理步骤如下：

1. 立即缓解：既然重启实例无效，说明有残留的孤儿进程或信号量没有被彻底清理，我使用ipcs -s命令，结合grep oracle找出所有Oracle相关的信号量ID，然后非常谨慎地使用ipcrm -s <信号量ID>命令，逐个手动清理掉那些状态异常的信号量。这里必须极度小心，一定要确认清理的是已经僵死或无用的信号量，否则可能引发数据损坏。 清理完毕后，我再次尝试重启Oracle数据库实例，这次重启过程顺利了很多，数据库成功打开，应用连接逐渐恢复，暂时缓解了业务中断的危机。

2. 根本解决：但这只是临时抱佛脚，为了防止问题复发，必须调整操作系统的内核参数，我联系了运维团队，提交了变更申请，说明情况的紧急性，在获得批准后，我们安排了临时的维护窗口，具体操作是修改/etc/sysctl.conf文件，将kernel.semmni、kernel.semmsl、kernel.semmns等参数的值，按照Oracle官方建议和我们的系统规模，调整到了一个更合理的、留有充足余地的数值，我们将semmns的值从原来的几千大幅提升到了几万。

3. 修改完成后，保存文件，并执行sysctl -p命令让新的参数生效，但需要注意的是，对于信号量的某些参数，完全生效可能需要重启操作系统。 考虑到业务的连续性要求，我们决定在当晚观察，如果不再出现报错，就在周末再进行一次计划内的重启以彻底固化配置。

4. 后续排查：问题解决后，我并没有就此打住，为什么信号量会耗尽？是遇到了什么罕见的BUG，还是应用端有异常的连接或操作？我仔细检查了数据库的告警日志，寻找在问题爆发前是否有其他异常，也和应用团队沟通，确认近期是否有大规模的批量任务上线或异常的并发访问，后来发现，那天晚上正好有一个新上线的定时任务，由于代码逻辑问题，导致了数据库连接池的泄漏，短时间内创建了远超预期的服务器进程，成为了压垮信号量资源的“最后一根稻草”，我们协同应用团队修复了那个任务的代码。

这次远程故障处理让我深刻体会到,数据库的问题往往不只是数据库本身的问题，它和操作系统、应用设计都紧密相关，ORA-07265虽然不常见，但一旦出现就是严重故障，作为DBA，不仅要熟悉Oracle的内部原理，还要对操作系统层面的知识有足够的了解，平时就要未雨绸缪，按照官方建议合理配置系统参数，并建立完善的监控告警机制，对信号量、共享内存等资源的使用率进行监控，才能在问题萌芽阶段就发现并处理，避免这种深夜的紧急抢修。