oracle实例进程结构

实例后台进程在启动实例时启动，在终止实例时终止运行。有这样5个后台进程，oracle使用它们历史长久，系统监视器（System Monitor,SMON）、进程监视器（Process Monitor,PMON）、数据库写入器（Database Writer,DBWn）、日志写入器（Log Writer,LGWR）和检查点进程（Checkpoint Process,CKPT）。在更新的产品版本中，引入了其他多个进程，可管理性监视器（Manageability Monitor,MMON）和内存管理器（Memory Manager,MMAN）是其中两个重要的进程。

1.SMON

SMON起初的任务是安装和打开数据库。简单的讲，SMON通过查找和验证数据库控制文件来安装数据库。此后，它通过查找可验证所有数据文件和联机日志文件打开数据库。一旦打开数据库并使数据库处于使用状态后，SMON就负责执行各种内部管理任务，如合并数据文件中的可利用空间。

2.PMON

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

注意：如果会话异常终止，PMON后台进程将回滚活动事务。

3.DBWn

始终注意一点：会话通常并不将数据写入磁盘。会话将数据（或现有数据的更改）写入数据库缓冲区。由数据库写入器负责在随后将缓冲区写入磁盘。一个实例可能有多个数据库写入器（最多不超过20个），依次成为DBW0和DBW1等。因此，使用术语DBWn指代特定的数据库写入器。默认数量是每8个CPU对应一个数据库写入器。

注意：究竟需要多少个数据库写入器？默认数量就很合适，添加多了数据库写入器性能可能会有所提升，但通常需要先考虑调整内存，一般来说，在优化磁盘I/O之前都要问问自己：为什么需要磁盘I/O呢？

DBWn将脏缓冲区从数据库缓冲区缓存写入数据文件中，但也并非缓冲区一旦变脏了，就相应的写入此缓冲区。相反，它会尽可能减少写入缓冲区的数量。通常认为，磁盘I/O会降低性能，因此，除非确有必要，就不要执行磁盘I/O。如果会话已经对缓冲区中的块进行了写操作，那么，该回话或其他会话就有可能再次写入。如果缓冲区近来还会变脏，那么为何要将其写入磁盘呢？DBWn用于选择脏缓冲区来写入磁盘（将清理缓冲区）的算法是：只选择最近未使用的缓冲区。如果由于会话重复执行读写操作，缓冲区处于十分忙碌的状态，DBWn就不会将缓冲区写入磁盘。在DBWn清理缓冲区前，可能有数百条或数千条对缓冲区的写操作。假如一个缓冲区缓存包括100万个缓冲区，其中10万个缓冲区变脏了，但DBWn可能每次直讲数百个缓冲区写入磁盘。可能有这样数百个缓冲区：一段时间来，任何会话都未曾关注过它们。DBWn根据极懒算法执行写入：尽可能少，再尽可能少。 在以下4种情况下，DBWn将执行写操作：没有任何可用缓冲区、脏缓冲区过多、遇到三秒超时和遇到检查点。

首先是没有可用缓冲区的情况。如果服务器进程需要将块复制到数据库缓冲区缓存中，则首先必须查找可用缓冲区。可用缓冲区是指既不脏（更新过，但尚未写回磁盘）也未被占用（即相应时刻正被另一个会话使用）的缓冲区。不能重写脏缓冲区，否则将丢失已更改的数据，也不能重写被占用的缓冲区，因为此操作系统的内存保护机制不允许这么做。如果服务器进程查找可用缓冲区用时过长（具体时限由oracle内部确定），就会通知DBWn将某些脏缓冲区写入磁盘。一旦完成，就会清理缓冲区，从此也就有了可用缓冲区。

第二种情况是脏缓冲区数量过多，究竟何为过多，这是由另一个内部阈值确定的。服务器进程都可以找到可用缓冲区，但总体而言，脏缓冲区数量过多，这将导致DBWn将其中一些缓冲区写入磁盘。

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

第四，可能存在请求的检查点。前面列出的三个原因将导致DBWn将有限数量的脏缓冲区写入数据文件。而当遇到检查点时，会写入所有脏缓冲区。这意味着可能有几十万个脏缓冲区。在检查点期间，磁盘I/O数量将达到顶峰，CPU使用率可能达到100%，最终用户会话的性能将下降。当完成检查点后，性能将恢复到通常的状态。那么，为什么要设置检查点呢？一言蔽之：在不得已时才设置它们。

注意：在提交事务时DBWn什么都不做。

唯一绝对需要检查点的时刻是：关闭了数据库，关闭了实例。检查点将所有脏缓冲区写入磁盘：这就实现了缓冲区缓存与数据文件的同步，实例与数据库的同步。在通常的运行状态下，数据文件始终是过时的：它们缺少多个更改（提交的更改或未提交的更改）。这不会带来问题：因为缓冲区缓存中的数据块副本是最新的，而会话使用的正是这些数据块。在关闭期间，有必要将所有内容写入磁盘。自动检查点只在关闭时出现，但是可使用下面的语句，随时强制设置检查点：

