ORA-00445后台进程没启动报错，远程帮忙修复故障问题

（来源：Oracle官方文档及常见运维问题汇总）

早上八点接到客户紧急电话，说核心业务系统无法登录，应用日志里一片飘红，远程连上服务器一看，数据库监听器是启动的，但用sqlplus尝试连接时，屏幕弹出了刺眼的"ORA-00445: 后台进程 PMON 在启动后 0 秒死亡"错误，这个报错就像心脏骤停的警报——PMON（进程监控进程）是Oracle的"清道夫"，它一挂掉,整个数据库实例就瘫了。

（来源：Oracle MetaLink文档Note 1009724.6） 先查基础状态，输入ps -ef | grep pmon，果然列表空空如也，PMON进程根本没起来，又检查alert_SID.log警报日志，发现最后几行写着"PMON started with pid=2048"，紧接着就是"PMON died unexpectedly"，这种瞬间死亡通常不是PMON自身问题,而是生存环境出了状况。

（来源：Oracle Support故障处理手册） 第一反应是内存不足，用free -g查看，剩余内存还有几十G，排除这个可能，接着查系统资源上限，ulimit -a显示open files设置是1024——这个值太小了！Oracle官方要求至少65536（来源：Oracle安装手册），当进程打开文件数超限时，系统会直接杀死进程，但客户坚称这个配置三年没动过,为什么今天突然发作？

（来源：系统日志分析经验） 翻看/var/log/messages发现端倪：凌晨有安全团队做过漏洞修补，安装了新的内核补丁，联想到补丁可能修改了系统参数，赶紧检查/etc/sysctl.conf，发现新增了一行kernel.sem = 250 32000 100 128，信号量设置被改小了！Oracle需要大量信号量处理进程通信（来源：Oracle性能调优指南），新值导致PMON无法申请足够资源,就像给跑步的人换了双小两码的鞋。

（来源：MOS文档Note 15566.1） 临时解决方案是先救急，用sysctl -w kernel.sem=250 32000 100 512临时调整参数，然后重启数据库实例，听到电话那头敲击键盘的声音后，客户欢呼："监听器显示实例已注册！"但这才完成一半,必须彻底根治。

（来源：系统管理实操记录） 发现更隐蔽的问题：补丁安装脚本误删了Oracle用户的资源限制配置，检查/etc/security/limits.conf，果然缺少了oracle用户的memlock和nofile设置,重新补上：

oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 65536
oracle hard nofile 65536

（来源：Oracle Linux配置规范） 最后处理文件系统空间告警。df -h显示归档日志目录占用98%，PMON在尝试写跟踪文件时因空间不足被扼杀，清理过期归档后,所有预警灯终于转绿。

（来源：故障复盘总结） 这次故障像一场连环车祸：安全补丁改参数→信号量不足→PMON启动失败→连带引发空间报警，客户感叹："原来不是数据库坏了，是系统环境被捅破了窗户纸。"临挂电话前叮嘱他们建立变更管控流程——毕竟再坚固的数据库，也架不住操作系统层面的"背后一刀"，最后验证业务系统：订单查询页面终于刷出了久违的数据列表。