如何查看后台进程状态_ps -ef | grep ora_命令巡检-Oracle-PHP中文网

ps -ef | grep ora 常漏掉关键进程，因匹配过宽且包含grep自身；应改用 ps -eo pid,state,comm,args | grep "ora\_" | grep -v grep 并验证状态是否为R/S。

ps -ef | grep ora 为什么经常漏掉关键进程

这条命令看似能查 oracle 相关进程，实际常漏掉 ora_pmon_、ora_smon_ 等核心后台进程，甚至把 grep 自己也列进来干扰判断。根本原因是 grep ora 会匹配任意含 ora 的字符串，比如日志路径里的 /ora/data、用户 home 路径里的 /home/oraadmin，而真正进程名开头是 ora_，中间还有下划线和实例名。

用 ps -ef | grep "ora_" 替代 grep ora，避免误匹配非进程项
加 -v grep 过滤掉 grep 自身那行：ps -ef | grep "ora_" | grep -v grep
如果实例名已知（如 orcl），直接锚定：ps -ef | grep "ora_.*orcl$"，结尾 $ 防止匹配到 orcl1 这类子串
注意大小写 —— Linux 下 ps 输出的用户名、命令路径默认小写，但 Oracle 进程名中实例名可能大写，建议用 grep -i "ora_" 更稳妥

如何确认 ora_pmon、ora_lgwr 这些关键进程是否存活

不能只看“有没有输出”，得验证进程状态是否为 R（运行）或 S（睡眠），而不是 Z（僵尸）或空字段（可能已僵死但未回收）。尤其 ora_pmon_ 和 ora_lgwr_ 缺一不可，前者负责实例恢复，后者控制日志写入，挂了会导致数据库 hang 住。

检查状态列（第8字段）：ps -eo pid,user,comm,state,args | grep "ora_[pl]mon\|ora_lgwr" | grep -v grep
comm 列显示的是去掉路径的命令名（如 ora_pmon_orcl），比 args 更干净，适合脚本解析
若发现状态是 Z，说明进程已终止但父进程没 wait，需进一步查 ps -eo pid,ppid,stat,comm | grep 'Z' 看是否关联到 oracle 用户的主进程

巡检时要不要加 -o 自定义输出字段

默认 ps -ef 输出 9 列，含冗余信息（如启动时间、TTY），既难读又影响管道后续处理。巡检不是查历史，重点就三个：PID、状态、完整命令名。少字段还能减少因列宽截断导致的误判。

推荐固定组合：ps -eo pid,state,comm,args —— pid 用于 kill 或跟踪，state 看是否卡住，comm 快速识别进程类型，args 校验实例名和参数
避免用 ps -ef --no-headers：部分老系统（如 RHEL6）不支持 --no-headers，直接报错；用 tail -n +2 更兼容
如果要导出给同事看，加 column -t 对齐：ps -eo pid,state,comm,args | grep "ora_" | grep -v grep | column -t

自动化巡检脚本里怎么避免误报

定时任务跑 ps -ef | grep ora 最容易在数据库刚启停、RAC 切换、ADG 同步延迟时误报。真实问题往往不是“进程没了”，而是“该有的没起来”或“起了但状态异常”。所以得结合实例状态反向验证。

先查 sqlplus / as sysdba -c "select status from v$instance;"，只有 OPEN 或 MOUNTED 才去查进程；否则跳过，避免在 startup 过程中误判
对每个预期进程（如 pmon、smon、lgwr、dbw0），用 pgrep -f "ora_${proc}_$ORACLE_SID" 检查是否存在，比 grep 更精准
记录上次成功巡检时间戳，若连续 3 次无 ora_lgwr 且 v$instance.status 是 OPEN，再告警；单次缺失可能是瞬时抖动