ORA-07581报错搞不定，进程名怪怪的导致SID拿不到，远程帮你修复问题

ORA-07581报错搞不定，进程名怪怪的导致SID拿不到，远程帮你修复问题

前几天，一个朋友火急火燎地找我，说他的Oracle数据库突然连不上了，应用全瘫，屏幕上赫然显示着一个他从来没见过的错误：ORA-07581，他查了半天文档，越查越迷糊，最要命的是，他连出问题的具体数据库实例（SID）都确定不了，因为系统里看到的进程名字“怪怪的”，跟平时完全不一样，眼看问题迟迟解决不了，业务中断时间越来越长,他只好找我远程帮忙。

我让他先别慌，把错误信息的截图发过来，ORA-07581这个错误代码，根据Oracle官方文档的解释，通常与操作系统层面的进程创建失败有关，比如资源不足（像进程数、内存或交换空间达到上限）或者某些必要的系统调用失败了，但光知道这个大概方向没用,必须找到是哪个具体的数据库实例进程出了问题。

关键点就卡在了他说的“进程名怪怪的”这个地方，正常情况下，在Linux或Unix系统里，我们使用ps -ef | grep ora_这样的命令，会看到一堆Oracle的后台进程，名字非常有规律，比如ora_pmon_<SID>, ora_smon_<SID>, ora_dbw0_<SID>等等，这里的<SID>就是数据库的系统标识符,一眼就能看出是哪个库的进程。

但朋友执行命令后发过来的结果却让人一愣，进程列表里确实有Oracle相关的进程，但名字不再是规整的ora_pmon_他的库名这种格式，而是出现了一些看起来随机或者非常规的命名，比如名字特别长，夹杂着一些数字和奇怪的字符，甚至有些进程名看起来不完整，这就导致我们无法直接从进程名中提取出清晰的SID，不知道到底哪个进程对应着那个出问题的数据库实例，有点像在人群中找人,但每个人戴的面具都遮住了最关键的身份信息。

这种情况下，常规的排查路径就走不通了，我们不能直接针对一个明确的SID去检查它的告警日志（alert log），也无法精准地使用sqlplus / as sysdba连接到具体的实例去查看内部状态,问题变得有点棘手。

远程连接上他的服务器后，我决定换个思路，既然从进程名直接读SID这条路暂时断了,我们就得找别的线索来定位。

第一步，扩大搜索范围。 我让他别只盯着ora_开头的进程看，我指导他使用了更详细的进程查看命令，比如ps -ef --forest，这样可以看清进程的父子关系，Oracle的数据库实例其实是由一个共同的父进程派生出来的，找到这个“根”可能就有线索，我让他检查了系统最近的核心系统日志（比如/var/log/messages），看看在报错的时间点附近，操作系统本身有没有记录下什么相关的错误信息，比如资源耗尽（out of memory, too many processes）的记录，ORA-07581的根因就在操作系统的日志里。

第二步，检查Oracle的公共区域。 每个Oracle数据库实例在服务器上都会有一个对应的内存共享段和信号量集，我让他使用操作系统的命令（如ipcs -a）来列出所有的共享内存和信号量，这些系统资源在创建时，通常会与SID有关联的key，虽然进程名乱了，但这些底层资源的关键字可能还保持着一定的规律性，我们仔细查看ipcs的输出，寻找那些属于Oracle用户（通常是oracle）的资源，并尝试从它们的key或owner信息中反推可能的SID,这是一个需要耐心和经验的步骤。

第三步，追踪进程来源。 我让他挑一个看起来最“像”Oracle后台进程的、名字奇怪的进程，记下它的进程号（PID），使用lsof -p <PID>命令，列出这个进程打开的所有文件，一个Oracle数据库进程必然会打开数据库的控制文件、数据文件、重做日志文件以及最重要的——告警日志文件，通过查看它打开的文件路径，我们就能确定数据库的存储位置，进而从路径结构中推断出SID，文件路径中往往包含了/u01/app/oracle/oradata/<SID>/...这样的模式，<SID>就藏在这里面,这招通常是杀手锏。

果然，在用lsof命令检查了一个名字古怪的进程后，我们在其打开的文件列表中清晰地看到了告警日志文件的完整路径：/u01/app/oracle/diag/rdbms/他的真实SID/他的真实SID/trace/alert_他的真实SID.log，至此，那个“丢失”的SID终于浮出水面了！

找到SID后，问题就解决了一大半，我们立刻去查看这个确定的告警日志，在错误发生的时间点，日志里详细记录了ORA-07581错误，并且紧跟着更具体的操作系统错误信息，提示是“无法创建新进程，达到最大用户进程数上限”，原来，是操作系统级别的maxuprc（每个用户最大进程数）参数设置得太低，而当时系统连接数激增，导致Oracle无法fork出新的服务器进程来处理连接请求，从而引发了ORA-07581。

根本原因找到，解决方案就简单了,我指导他：

1. 临时解决：以root用户身份，清理掉一些无用的僵死进程或非关键的进程,释放进程槽位。
2. 永久解决：修改操作系统的内核参数（比如/etc/security/limits.conf文件），适当提高oracle用户的nproc（最大进程数）限制，然后重启服务器（或者至少让oracle用户重新登录）使设置生效。

参数调整完成后，数据库实例顺利启动，一切恢复正常，至于最初那个“怪怪的”进程名，后来我们分析，可能是在数据库异常崩溃或进程状态极度混乱的情况下，操作系统显示进程信息时出现了异常，或者某些后台进程在异常终止过程中其命令行参数没有被正确显示，属于一种非典型现象，但只要我们掌握了多种排查手段，不管进程名怎么“怪”，总能找到蛛丝马迹，定位到问题的核心,这次远程支援也算是有惊无险地完成了。