Oracle 体系结构三 后台进程

实例后台进程在启动实例时启动，在终止实例时终止运行。

 

 

SMON

SMON（system monitor）起初的任务是安装和打开数据。SMON经过查找和验证数据库控制文件来安装数据库。此后，它经过查找和验证全部数据文件和联机日志文件，来打开数据库。一旦打开数据库并使数据库处于使用状态后，SMON就负责执行各类内部管理任务，如合并数据文件中的可用空间。

 

系统监视器（System Monitor）要完成全部“系统级”任务。PMON感兴趣的是单个的进程，而SMON与之不一样，它以系统级为出发点，这是一种数据库“垃圾收集器”。SMON所作的工做包括如下几种：

 

• • 清理临时空间：例如，创建一个索引时，建立时为索引分配的区段标记为TEMPORARY。若是处于某种缘由CREATE INDEX会话停止了，SMON就要负责清理。其余操做建立的临时区段也要有SMON负责清理。

 

• • 合并空闲空间：若是你在使用字典管理的表空间，SMON要负责取得表空间中相互连续的空间区段，并把它们合并为一个更大的空闲区段。只有当字典管理的表空间有一个默认的存储子句，并且pctincrease设置为一个非0值时，才会出现空闲空间的合并。

 

• • 针对原来不可用的文件恢复活动的事务：这相似与数据库启动时SMON的做用。在实例/崩溃恢复时因为某个文件（或某些文件）不可用，可能会跳过一些失败的事务（即没法恢复），这些失败事务将由SMON来恢复。例如，磁盘上的文件可能不可用或未装载，当文件确实可用是，SMON就会由此恢复事务。

 

• • 执行RAC中失败节点的实例恢复：在一个Oracle RAC配置中，集群中的一个数据库实例失败时（例如，实例所在主机失败），集群中的另外某个节点会打开该失败实例的重作日志文件，并为该失败实例完成全部数据的恢复。

 

• • 清理OBJ$：OBJ$是一个低级数据字典表，其中几乎对每一个对象（表、索引、触发器、视图等）都包含一个条目。不少状况下，有些条目表示的多是已经删除的对象，或者表示“not there”对象（“not there”对象是Oracle一来机制中使用的一种对象）。要有SMON进程来删除这些再也不须要的行。

 

• • 收缩回滚段：若是有设置，SMON会自动将回滚段收缩为所设置的最佳大小。

 

• • “离线”回滚段：DBA有可能让一个有活动事务的回滚段离线（offline），或置为不可用。也有可能活动事务会使用离线的回滚段。在这种状况下，回滚段并无真正离线；它只是标记为“简要离线”。在后台，SMON会按期尝试真正将其置为离线，知道成功为止。

 

除此以外，它还会作许多其余的事情，如将DBA_TAB_MONITIRING视图中的监视统计信息刷新输出，将SMON_SCN_TIME表中的SCN-时间戳映射信息刷新输出，等等。随着时间的推移，SMON进程可能会累计地占用大量CPU时间，这应该是正常的。SMON会按期地醒来（或者被其余后台进程唤醒），来执行这些维护工做。

 

PMON

用户会话是链接到服务器进程的用户进程。服务器进程在此会话建立时启动，在会话结束时销毁。从会话中有序退出涉及用户注销。在这种状况下，用户执行的任何工做都将有序完成，服务器进程将终止。若是以无序方式终止会话（多是用户计算机从新启动），那么会话将处于一个必须进行清理的状态。PMON（process monitor）监视全部服务器进程，并检测会话中的任何问题。若是会话异常终止，PMON将销毁服务器进程，将其PGA内存返回给操做系统的空闲内存池，并回滚任何尚在进行的未完成事务。

进程监视器（Process Monitor）负责在出现异常停止的链接以后完成清理，还负责监视其余的Oracle后台进程，并在必要时重启这些后台进程，也可能适当地停止实例。PMON还会为实例作另外一件事，这就是向Oracle TNS监听器注册这个实例。实例启动时，PMON进程会询问公认的端口地址（1521），来查看是否启动并运行了一个监视器。若是数据库实例启动时有监听器在运行，PMON会与这个监听器通讯，并向它传递相关的参数，如服务名和实例的负载度量等。若是监听器未启动，PMON则会按期地试图与之联系来注册实例。（12c中由LREG来实现此功能）

DBWn

