Oracle_体系架构_后台进程及从进程详解

后台进程包括:

1)Focused Background Processes
2)Utility Background Processes

1)Focused Background Processes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PMON:

1)connection在不正常终止时,pmon负责释放资源，rollback未提交的事务
2)监控后台进程，如果某些后台进程不正常终止，则会重启它（比如dispatcher），或者直接终止实例(比如lgmr终止时)
3)实例启动时，pmon负责注册实例到监听上，当实例启动时，pmon进程会检查默认监听器是否启动，如果使用非默认的监听器，需要设置
local_listener参数。

SMON:
1)clean up临时空间：真正的临时段不需要clean up，但某些操作，比如create index产生的临时段当create index的session不正常终止时，此时需要smon来清理。
2)Coalesces free space：如果使用字典管理表空间，smon负责将连续的空闲extent合并。
3)Recovers transactions active against unavailable files: 这个过程和实例启动时进行的instance crash recovery(自动前滚和回滚)相似，只不过由于实例启动时某些文件无法访问，而实例启动后的某个时间这些文件可以访问时，smon就会对其执行recover;
4)Performs instance recovery of a failed node in RAC: 当rac的某个节点失败时，某个剩余的节点会打开失败节点对应的redo log，进行recover;
5)Cleans up OBJ$: obj$是个底层的数据字典，包括所有的数据库对象信息，很多时候，某些对象被删除时，由smon进程来clean up 该视图;
6)Shrinks rollback segments：如果设置了optimal size参数，smon进程负责执行回滚段的自动收缩
7)"Offlines" rollback segments：当用户offline某个回滚段，但此时该回滚断有active trancsaction，这是回滚段的状态其实是pending offline,而smon进程会定期的检查该回滚段的事务是否完成，完成即将其变为offline
8)还有很多其它任务。

RECO:Distributed Database Recovery

1)reco有个主要工作，就是recover那些两阶段提交的但由于网络或其它原因造成状态为prepared 的挂起事务。
  两阶段提交的概念：
  A 2PC is a distributed protocol that allows for a modification that affects many disparate databases to be committed automically. It attempts to close the window for distributed failure as much as possible before committing. In a 2PC between N databases, one of the databases—typically (but not always) the one the client logged into initially—will be the coordinator. This one site will ask the other
N-1 sites if they are ready to commit. In effect, this one site will go to the N-1 sites and ask them to be prepared to commit. Each of the N-1 sites reports back its “prepared state” as YES or NO. If any one of the sites votes NO, the entire transaction is rolled back. If all sites vote YES,then the site coordinator broadcasts a message to make the commit permanent on each of the N-1 sites.
  关于2pc的中文帖子说明：
  http://flyhorse2k.spaces.live.com/blog/cns!9C7106D3DF7B09DE!178.entry

2)当某些节点反馈yes给事务协调器可以提交时，但事务协调器还未正式发出可以提交的最后指示时，由于网络的原因，这些节点失去了和事务协调节点的联系，此时这些事务就成为了an in-doubt distributed transaction。此时，RECO就负责定期的联系事务协调器，当联系到时，就会提交或者回滚这些事务了。

3)对于某些大的事务，如果使用reco的成本比较高，可以人为的干涉来处理掉这些事务
SQL>  select local_tran_id,global_tran_id,state from dba_2pc_pending;
SQL>  rollback force "";

CKPT: Checkpoint Process

1)CKPT进程不是做checkpoint(A checkpoint is the writing of dirty (modified) blocks from the buffer cache to disk)的,而是在发生checkpoint时，修改数据文件头的。

2)在oracle8以前，CKPT的任务可以由LGWR进程来执行，因此CKPT进程可选，但从8.0开始，CKPT进程是必须的，LGWR也减少了执行负担。

DBWR: Database Block Writer

1)负责将dirty buffer写入到datafile中，目的是腾出sga空间和advance checkpoint
2)Advance checkpoint后，oracle在做instance recover时，就从online redo file的新位置做为起点位置做恢复。
3)当发生log switch时，会出发checkpoint
4)当online log file 需要被重用时，checkpoint还没有做完的话，警告文件里面会有checkpoint note complete的警告
5)如果dbwr的性能低下，我们会发现很多free buffer waits和write complete waits的等待
6)可以配置多个dbwr进程，比如dbw1,dbw2,...dbw9,...dbwj,最多20个，参数为db_writer_processes,这可以利用多个CPU的并行处理功能
7)如果操作系统支持AIO，dbwr就可以不用等待操作系统写完，而继续下一个dbwr请求。
8)如果操作系统不支持AIO，可以利用dbwr slaves来模拟，参数为dbwr_io_slaves


