后台进程介绍

Oracle 实例包括两部分：SGA和 一组后台进程。后台进程执行保证数据库运行所需的实际维护任务。例如，有一个进程为我们维护块缓冲区缓存，根据需要将块写出到数据文件。另一个进程负责当在线重做日志文件写满时将它复制到一个归档目标。另外还有一个进程负责在异常中止进程后完成清理，等等。每个进程都专注于自己的任务，但是会与所有其他进 程协同工作。例如，负责写日志文件的进程填满一个日志后转向下一个日志时，它会通知负责对填满的日志文件进行归档的进程，告诉它有活干了[@more@]

Oracle后台进程

1、 PMON：进程监视器（Process Monitor）

这个进程负责在出现异常中止的连接之后完成清理。例如，如果你的专用服务器“失败”或者出于某种原因被撤销，就要由PMON进程负责修正（恢复或撤销工作），并释放你的资源。PMON会回滚未提交的工作，并释放为失败进程分配的SGA资源。

除了出现异常连接后完成清理外，PMON还负责监视其他的Oracle后台进程，并在必要时（如果可能的话）重启这些后台进程。如果一个共享服务器或调度器失败（崩溃），PMON会介入，并重启另一个共享服务器或调度器（对失败进程完成清理之后）。PMON会查看所有Oracle进程，可能重启这些进程，也可能适当地终止实例。例如，如果数据库日志写入器进程（LGWR）失败，就最好让实例失败。这是一个严重的错误，最安全的做法就是立即终止实例，并根据正常的恢复来修正数据（注意，这是一种很罕见的情况，要立即报告给Oracle Support）。

PMON还会为实例做另一件事，这就是向Oracle TNS监听器注册这个实例。实例启动时，PMON进程会询问公认的端口地址（除非直接指定），来查看是否启动并运行了一个监听器。Oracle使用的公认/默认端口是1521。如果此时监听器在另外某个端口上启动会怎么样呢？在这种情况下，原理是一样的，只不过需要设置LOCAL_LISTENER参数来显式地指定监听器地址。如果数据库实例启动时有监听器在运行，PMON会与这个监听器通信，并向它传递相关的参数，如服务名和实例的负载度量等。如果监听器未启动，PMON则会定期地试图与之联系来注册实例。

2、 SMON：系统监视器（System Monitor）

SMON进程要完成所有“系统级”任务。PMON感兴趣的是单个的进程，而SMON与之不同，它以系统级为出发点，这是一种数据库“垃圾收集器”。SMON所做的工作包括：

q 清理临时空间：原先清理临时空间这样的杂事都要由我们来完成，随着引入了“真正” 的临时表空间，这个负担已经减轻，但并不是说完全不需要清理临时空间。例如，建立一个索引时，创建时为索引分配的区段标记为TEMPORARY。如果出于某种原因CREATE INDEX会话中止了，SMON就要负责清理。其他操作创建的临时区段也要由SMON负责清理。

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

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

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

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

q 收缩回滚段：如果有设置，SMON会自动将回滚段收缩为所设置的最佳大小。

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

从以上介绍你应该对SMON做些什么有所认识了。除此之外，它还会做许多其他的事情，如将DBA_TAB_MONITORING视图中的监视统计信息刷新输出，将SMON_SCN_TIME表中的SCN-时间戳映射信息刷新输出，等等。随着时间的推移，SMON进程可能会累积地占用大量CPU时间，这应该是正常的。SMON会定期地醒来（或者被其他后台进程唤醒），来执行这些维护工作。

3、 RECO：分布式数据库恢复（Distributed Database Recovery）

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

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

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

4、 CKPT：检查点进程（Checkpoint Process）