会话一般并不将数据写入磁盘。会话将数据（或现有数据的更改）写入数据库缓冲区缓存中的缓冲区。由数据库写入器负责随后将缓冲区写入磁盘。一个实例可能有多个数据库写入器（最多不超过100个），一次称为DBW0到DBW9，而后是DBWa到DBWz，超过36的写入器命名为BW36到BW99。默认数量是每8个CPU对应一个数据库写入器（向上舍入）。在如下4种状况下，DBWn将执行写操做：没有任何可用缓冲区、脏缓冲区过多、遇到三秒超时或遇到检查点。

没有任何可用缓冲区的状况：若是服务器进程须要将块复制到数据库缓冲区缓存中，首先必须查找空闲的缓冲区。这种缓冲区是指既不脏（更新过，但还没有写回磁盘）也未被占用（即相应时刻正被另外一个会话使用）的缓冲区。不能重写脏缓冲区，不然将丢失已更改的数据，也不能重写被占用的缓冲区，由于操做系统的内存保护机制不容许这么作。若是服务器进程超找空闲缓冲区用时过长（具体时限由Oracle内部肯定），就会通知DBWn将某些脏缓冲区写入磁盘。一旦完成，缓冲区就是干净的，也就有了空闲的缓冲区可用。

脏缓冲区过多：这是由另外一个内部阈值肯定的。

遇到三秒超时：DBWn没三秒钟会对一些缓冲区清理一次。在实践中，这对生产系统影响不大，由于前面描述的两种状况将强制执行写入，但超时意味着：即便系统处于闲置状态，最终也会清理数据库缓冲区缓存。

可能存在请求的检查点：前面列出的三个缘由将致使DBWn将有限数量的脏缓冲区写入数据文件。而当遇到检查点时，会写入全部脏缓冲区。因前三个缘由而写入缓冲区称为增量检查点，或提升增量检查点位置。这是在正常运行过程当中应该执行的，并进行优化，使缓冲区根据须要来提供，而不会给I/O系统增长压力，而影响了性能。这意味着可能有几十万个脏缓冲区。在检查点期间，磁盘I/O数量将达到顶峰，CPU使用率可能高达100%，最终用户会话的性能将降低。当完成检查点后（这可能须要数分钟的时间），性能将恢复到一般的状态。惟一绝对须要检查点的时刻是：关闭了数据库，关闭了实例。检查点将多有脏缓冲区写入磁盘：这就实现了缓冲区缓存与数据文件的同步，实例与数据库的同步。在一般的运行状态下，数据文件始终是过期的：它们缺乏多个更改（提交的更改或未提交的更改）。这不会带来问题：由于缓冲区缓存中的数据块副本是最新的，而会话使用的正是这些数据块。在关闭期间，有必要将全部内容写入磁盘。更经常使用的是局部检查点，局部检查点强制DBWn写入仅包含一个或多个数据文件（而不是整个数据库）的块的全部脏缓冲区：在数据文件或有表空间脱机时；在将表空间植入备份模式时；或在将表空间设置为只读时。与彻底检查点相比，这些检查点的力度较小，每次在相关事件发生时自动执行。

Oracle切换日志文件时就会标记（创建）一个检查点。Oracle须要推动检查点，推动检查点后，就再也不须要它刚填满的在线重作日志文件了。若是须要重用这个重作日志文件，而此时它还依赖于原来的重作日志文件，咱们就会获得一个“检查点未完成”消息，而不惜等待。

能够看到，DBWn的性能可能很重要。若是它写出块的速度不够快，不能很快地释放缓冲区（能够重用来缓存其余块），就会看到Free Buffer Waits和Write Complete Waits的等待数和等待时间开始增加。 

最好的状况下，DBWn使用异步I/O将块写至磁盘。采用异步I/O，DBWn会收集一批要写的块，并把它们交给操做系统。DBWn并不等待操做系统真正将块写出；而是当即返回，并收集下一批要写的块，当操做系统完成写操做时，它会异步地通知DBWn写操做已经完成。这样，与全部工做都串行进行相比，DBWn能够更快地工做。