alter system checkpoint;

前面讨论的是完全检查点，更常用的是局部检查点。局部检查点强制DBWn写入仅包含一个或多个数据文件（而不是整个数据库）的块的所有脏缓冲区：在数据文件或有表空间脱机时；在将表空间置入备份模式时；或在将表空间设置为只读时。与完全检查点相比，这些检查点的力度较小，每次在相关事件发生时自动执行。

总之，DBWn按极懒算法执行写入：尽可能少，再尽可能少。但出现检查点的情况例外：将所有脏缓冲区尽快写入磁盘。

4.LGWR

LGWR将日志缓冲区的内容写入到磁盘上的联机日志文件中。将日志缓冲区写入联机重做日志文件的过程通常称为“日志缓冲区转储”。

当会话对数据库缓冲区缓存中的块执行任何更改时，在其将更改应用到块之前，会将要应用的变更向量写出到日志缓冲区中。为了保证不丢失任何工作，必须在最大程度减少延迟的情况下将这些变更向量写入磁盘。为此，LGWR将日志缓冲区的内容几乎实时的传输到联机重做日志文件中。当会话发出commit时，LGWR会实时写入；在LGWR将缓冲区写入磁盘时，会话将挂起。只有此时才将事务记录为已经提交（因此是不可逆的）。

LGWR是oracle体系结构中最大的瓶颈之一。DML的速度不可能超过LGWR将变更向量写入磁盘的速度。在三种情况下，LGWR将转储日志缓冲区：会话发出COMMIT、日志缓冲区占用率达1/3、DBWn要写入脏缓冲区。

第一种情况是提交时写入。为了处理COMMIT，服务器进程在日志缓冲区中插入提交记录。在LGWR将日志缓冲区转储到磁盘之前，将挂起会话。只有此写操作完成时，才能将提交完成的消息返回给会话，服务器进程才能继续工作。这将确保事务永不丢失：已提交事务的每个变更向量都可以在磁盘上的重做日志上得到，并可以在此后应用于数据文件备份。因此，如果数据库被损坏，那么可以通过备份进行还原，而且可以重做自备份以来执行的所有工作。

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

第三张情况是DBWn需要将脏缓冲区从数据库缓冲区缓存写入到数据文件中，在执行此操作前，它会通知LGWR将日志缓冲区转储到联机重做日志文件中。这样做可以确保：始终可以反转未提交的事务。

注意：LGWR会在哪些情况下将日志缓冲区转储到磁盘？会话发出COMMIT时、缓冲区的占用率达到1/3时，DBWn正好要执行写入前。

注意：何时出现完全检查点？只会应请求这么做，或在有序关闭数据库时出现。

注意：默认方式下，MMON每小时收集一次快照并启动ADDM。

5.CKPT

崩溃后必须从重做日志提取与脏缓冲区（出现故障时，尚未由DBWn写入磁盘的缓冲区）对应的所有变更向量，并将其应用于数据库块，这就是恢复过程。频繁的检查点确保：可用将脏缓冲区快速写入磁盘，从而最大程度的减少崩溃发生后必须应用的重做量，最大程度的减少恢复数据库所用的时间。CKPT负责发出普通检查点的信号。从8I开始，DBWn用增量检查点替代了完全检查点。增量检查点机制要求DBWn以固定速率写出脏缓冲区，因此，DBWn和LGWR之间始终有一个可以预见的差距。与早先的完全检查点机制相比，增量检查点有助于获得更平稳的性能，恢复时间也更易于预测。

提示;增量检查点增加的越快，发生故障后恢复的速度就越快。但由于额外的磁盘I/O（DBWn更快的写出脏缓冲区），性能会因此恶化。这是最小化停机时间与最大化性能之间的冲突。

CKPT不再必须发出完全检查点，但是，它必须跟踪重做流中增量检查点的位置，如有必要，将指示DBWn写出一些脏缓冲区，以便使检查点位置前移。当前检查点位置，也称RBA（redo byte address，重做字节地址），是发生实例故障时重做流中必须由此开始的恢复位置。CKPT使用当前检查点位置不断更新控制文件。

6.MMON

MMON（Manageability Monitor）是数据库版本10g引入的进程，是数据库的很多自我监视和自我调整功能的支持进程。

此数据库实例收集有关活动和性能的大量统计数据。这些统计数据收集到SGA中，通过发出SQL查询，可以询问他们的当前值。为了调整性能，也为了分析趋势和获得历史报告，有必要将这些统计数据保存到长期存储的地方。MMON从SGA定期捕获统计数据（默认是每小时一次），并将他们写入到数据字典中，在数据字典中，可以无限期的存储他们（不过默认方式是存储8天）。

每次MMON收集一组统计数据（称为快照）时，它还启动Automatic Database Diagnostic Monitor(ADDM)。ADDM工具使用由多名DBA历经多年开发的专家系统来分析数据库活动。它观察两个快照（默认是当前快照和先前的快照），并得出有关性能的观察结果和建议。除了收集快照外，MMON还持续监视数据库和实例，来确定是否应该发出任何警报。某些警报条件（例如，到达存储空间限制时发出警告）会默认启动，而其他条件由DBA配置。