检查点进程并不像它的名字所暗示的那样真的建立检查点（检查点在第3章介绍重做日志一节中已经讨论过），建立检查点主要是DBWn的任务。CKPT只是更新数据文件的文件首部，以辅助真正建立检查点的进程（DBWn）。以前CKPT是一个可选的进程，但从8.0版本开始，这个进程总会启动，所以，如果你在UNIX上执行一个ps命令，就肯定能看到这个进程。原先，用检查点信息更新数据文件首部的工作是LGWR的任务；不过，一段时间后，随着数据库大小的增加以及文件个数的增加，对LGWR来说，这个额外的工作负担太重了。如果LGWR必须更新数十个、数百个甚至数千个文件，等待提交事务的会话就可能必须等待太长的时间。有了CKPT，这个任务就不用LGWR操心了。

5、 DBWn：数据库块写入器（Database Block Writer）

数据库块写入器（DBWn）是负责将脏块写入磁盘的后台进程。DBWn会写出缓冲区缓存中的脏块，通常是为了在缓存中腾出更多的空间（释放缓冲区来读入其他数据），或者是为了推进检查点（将在线重做日志文件中的位置前移，如果出现失败，Oracle会从这个位置开始读取来恢复实例）。如第3章所述，Oracle切换日志文件时就会标记（建立）一个检查点。Oracle需要推进检查点，推进检查点后，就不再需要它刚填满的在线重做日志文件了。如果需要重用这个重做日志文件，而此时它还依赖于原来的重做日志文件，我们就会得到一个“检查点未完成”消息，而必须等待。

注意 推进日志文件只是导致检查点活动的途径之一。有一些增量检查点由诸如FAST_START_ MTTR_TARGET之类的参数以及导致脏块刷新输出到磁盘的其他触发器控制。

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

可以配置多个DBWn；实际上，可以配置多达20个DBWn（DBW0…DBW9、DBWa…DBWj）。大多数系统都只有一个数据库块写入器，但是更大的多CPU系统可以利用多个块写入器。通常为了保持SGA中的一个大缓冲区缓存“干净” ，将脏的（修改过的）块刷新输出到磁盘，就可以利用多个DBWn来分布工作负载。

最好的情况下，DBWn使用异步I/O将块写至磁盘。采用异步I/O，DBWn会收集一批要写的块，并把它们交给操作系统。DBWn并不等待操作系统真正将块写出；而是立即返回，并收集下一批要写的块。当操作系统完成写操作时，它会异步地通知DBWn写操作已经完成。这样，与所有工作都串行进行相比，DBWn可以更快地工作。在后面的“从属进程”一节中，我们还将介绍如何使用I/O从属进程在不支持异步I/O的平台或配置上模拟异步I/O。

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

6、 LGWR：日志写入器（Log Writer）

LGWR进程负责将SGA中重做日志缓冲区的内容刷新输出到磁盘。如果满足以下某个条件，就会做这个工作：

q 每3秒会刷新输出一次

q 任何事务发出一个提交时

q 重做日志缓冲区1/3满，或者已经包含1 MB的缓冲数据

由于这些原因，分配超大的（数百MB）重做日志缓冲区并不实际，Oracle根本不可能完全使用这个缓冲区。日志会通过顺序写来写至磁盘，而不像DBWn那样必须执行分散I/O。与向文件的各个部分执行多个分散写相比，像这样大批的写会高效得多。这也是使用LGWR和重做日志的主要原因。通过使用顺序I/O，只写出有变化的字节，这会提高效率；尽管可能带来额外的I/O，但相对来讲所提高的效率更为突出。提交时，Oracle可以直接将数据库块写至磁盘，但是这需要对已满的块执行大量分散I/O，而让LGWR顺序地写出所做的修改要比这快得多。

7、 ARCn：归档进程（Archive Process）

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

ARCn通 常将在线重做日志文件复制到至少两个位置（冗余正是不丢失数据的关键所在！）。这些位置可能是本地机器上的磁盘，或者更确切地讲，至少有一个位置在另一台机器上，以应付灾难性的失败。在许多情况下，归档重做日志文件会由另外某个进程复制到一个第三辅存设备上，如磁带。也可以将这些归档重做日志文件发送到另 一台机器上，应用于“备用数据库”（standby database），这是Oracle提供的一个故障转移选项。稍后将讨论其中涉及的进程。

8、 其他中心进程