关于DBWn，还有最后一点说明。根据定义，块写入器会把块写出到全部磁盘，即分散在各个磁盘上；也就是说，DBWn会作大量的分散写（scattered write）。执行一个更新时，你会修改多处存储的索引块，还可能修改随机地分布在磁盘上的数据块。另外一方面，LGWR则是向重作日志完成大量的顺序写（sequential write）。这是一个很重要的区别，Oracle之因此不只有一个重作日志和LGWR进程，还有DBWn进程，其缘由就在于此。分散写比顺序写慢多了。经过在SGA中缓存脏块，并由LGWR进程完成大规模顺序写（可能重建这些脏缓冲区），这样能够提高性能。DBWn在后台完成它的任务（很慢），而LGWR在用户等待时完成本身的任务（这个任务比较快），这样咱们就能获得更好的总体性能。尽管从技术上讲这样会使Oracle执行更多没必要要的I/O（写日志以及写数据文件），但总体性能仍是会提升。从理论上讲，若是提交期间Oracle已经将已修改的块物理地写出到磁盘，就能够跳过写在线重作日志文件。但实际中并非这样：LGWR仍是会把每一个事务的重作信息写至在线重作日志，DBWn则在后台将数据库块刷新输出到磁盘。

LGWR

LGWR（log writer）将日志缓冲区的内容写入到磁盘上的联机日志文件中。将日志缓冲区写入联机重作日志文件的过程一般称为“日志缓冲区转储”。

当会话对数据库缓冲区缓存中的块执行任何更改时，在其将更改应用到块以前，会将要应用的变动向量写入磁盘。为此LGWR将日志缓冲区的内容几乎实时地传输到联机重作日志文件中。当会话发出COMMIT时，LGWR会实时写入：在LGWR将缓冲区写入磁盘时，会话将挂起。只有此时才将事务记录为已经提交（所以是不可逆的）。

 

在如下3种状况下，LGWR将转储日志缓冲区：DBWn要写入脏缓冲区；任何事务发出一个提交时；重作日志缓冲区1/3满。

提交时写入：为了处理COMMIT，服务器进程在日志缓冲区中插入提交记录。在LGWR将缓冲区写入磁盘时，会话将挂起。只有此写操做完成时，才能将提交完成的消息返回给会话，服务器进程才能继续工做。这将确保事务永不丢失：已提交事务的每一个变动向量均可以在磁盘的重作日志上获得，并能够在伺候应用于数据文件备份。所以，若是数据库被破坏，那么能够经过备份进行还原，并且能够重作自备份以来执行的全部工做。

重作日志缓冲区的占用率达到1/3：此时，LGWR会将日志缓冲区转储到磁盘。这与性能相关。若是日志缓冲区较小（一般也应该这样），即便没有回话提交事务，占用率达到1/3的相应触发器将强制LGWR将缓冲区准实时写入磁盘。就大多数应用程序而言，日志缓冲区的优化大小仅为数MB。应用程序将在几分之一秒的时间内生成足以填充1/3的重作内容，所以会强制LGWR将变动向量不断地准实时写入磁盘。此后，当会话发出COMMIT命令时，几乎没有任何要写入的内容：COMMIT命令能够当即完成。

DBWn要将脏缓冲区从数据库缓冲区缓存写入到数据文件中：在执行此操做前，它会通知LGWR将日志缓冲区转储到联机重作日志文件中。这样作能够确保：始终能够反转未提交的事务。此处须要了解，DBWn彻底可能将未提交的事务写入数据文件。只要必定可以得到反转事务所需的撤销数据，这就不成问题。在生成撤销数据时，也会生成变动向量。在更新数据文件前，这些已经在重作日志文件中，若有必要，能够重建回滚事务所需的撤销数据。注意，致使LGWR执行写入的三秒超时是存在的。超时实际上在DBWn上，但因为LGWR老是先于DBWn执行写入，LGWR上也就有了三秒钟的超时。 

CKPT

检查点进程（Checkpoint Process）并不像它的名字所暗示的那样真的创建检查点，创建检查点主要是DBWn的任务。CKPT只是更新数据文件的文件首部，以辅助真正创建检查点的进程（DBWn）。当前检查点位置，是发生实例故障时重作流中必须由此开始的恢复位置。CKPT使用当前检查点位置不断更新控制文件。

MMON

MMON（manageability monitor）是数据库的不少自我监视和自我调整功能的支持进程。此数据库实例收集有关活动和性能的大量统计数据，这些统计数据收集到SGA中，经过发出SQL查询，能够查询它们的当前值。为了调整性能，也为了分析趋势和得到历史报告，有必要将这些统计数据保存到长期存储的地方。MMON从SGA按期捕获统计数据（默认是每小时一次），并将它们写入到数据字典中，能够无限期地存储它们（不过，默认方式是只存储8天）。MMON还持续监视数据库和实例，来肯定是否应该发出任何警报。