7.MMNL

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

8.MMAN

MMAN（Memory Manager）进程是在数据库版本10g中引入的。它支持牛才能分配的自动管理。在数据库版本9i之前，oracle环境中的内存管理与人们的期待有很大的落差。与会话服务器进程相关的PGA内存无法转移：服务器进程从操作系统的可用内存池中获得内存，但从不返回内存，即使仅使用一小会也是如此。SGA内存结构固定不变：在启动实例时定义 ，除非关闭或重新启动实例，否则不能改变它。

9i版本改变了这一切：可用伸缩PGA，服务器根据需要为会话分配内存，同时确保分配的PGA内存总量保持在一定的限度之内。其中的SGA和组件（要特别注意，日志缓冲区除外）的大小可以在一定范围内重新设置。10g版本实现了SGA大小重调的自动化：MMAN监视SGA内存结构的需要，并能根据需要重设其大小。

11g版本的内存管理能力更进一步：DBA仅需为内存使用情况确定一个总体目标，MMAN将观察PGA内存和SGA内存的需要，并根据需要将内存分配给会话和SGA结构，同时将内存分配总量保持在DBA设定的限制范围内。

9.ARCn

就数据库而言，这是一个可选的进程，但对于企业来说却通常是必须的。如果没有一个或多个ARCn（Archiver）进程（数量在1-30之间，名为ARC0，ARC1..）就可能会丢失数据。应用于数据块的所有变更向量都写出到日志缓冲区（由执行更改的会话完成）中，然后写出到联机重做日志文件中（由LGWR完成）。联机重做日志文件的大小和数量固定不变。一旦变满，LGWR将用更多的重做数据覆盖它们。在此之前经历的时间与联机日志文件的大小和数量，以及针对数据库的DML活动数量（以及生成的重做数量）相关。这意味着，联机重做日志仅存储最近发生的活动的变更。为了保留一份应用于数据的所有更改的完整历史记录，必须在联机日志文件变满和被重用前制作副本。这正是ARCn的职责。如果这些副本（称为归档重做日志文件）可用，那么无论数据库损坏程度如何，通过还原数据文件备份，并为其应用从备份以来生成的所有归档日志文件中提取的变更向量，都可以恢复数据库。最后使备份达到最新状态的恢复将来自于使用联机重做日志文件中的最新变更向量。

注意：LGWR对联机日志文件中执行写操作，ARCn读取联机日志文件，其他任何进程根本不接触此类文件。

大多数生产环境的事务数据库将在“归档日志模式”下运行，这意味着，ARCn自动启动，而且在ARCn成功将联机日志文件成功归档到归档日志文件前，将不允许LGWR重写相应的联机日志文件。

提示：必须监视ARCn进程的进度及写入目标的状态。如果归档操作失败，数据库最终将会挂起。可以通过警报系统完成监视操作。

10.RECO

分布式事务涉及两个或多个数据库的更新。分布式事务由编程人员设计，并通过数据库链接来实现，请看下面的例子：

update orders set order_status=complete where customer_id=1000;

update orders@mirror set order_status=complete where customer_id=1000;
commit;

第一个更新应用于本地数据库中的行，而第二个更新应用于由数据库链接MIRROR标识的远程数据库的行。

COMMIT命令要求两个数据库提交事务（由两个语句组成）。分布式事务需要两阶段提交。每个数据库中的提交都必须进行协调：如果一个失败了，而另一个要成功了，那么整体看来，数据将处于不一致状态。两阶段提交在准备数据库时，指示其LGWR将日志缓冲区转储到磁盘中（第一阶段），一旦得到确认，就在每处都将事务标记为已提交（第二阶段）。如果在两个阶段之间，在任何位置发生了错误，那么RECO进程（Recoverer Process）将采取措施来取消提交，并回滚所有数据库中的工作。

11.了解在实例中运行的进程

1.作为用户system连接到数据库。

2.确定哪些进程正在运行，以及每个进程的数量有多少：

select program from v$session order by program;

select program from v$process order by program;

这些查询将得到相似结果：每个进程必须有会话（即使后台进程，也同样如此），而每个会话必须有进程。可多次出现的进程将有一个数字后缀，但支持用户会话的除外：他们都使用同一名称。

3.通过计算服务器进程数量（Linux或任何Unix平台上）或oracle线程数量（Windows上），演示会话生成后启动的服务器进程。这两个平台上的技术有所不同，这是因为，在Linux/Unix上，oracle进程是独立的操作系统进程，而在Windows上，它们是一个操作系统进程中的多个线程。

在Windows上，启动任务管理器。对其进行配置，以便显示每个进程中的线程数量：在View菜单中，选择select column选项，然后选中thread count复选框。查看oracle.exe进程，看一下线程数量。如果启动针对此实例的新会话，您将看到，线程数量增加了。退出会话，线程数量又少了。

12.几个关键进程与SGA内存结构的典型交互情况示意图