ProcessMonitor (PMON): 该进程在用户进程出现故障时执行进程恢复，负责清理内存储区和释放该进程所使用的资源。例：它要重置活动事务表的状态，释放封锁，将该故障的进程的ID从活动进程表中移去。PMON还周期地检查调度进程（DISPATCHER）和服务器进程的状态，如果已死，则重新启动（不包括有意删除的进程）。
PMON有规律地被呼醒，检查是否需要，或者其它进程发现需要时可以被调用。
PMON进程还负责在反常中断的连接之后的清理工作。例如，如果因某些原因专用服务“故障”或被kill掉，PMON就是负责处理（恢复或回滚工作）和释放你的资源。PMON将发出未提交工作的回滚，释放锁，和释放分配给故障进程的SGA资源。
除了在异常中断之后的清理外，PMON监控其他oracle后台进程，如果有必要（和有可能）重新启动他们。如果共享服务或一个分配器故障（崩溃），PMON将插手并且重启另一个（在清理故障进程之后）。PMON将观察所有Oracle进程，只要合适或重启他们或中止进程。例如，在数据库日志写进程事件中，LGWR故障，实例故障。这是一个严重的错误，最安全的处理方法就是去立即终止实例，让正常的恢复处理数据。（注意这是很少发生的事情，应该立即报告oracle支持）。
PMON为实例做的另一件事是去使用OracleTNS监听器登记。当一个实例开启的时候，PMON进程投出众所周知的端口地址，除非指向其他，来看是否监听器正在开和运行着。众所周知/默认端口是使用1521。现在，如果监听器在一些不同端口开启会发生什么？这种情况，机制是相同的，除了监听器地址需要被LOCAL_LISTENER参数明确指定。如果监听器运行在库实例开启的时候，PMON和监听器通讯，传到它相关参数，譬如服务器名和实例的负载度量。如果监听器没被开启，PMON将周期性的试着和它联系来登记自己。
If abackground process fails, the PMON process performs the cleanup operations byperforming the following tasks:
•Rolls back the user’s current transaction
•Releases all the locks that are held on tables or rows
•Frees other resources used by the users
•Restarts the dead dispatcher
System Monitor (SMON):该进程在实例启动时执行实例恢复，还负责清理不再使用的临时段。在具有并行服务器选项的环境下，SMON对有故障CPU或实例进行实例恢复。SMON进程有规律地被呼醒，检查是否需要，或者其它进程发现需要时可以被调用。
SMON还负责做所有系统级的工作。相对于PMON对单个进程感兴趣，SMON是一个系统级别的观点，是一种用于库的“垃圾收集者”。它做的工作包括如下7件：
1清理临时表空间：伴随着“真正”的临时表空间的出现，清理临时表空间的杂事已经减轻了，但它还没完全消失。例如，当建立一个索引，在创建期间分配给索引的扩展区被标志为TEMPORARY。如果CreateIndex会话因某些原因异常中断，SMON负责清理他们。其他操作创建的临时扩展区，SMON同样会负责。
2接合空闲空间：如果你正使用数据字典管理表空间，SMON负责把那些在表空间中空闲的并且互相是邻近的extent接合成一个较大的空闲扩展区。这发生仅在带有默认的pctincrease设置为非零的存储子句的字典管理表空间。
3把对于不可用文件的事务恢复成活动状态：它的角色类似在库启动期间。这时，因为文件不能用于恢复，SMON恢复在实例/崩溃恢复期间被跳过的故障事务。例如，文件可能已经在不可用或没装载的磁盘上。当文件变可用了，SMON将恢复它。
4 执行一个RAC中故障节点的实例恢复：在一个oracleRAC配置中，当群集中的一个库实例失败（例如，实例正执行的机器故障了），一些群集中的其他节点将开启故障的实例的重做日志文件，为故障实例执行所有数据的恢复。
5清理OBJ$：OBJ$是一个包含库中几乎每一个对象（表，索引，触发器，视图等等）的记录的行级数据字典表。许多次，这儿存在的记录代表已删对象，或代表不在这儿的对象，在oracle的信赖机制中被使用。SMON是删除这些不在被需要的行的进程。
6 收缩回滚段：SMON将执行回滚段的自动收缩到它的optimal尺寸，如果它被设置。
7“脱机”回滚段：对于DBA来，让一个有active事务的回滚段，脱机或不可用，这事是可能的。Active事务正使用这脱机回滚段是可能的。在这情况下，回滚不是真正的脱机；它被标志为“悬挂offline”。在后台进程中，SMON将周期性尽力让它真正脱机，直到成功。它做许多其他事情，譬如存在DBA_TAB_MONITORING视图中的监控统计数据的洗刷，在SMON_SCN_TIME表中发现的时间戳定位信息的SCN的洗刷，等等。SMON在期间能消耗很多CPU，这应该被认为是正常的。SMON周期性的苏醒（或被其他后台进程叫醒）来执行这些管家的家庭杂事。
Ifan Oracle instance crashes, any changes that are made in the SGA are notwritten to the data files. When you restart the instance, the SMON backgroundprocess automatically performs instance recovery by performing the followingtasks:
•Rolling forward changes that are made in the online redo log files but not inthe data files. Since all the committed transactions are written to the onlineredo log files, these are successfully recovered as result of rolling forwardchanges from the online redo log files to the data files.
•Opening the database. After the database is opened, users can log on and accessany data that is not locked by un-recovered transaction.
•Rolling back all the uncommitted transactions.
memory manager(MMAN)：MMAN内存管理,如果设定了 SGA自动管理，MMAN用来协调SGA内各组件的大小设置和大小调整。
Memory Monitor(mmon)：在Oracle不同的文档中，对这两个进程的解释存在歧义。MMON应该是 Memory Monitor 的缩写，但是在有的文档中被记录为Manageability Monitor，这应当是10g早期版本中的称呼，只不过后来发生了变更。
这个进程的主要作用如下：
The memory monitor (MMON) process was introduced in10g and is associated with the Automatic Workload Repository new features usedfor automatic problem detection and self-tuning. MMON writes out the requiredstatistics for AWR on a scheduled basis.
MMON主要用于AWR，ADDM，MMON会从SGA将统计结果写到系统表中
The Memory Monitor Light (MMNL)：thisprocess is anew process in 10g which works with the Automatic Workload Repository newfeatures (AWR) to write out full statistics buffers to disk as need（这个as need怎么理解呢？mmon进程主要是内存中sql信息，ash信息的收集工作，如果这些信息需要写入到磁盘（即一些数据字典表）中，那么就需要MMNL进程负责写入。）
另外一个进程是 MMNL ，是 Memory Monitor Light (MMNL)的缩写，在部分文档中记录为 Manageability Monitor Light .
对mmon和mmnl进程的一个协调工作总结：
MMON、MMNL和Mnnn这些进程用于填充自动工作负载存储库（Automatic WorkloadRepository，AWR），这是Oracle 10g中新增的一个特性。MMNL进程会根据调度从SGA将统计结果刷新输出至数据库表。MMON进程用于“自动检测”数据库性能问题，并实现新增的自调整特性。Mnnn进程类似于作业队列的Jnnn或Qnnn进程；MMON进程会请求这些从属进程代表它完成工作。Mnnn进程本质上是临时性的，它们将根据需要来来去去。
由此可见，MMON和MMNL进程宕掉是awr不能自动收集的根本原因。