MMNL

MMNL（manageability monitor light）是MMON的辅助进程。有时，MMON的预订活动显得不足。例如，MMON根据调度安排将SGA中收集的统计信息转储到数据库中：默认方式下是每小时一次。若是在MMON预约执行转储前，用于收集此信息的内存缓冲区变慢，那么，MMNL将担当起转储数据的职责。

MMAN

MMAN（memory manager）进程支持内存分配的自动管理。DBA仅需为内存使用状况肯定一个整体目标，MMAN将观察PGA内存和SGA内存的须要，并根据须要将内存分配给会话和SGA结构，同时将内存分配总量保持在DBA设定的限制范围内。

LREG

数据库实例尝试用数据库侦听器注册它本身。这就容许用户经过侦听器链接数据库。在高级环境中，例如带有几个实例的群集数据库（提供了许多服务），LREG（listener regulation process）也会用工做负载和性能信息更新侦听器。这样侦听器就能够智能地与合适的实例进行会话。在早期版本中，这个功能由PMON进程实现。在12c版本中，添加了一个专用的进程LREG来实现它。

 

ARCn

 

ARCn（archiver）进程的任务是：当LGWR将在线重作日志文件填满时，就将其复制到另外一个位置。此后这些归档的重作日志文件能够用于完成介质恢复。在线重作日志用于在出线电源故障（实例停止）时“修正”数据文件，而归档重作日志则不一样，它是在出线硬盘故障时用于“修正”数据文件。若是丢失了包含数据文件/d01/oradata/ora11g/system.dbf的磁盘，能够去找上一周的备份，恢复旧的文件副本，并要求在数据库上应用自此次备份以后生成的全部归档和在线重作日志。这样就能使这个数据文件“遇上”数据库中的其余数据文件，因此咱们能够继续处理而不会丢失数据。

 

ARCn一般将在线重作日志文件复制到至少两个位置。这些位置多是本地机器上的磁盘，或者更确切地将，至少有一个位置在另外一台机器上，以应付灾难性的失败。在许多状况下，归档重作日志文件会由另外某个进程复制到一个第三辅存设备上，如磁带。也能够将这些归档重作日志文件发送到另外一台机器上，应用于“备用数据库”（standby database），这是Oracle提供的一个故障转移选项。

RECO

RECO（recoverer process）分布式数据库恢复有一个很中心的任务：因为两段提交（two-phase commit，2PC）期间的崩溃或连接丢失等缘由，有些事务可能会保持准备状态，这个进程就是要恢复这些事务。2PC是一种分布式协议，容许影响多个不一样数据库的修改实现原子提交。它力图在提交以前尽量地关闭分布式失败窗口。若是在N个数据库中间采用2PC，其中一个数据（一般是客户最初登陆的那个数据库，但也不必定）将成为协调器（coodinator）。这个站点会询问其余N-1个站点是否准备提交。实际上，这个站点会转向另外这N-1个站点，问它们是否准备好提交。这N-1个站点都会返回其“准备就绪状态”，报告为YES或NO。若是任何一个站点投票（报告）NO，整个事务都要回滚。若是全部站点都投票YES，站点协调器就会广播一条消息，使这N-1个站点真正完成提交（提交获得持久地存储）。

若是某个站点邮票YES，称其准备好要提交，可是在此以后，而且在获得协调器的指令真正提交以前，网络失败了，或者出现了另外某个错误，事务就会成为一个可疑的分布式事务（in_doubt distributed transaction）。2PC力图限制出现这种状况的时间窗口，可是没法根除这种状况。若是正好在那时（这个时间窗口内）出现一个失败，处理事务的工做就要由RECO负责。RECO会试图联系事务的协调器来发现协调的结果。在此以前，事务会保持未提交状态。当再次到达事务协调器时，RECO可能会提交事务，也可能将事务回滚。

须要说明，若是失败（outrage）持续很长一段时间，并且你有一些很重要的事务，能够自行手动地提交或回滚。有事你可能想要这样作，由于可疑的分布式事务科能致使写入器阻塞读取器（Oracle中只有此时会发生“写阻塞读”的状况）。你的DBA能够通知另外一个数据库的DBA，要求他查询那些可疑事务的状态。而后你的DBA再提交或回滚，而再也不由RECO完成这个任务。