LGWR: Log Writer

1)将redo log buffer写入到redo log file中
2)3s，commit,redo log buffer 1/3满时，都会触发lgwr写
3)因此redo log buffer不需要太大
4)lgwr采用sequenctial地写入，不像dbwr是scatter的写入，因此lgwr的性能要高很多。


ASMB：Automatic Storage Manangement Background

1)当使用ASM存储database file时，启用该进程
2)该进程负责与ASM实例进行通信

RBAL:Reblance

1)当使用ASM存储database file时，启用该进程
2)该进程负责当从ASM disk group中增加或减少disk时，rebalance数据。

LMON:Lock monitor

1)RAC下的进程
2)负责监控RAC集群中的实例是否fail
3)当RAC中实例增加或减少时，负责重新配置lock和其他资源

LMD:Lock mananger daemon

1)RAC下的进程
2)将global cache service(keep he block buffer consistent between instances)的锁请求发送给LMSn控制的队列中

LMSn:Lock manager server

1)RAC下的进程
2)主要目的是通过cache-to-cache的方式，保证gloabal cache service
3)每个Instance可以配置最多10g LMSn

LCK0:Lock

1)RAC下的进程
2)作用和LMD类似，但它不仅处理data block buffer的请求，也处理其它的global resource

DIAG:Diagnosability daemon

1)RAC下的进程
2)监控各个实例是否health，并且在发生fail时，进行capture


2)Utility Background Processes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CJQ0 and Jnnn Processes:Job Queue

1)当配置job_queue_processes时，会有Jnnn和CJQ0进程
2)Jnnn进程最多可有1000个
3)Jnnn进程在job之间是共享的，但同时每个Jnnn只能执行一个job，并且它使用的内存是在UGA中
4)物化试图的刷新一般要用到job
5)streams一般用到AQ
6)CJQ0，做为jnnn的coordinator，它来控制jnnn的启动和关闭
7)Jnnn进程只会在有job需要处理时才会启动

QMNC and Qnnn Processes:Job Queue

1)用于AQ功能
2)Qnnn处理每个message queue,QMNC做为Qnnn的coordinator
3)如果配置了aq_tm_processes，就会启动QMNC和Qnnn进程,不论有没有queue要处理，Qnnn都会全部启动

EMNn:Event Monitor Processes

1)用于AQ功能
2)用于监控queue,向订购者反馈消息


MMAN:Memory Manager

1)当使用自动管理内存功能时，MMAN负责处理sga各组件的内存动态分配，包括有default buffer pool,shared pool,java pool,large pool.


MMON,MMNL,Mnnn:Manageability Monitors

1)用于AWR(autmatic workload repository)
2)MMNL负责将SGA中的统计信息写入到表中
3)MMON监控数据库性能，进行自动调优
4)Mnnn属于MMON的帮手，帮助进行调优工作


CTWR:Change Tracking Processes

1)负责维护new change tracking file

RVWR:Recovery Writer

1)负责维护flash recovery area中的before images数据


还有一些其他的utility process,比如为dataguard服务的，为streams服务的，为data pump服务的等等......



从进程包括:

1)I/O slaves
2)Parallel query Slaves


I/O Slaves

1)如果操作系统不支持AIO,可以利用io slaves模拟aio
2)backup_tape_io_slaves为rman服务，设置为true的话，rman会根据需要自动启动一些slaves来完成与tape的相关读写操作
3)dbwr_io_slaves为dbwr使用，当设置dbwr_io_slave大于0时，lgwr和arch会使用他们自己的slaves(最多4个)
4)dbwr的从进程为I1nn,lgwr的从进程为I2nn

Parallel Query Slaves

1)当执行某些语句时，会产生很多执行计划，这些执行其实可以并行执行，然后合并成一个输出结果
2)可以利用并行查询功能来实现并行
3)产生的并行查询进程名为Pnnn