取决于所用的Oracle特性，可能还会看到其他一些中心进程。这里只是简单地列出这些进程，并提供其功能的简要描述。前面介绍的进程都是必不可少的，如果运行一个Oracle实例，就肯定会有这些进程。以下进程则是可选的，只有在利用了某个特定的特性时才会出现。下面的进程是使用ASM的数据库实例所特有的，见第3章的讨论：

q 自动存储管理后台（Automatic Storage Management Background，ASMB）进程：ASMB进程在使用了ASM的数据库实例中运行。它负责与管理存储的ASM实例通信、向ASM实例提供更新的统计信息，并向ASM实例提供一个“心跳”，让ASM实例知道它还活着，而且仍在运行。

q 重新平衡(Rebalance，RBAL)进程：RBAL进程也在使用了ASM的数据库实例中运行。向ASM磁盘组增加或去除磁盘时，RBAL进程负责处理重新平衡请求（即重新分布负载的请求）。

q 以下进程出现在Oracle RAC 实例中。RAC是一种Oracle配置，即集群中的多个实例可以装载和打开一个数据库，其中每个实例在一个单独的节点上运行（通常节点是一个单独的物理计算机）。这样，你就能有多个实例访问（以一种全读写方式）同样的一组数据库文件。RAC的主要目标有两个：

q 高度可用性：利用Oracle RAC，如果集群中的一个节点/计算机由于软件、硬件或人为错误而失败，其他节点可以继续工作，还可以通过其他节点访问数据库。你也许会丧失一些计算能力，但是不会因此而无法访问数据库。

q 可扩缩性：无需购买更大的机器来处理越来越大的工作负载（这称为垂直扩缩），RAC允许以另一种方式增加资源，即在集群中增加更多的机器（称为水平扩缩）。举例来说，不必把你的 4 CPU机器扩缩为有8个或16个CPU，通过利用RAC，你可以选择增加另外一个相对廉价的4 CPU机器（或多台这样的机器）。

以下进程是RAC环境所特有的，如果不是RAC环境，则看不到这些进程。

q 锁监视器（Lock monitor，LMON）进程：LMON监视集群中的所有实例，检测是否有实例失败。这有利于恢复失败实例持有的全局锁。它还负责在实例离开或加入集群时重新配置锁和其他资源（实例失败时会离开集群，恢复为在线时又会加入集群，或者可能有新实例实时地增加到集群中）。

q 锁管理器守护（Lock manager daemon，LMD）进程：LMD进程为全局缓存服务（保持块缓冲区在实例间一致）处理锁管理器服务请求。它主要作为代理（broker）向一个队列发出资源请求，这个队列由LMSn进程处理。LMD会处理全局死锁的检测/解析，并监视全局环境中的锁超时。

q 锁管理器服务器（Lock manager server，LMSn）进程：前面已经提到，在一个RAC环境中，各个Oracle实例在集群中的不同机器上运行，它们都以一种读写方式访问同样的一组数据库文件。为了达到这个目的，SGA块缓冲区缓存相互之间必须保持一致。这也是 LMSn进程的主要目标之一。在以前版本的Oracle并行服务器（Oracle Parallel Server，OPS）中，这是通过ping实现的。也就是说，如果集群中的一个节点需要块的一个读一致视图，而这个块以一种独占模式被另一个节点锁定，数据的交换就要通过磁盘刷新输出来完成（块被ping）。如果本来只是要读取数据，这个操作（ping）的代价就太昂贵了。现在则不同，利用LMSn，可以在集群的高速连接上通过非常快速的缓存到缓存交换来完成数据交换。每个实例可以有多达10个LMSn进程。

q 锁（Lock，LCK0)进程：这个进程的功能与前面所述的LMD进程非常相似，但是它处理所有全局资源的请求，而不只是数据库块缓冲区的请求。

q 可诊断性守护（Diagnosability daemon，DIAG）进程：DIAG只能用于RAC环境中。它负责监视实例的总体“健康情况”，并捕获处理实例失败时所需的信息。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10455206/viewspace-1037075/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10455206/viewspace-1037075/