ps - ef | grep smon 和 ps - ef | grep pmon 有什么区别
时间: 2023-10-28 08:44:29 浏览: 386
这两个命令都是用来查找 Oracle 数据库进程的。
- `ps -ef | grep smon`:该命令将列出所有正在运行的进程,并使用 grep 命令过滤以 `smon` 结尾的进程,`smon` 是 Oracle 数据库中的一个进程,它负责实例的系统监视和清理工作。
- `ps -ef | grep pmon`:该命令同样列出所有正在运行的进程,并使用 grep 命令过滤以 `pmon` 结尾的进程,`pmon` 是 Oracle 数据库中的另一个进程,它负责实例的进程监视和恢复工作。
因此,这两个命令的区别在于它们过滤的进程不同。如果你想查看数据库实例的系统监视和清理进程,则使用 `ps -ef | grep smon`;如果你想查看数据库实例的进程监视和恢复进程,则使用 `ps -ef | grep pmon`。
相关问题
ps -ef | grep ora_ 这个命令有什么作用
### 组合命令的功能
`ps -ef | grep ora_` 是一种常见的 Linux 或 Unix 系统中的管道命令组合,用于查找与 `ora_` 开头的相关进程。以下是该命令的具体作用:
#### 1. **`ps -ef`**
`ps -ef` 命令会显示当前系统上所有的运行进程及其详细信息。它提供了关于每个进程的全面视图,包括但不限于以下字段:
- 用户名 (USER)
- 进程 ID (PID)
- 父进程 ID (PPID)
- CPU 使用时间
- 启动时间和终端信息
- 执行的命令行[^3]
此部分的作用是从整个系统的进程中提取完整的列表。
#### 2. **`grep ora_`**
`grep` 是一个强大的文本过滤工具,能够匹配指定模式的内容并将其筛选出来。在这里,`grep ora_` 的作用是仅保留那些包含字符串 `ora_` 的行。这通常用来定位 Oracle 数据库实例相关的后台进程名称,例如 `ora_pmon_<SID>`、`ora_smon_<SID>` 等。
通过这种组合方式,可以快速找到特定于某个数据库实例的所有活动进程。
---
### 应用场景分析
此类命令广泛应用于管理 Oracle 数据库环境的过程中,具体用途如下:
#### 1. 验证数据库实例状态
管理员可以通过查看是否存在某些关键进程来判断数据库是否正常启动。例如,如果发现缺少像 PMON(Process Monitor)、SMON(System Monitor)这样的核心守护程序,则表明可能存在严重问题需要进一步排查。
#### 2. 调试性能瓶颈
当遇到 ORA 错误或者异常高负载情况时,利用上述方法可以帮助识别哪些具体的 Oracle 工作线程正在占用资源过多。比如,在发生 ORA-01575 故障期间,可能会注意到 SMON 正在执行大量的空间重组工作而导致 CPU 利用率达到峰值[^5]。
#### 3. 自动化监控脚本开发
为了实现持续健康状况监测,运维人员经常编写 shell 脚本来定期调用类似的查询逻辑,并将结果记录下来供后续分析使用。下面给出一段简单的例子演示如何捕获这些数据并将它们保存到文件当中去:
```bash
#!/bin/bash
LOGFILE="/tmp/oracle_process.log"
echo "$(date): Capturing running processes..." >> $LOGFILE
ps -ef | grep ora_ | grep -v grep >> $LOGFILE
```
这里额外加了一个 `grep -v grep` 来排除掉本身由 `grep` 引起的结果干扰项。
---
### 注意事项
尽管这种方法简单有效,但也存在一些潜在陷阱需要注意规避:
- 如果目标服务器上有多个不同版本甚至类型的 RDBMS 安装共存的话,那么仅仅依赖关键字搜索可能不够精确;
- 对于大规模部署而言,手动逐台机器登录检查效率低下,建议采用集中式的解决方案如 EM Cloud Control 或第三方工具替代之;
---
连接到: Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production SQL> startup nomount; ORA-01081: ????????? ORACLE - ?????? SQL> alter database mount; alter database mount * 第 1 行出现错误: ORA-63995: ?????????????: (? 3, # ? 1) ORA-00202: ?
在Oracle Database 12.2.0.1环境中,若用户尝试启动数据库实例时遇到`ORA-01081: cannot start already-running ORACLE instance - shut it down first`错误,并随后尝试挂载数据库时又出现`ORA-63995: unknown error`与`ORA-00202: control file: '%s'`错误,则说明数据库实例状态存在冲突或控制文件损坏。以下是对此类问题的诊断与解决方法。
### 问题分析
#### `ORA-01081` 错误
此错误通常表示数据库实例已经运行,而用户试图再次启动该实例。这可能是因为:
- 实例未正确关闭,导致残留进程仍在运行;
- 操作系统级别的Oracle进程(如`pmon`、`smon`等)未被清除;
- 共享内存段或信号量仍被占用。
#### `ORA-63995` 和 `ORA-00202` 错误
这两个错误通常与控制文件相关。`ORA-00202`明确指出控制文件存在问题,可能的原因包括:
- 控制文件路径配置错误;
- 控制文件损坏或丢失;
- 多路复用控制文件中部分文件不可用;
- 文件权限或属主设置不正确。
### 解决方案
#### 1. 清理已存在的实例进程
首先确认当前是否有Oracle进程正在运行:
```bash
ps -ef | grep oracle
```
查找类似以下的进程:
```
oracle 1234 1 0 10:00 ? 00:00:00 ora_pmon_orcl
oracle 1235 1 0 10:00 ? 00:00:00 ora_smon_orcl
```
若存在此类进程,使用以下命令强制清理:
```bash
kill -9 <pid>
```
同时检查并删除共享内存段和信号量:
```bash
ipcs -m | grep oracle
ipcrm -m <shmid>
ipcs -s | grep oracle
ipcrm -s <semid>
```
#### 2. 验证控制文件路径与状态
检查参数文件(`spfile`或`pfile`)中的`CONTROL_FILES`参数是否指向正确的控制文件路径:
```sql
SQL> show parameter control_files;
```
确保列出的所有控制文件都存在且可读写。若发现某个控制文件缺失或损坏,应从备份恢复或重建控制文件。
#### 3. 使用RMAN重建控制文件(如有备份)
如果控制文件确实损坏且无法修复,可以使用RMAN从备份中恢复:
```bash
RMAN> restore controlfile from autobackup;
```
或者手动创建新的控制文件:
```sql
CREATE CONTROLFILE REUSE DATABASE "orcl" NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 ('/u01/oradata/orcl/redo01.log') SIZE 50M,
GROUP 2 ('/u01/oradata/orcl/redo02.log') SIZE 50M,
GROUP 3 ('/u01/oradata/orcl/redo03.log') SIZE 50M
DATAFILE
'/u01/oradata/orcl/system01.dbf',
'/u01/oradata/orcl/sysaux01.dbf',
'/u01/oradata/orcl/undotbs01.dbf',
'/u01/oradata/orcl/users01.dbf'
CHARACTER SET AL32UTF8;
```
#### 4. 启动并挂载数据库
完成上述操作后,重新尝试启动数据库:
```sql
SQL> startup nomount;
SQL> alter database mount;
SQL> alter database open;
```
### 总结
当遇到`ORA-01081`与`ORA-63995`、`ORA-00202`错误时,需重点排查Oracle进程残留、共享内存与信号量残留以及控制文件状态。通过清理进程、验证控制文件路径及必要时重建控制文件,可有效解决此类问题[^2]。
---
阅读全文
相关推荐














