Mandatory Background Processes可以理解为强制开启的后台进程，下面来主要介绍几个常见的Mandatory Background Processes：
Process Monitor Process (PMON)
The process monitor (PMON)monitors the other background processes and performs process recovery when a server or dispatcher process terminates abnormally.PMON is responsible for cleaning up the database buffer cache and freeing resources that the client process was using. For example, PMON resets the status of the active transaction table, releases locksthat are no longer required, and removes the process ID from the list of active processes.
pmon监控其他后台进程，并且在服务器进程或者转发器进程异常终止之后执行恢复。pmon负责清理数据库的buffer cache，并且释放客户端进程使用的资源。比如说pmon重置当前活动的事务表，释放不需要的locks，，清理进程进程id（隐式回滚）。
PMON also registers information about the instance and dispatcher processes with the Oracle Net listener(see "The Oracle Net Listener"on page 16-6). When an instance starts, PMON polls the listener to determine whether it is running. If the listener is running, then PMON passes it relevant parameters. If it is not running, then PMON periodically attempts to contact it.
pmon同样注册实例和转发器进程的信息到oracle net listener中。当一个实例开启，pmon会调查listener，去确定是否正在运行。如果listener正在运行，那么pmon会传递相关的参数，如果没有运行那么pmon定期的尝试连接。
System Monitor Process (SMON)
The system monitor process (SMON)is in charge of a variety of system-level cleanup duties
smon负责系统级别的清理工作。
smon负责以下几个主要的任务
■ Performing instance recovery, if necessary, at instance startup. In an Oracle RAC database, the SMON process of one database instance can perform instance recovery for a failed instance.
■ Recovering terminated transactions that were skipped during instance recovery because of file-read or tablespace offline errors. SMON recovers the transactions when the tablespace or file is brought back online.
■ Cleaning up unused temporary segments. For example, Oracle Database allocates extents when creating an index. If the operation fails, then SMON cleans up the temporary space.
■ Coalescing contiguous free extents within dictionary-managed tablespaces.
1. 执行实例恢复。
2. 恢复异常的transaction（实例恢复期间 file or tablespace 被置为offline状态），smon会在他们置为online的时候执行恢复。
3. 清理不使用的临时segments。比如当创建index的时候需要分配临时extent，如果操作失败，smon负责清理这些临时空间。
4. 在使用字典管理表空间的时候合并连续的空闲extent。
SMON checks regularly to see whether it isneeded. Other processes can call SMON if they detect a need for it
smon为定期监控。其他进程如果需要的话也会通知smon。
Database Writer Process (DBWn)
The database writer process (DBWn) writes the contents of database buffers to data files. DBWnprocesses write modified buffers in the database buffer cache to disk (see "Database Buffer Cache"on page 14-9).
dbwn负责将更改的buffer 从db buffer cache中写到datafile中去。
Although one database writer process (DBW0)is adequate for most systems, you can configure additional processes—DBW1 through DBW9 and DBWa through DBWj—to improve write performance if your system modifies data heavily. These additional DBWnprocesses are not useful on uniprocessor systems.
通过一个dbwn进程（dbw0）就足够了，但是也可以配置更多额外的dbwr进程，它可以提升频繁更改的数据库系统的性能。当然额外的dbw进程对于单处理器系统是没有任何用处的。
dbwn写的条件：
■ When a server process cannot find a clean reusable buffer after scanning a threshold number of buffers, it signals DBWnto write. DBWnwrites dirty buffers to disk asynchronously if possible while performing other processing.
■ DBWnperiodically writes buffers to advance the checkpoint, which is the position in the redo threadfrom which instance recovery begins (see "Overview of Checkpoints"on page 13-11). The log position of the checkpoint is determined by the oldest dirty buffer in the buffer cache.
1.当服务器进程扫描了一定个数的buffer之后（厥值）仍然没有找到可以重用的buffer，那么它就会给dbwn发送一个写的信号。
2.dbwn定期的写buffer，来推进检查点(实例恢复必须开始的redo thread position）
In many cases the blocks that DBWnwrites are scattered throughout the disk. Thus, the writes tend to be slower than the sequential writes performed by LGWR. DBWn performs multiblock writes when possible toimprove efficiency. The number of blocks written in a multiblock write varies by operating system.
很多情况下，dbwn写blocks分散到不同的disk中。所以写操作会比lgwr的顺序写要慢的多。dbwn执行多块写，当可以提升性能。多块写的blocks个数由操作系统决定。
Log Writer Process (LGWR)
The log writer process (LGWR)manages the redo log buffer. LGWR writes one contiguous portion of the buffer to the online redo log. By separating the tasks of modifying database buffers, performing scattered writes of dirty buffers to disk, and performing fast sequential writes of redo to disk, the database improves performance
lgwr管理这redo log buffer。lgwr写buffer中连续的部分到online redo log 中。因为分离了更改数据库buffer的任务：dbwn散列写buffer到disk中，执行快速的顺序写到redo，所以数据库提升了性能。
lgwr写操作的发生条件：
■ A user commits a transaction (see "Committing Transactions"on page 10-10).
■ An online redo log switchoccurs.
■ Three seconds have passed since LGWR last wrote.
■ The redo log buffer is one-third full or contains 1 MB of buffered data.
■ DBWnmust write modified buffers to disk.
1. 用户提交了一个事务。
2. redo log switch 发生
3. 从上一次lgwr写操作开始已经过去了3秒
4. redo log buffer 三分之一满或者已经存储了1mb的数据量
5. dbwn必须写更改的数据到磁盘上面。
Before DBWncan write a dirty buffer, redo records associated with changes to the buffer must be written to disk (thewrite-ahead protocol). If DBWnfinds that some redo records have not been written, it signals LGWR to write the records to disk and waits for LGWR to complete before writing the data buffers to disk.
在dbwn写dirty buffer之前，redo 记录的相关的change必须已经写入了磁盘上面。如果dbwn找到了一些没有写出的redo record，那么它会给lgwr一个写的信号，并且等待lgwr完成写操作后再执行自己的写操作。（写记后写这是必须的）
LGWR and Commit
LGWR and Commits Oracle Database uses a fast commit mechanism to improve performance for committed transactions. When a user issues a COMMITstatement, the transaction is assigned a system change number (SCN). LGWR puts a commit record in the redo log buffer and writes it to disk immediately, along with the commit SCN and transaction's redo entries.
oracle database使用快速提交的原理来提升提交事务的性能。当用户使用了一个commit语句，事务就会生成一个scn号。lgwr将包含commit的redo record立刻写入到磁盘中，与事务的redo条目一起。
The redo log buffer is circular. When LGWR writes redo entries from the redo log buffer to an online redo log file, server processes can copy new entries over the entries in the redo log buffer that have been written to disk. LGWR normally writes fast enough to ensure that space is always available in the buffer for new entries, even when access to the online redo log is heavy
redo log buffer是循环的。当lgwr写redo log buffer中的redo 条目到redo log file上的时候，服务器进程就能够将新的条目copy到redo log buffer上面。lgwr通常写的非常快，以保证空间的持续可用性（redo log buffer）。
The atomic write of the redo entry containing the transaction's commit record is the single event that determinesthe transaction has committed. Oracle Database returns a success code to the committing transaction although the data buffers have not yet been written to disk. The corresponding changes to data blocks are deferred until it is efficient for DBWnto write them to the data files.
写redo条目（包含是否commit的条目）是一个原子操作。数据库会返回一个成功的代码给正在提交的事务，尽管更改的数据还没有写入到磁盘上面。这些相关的更改的数据块与磁盘上面的数据时不同的，直到dbwn将它们写入到磁盘上面。
When activity is high, LGWR can use group commits. For example, a user commits, causing LGWR to write the transaction's redoentries to disk. During this write other users commit. LGWR cannot write to disk to commit these transactions until its previous write completes. Upon completion, LGWR can write the list of redo entries of waiting transactions (not yet committed) in one operation. In this way, the database minimizes disk I/O and maximizes performance. If commits requests continue at a high rate, then every write by LGWR can contain multiple commit records.
当活动量过高的时候，lgwr可以使用分组提交。比如说如果一个用户提交了，那么lgwr会写这些事务的redo 条目到disk中。这个时候另外的用户提交，lgwr只能等到上一个操作完成后才能处理。上面的情况结束以后，lgwr能够一次操作写一组redo条目。这样数据库能够减少io并且最大化性能。如果提交请求持续在一个较高的频率上面，那么所有lgwr写操作能够包含多个提交的数据。
LGWR and Inaccessible Files
LGWR and Inaccessible Files LGWR writes synchronously to the active mirrored group of online redo log files. If a log file is inaccessible, then LGWR continues writing to other files in the group and writes an error to the LGWR trace file and the alert log. If all files in a group are damaged, or if the group is unavailable because it has not been archived, then LGWR cannotcontinue to function.
lgwr默认会同步写已经激活的log group中的所有镜像redo log文件。如果一个log file没有办法访问，那么lgwr会写这些数据到组中其他的文件中去，并且将错误写入到alert 日志中。如果组中的所有文件都无法访问，或者redo group是不可用的状态（因为没有完成归档），那么lgwr将不再可用。
Checkpoint Process (CKPT)
The checkpoint process (CKPT)updates the control file and data file headers with checkpoint information and signals DBWnto write blocks to disk. Checkpoint information includes the checkpoint position, SCN, location in online redo log to begin recovery, and so on.
ckpt更新控制文件以及数据文件头部的检查点信息，并且给dbwn信号去写数据块到磁盘上面。检查点信息包括：检查点位置，scn，恢复时开始的redo log 位置，类似这样的信息。
Manageability Monitor Processes (MMON and MMNL)
The manageability monitor process (MMON)performs many tasks related to the Automatic Workload Repository (AWR). For example, MMON writes when a metric violates its threshold value, taking snapshots, and capturing statistics value for recently modified SQL objects.
mmon执行很多关于awr的任务（自动负载资料库）。mmon写发生的情况包括：比如在度量超过了它的 厥值，产生快照，为最近更改的sql对象抓取统计信息值。
The manageability monitor lite process (MMNL)writes statistics from the Active Session History (ASH) buffer in the SGA to disk. MMNL writes todisk when the ASH buffer is full.
mmnl写统计信息从ash buffer到disk中。mmnl只有当ash buffer满的时候，才会将其写入到磁盘中。
Recoverer Process (RECO)
In a distributed database, the recoverer process (RECO)automatically resolves failures in distributed transactions. The RECO process of a node automatically connects to other databases involved in anin-doubt distributed transaction. When RECO reestablishes a connection between the databases, it automatically resolves all in-doubt transactions, removing from eachdatabase's pending transaction table any rows that correspond to the resolved transactions.
在分布式数据库中，reco进程自动的解决分布式事务发生错误的情况。一个节点上的reco进程自动的连接到没有被正确处理事务相关的数据库上面。当reco建立了数据库之间的连接，它会自动的解决没有办法处理的事务，删除与该事务相关的待定的事务表中的行（清理事务表）。
