LGWR负责redo log buffer的管理――把redo log buffer中的内容写到磁盘的重做日志文件。LGWR把从上一次写磁盘之后又拷贝到缓存的redo条目写到磁盘中。
Redo log buffer是一个循环的buffer。当LGWR把redo条目从redo log buffer写到重做日志文件后,服务器进程将拷贝新的条目覆盖已经写到磁盘的条目。LGWR写的速度要足够快以保证新的redo条目有足够的空间。
LGWR把redo log buffer中一个连续的部分写到磁盘空间,LGWR写如下内容:
― 每3秒写一次
― 当redo log buffer的空间被占用三分之一时
― 当DBWn进程需要将被修改的缓存写到磁盘时
注意:在DBWn写被修改的buffer之前,所有与这个buffer有关的的重做记录都要写到重做日志文件里(writer-ahead协议),如果DBWn发现有一些重做记录没有写到磁盘里,DBWn将调用LGWR进程把这些信息写到磁盘后,DBWn才开始写这些buffer。
LGWR同步的向活动的重做日志文件的组员写信息。如果重做日志文件组中的某个文件被损坏或不可用,LGWR继续向组中的其他文件写信息并且记录一个错误到LGWR的跟踪文件或者系统alert日志。如果组中所有的文件被损坏,或者是因为组没有归档而导致它不可用,LGWR将不能继续工作。
当用户发布COMMIT语句后,LGWR把一条commit记录放到redo log buffer然后立即将这条记录和它相关事务的redo信息写到磁盘。涉及到数据块的更改会等到写效率更高时写到磁盘里。这种机制就叫fast commit。Redo条目的原子信息里包含事务的提交信息,这个信息是事务已经提交的标志。Oracle返回成功的信息给正在提交的事务,即使数据缓冲区中的信息并没有写入磁盘。
注意:有时,如果需要更多的缓存空间时,LGWR会在一个事务提交之前把信息写到磁盘的日志文件里。只有在事务后来提交时这些条目会变成永久的。
当用户提交一个事务时,这个事务被指定一个系统改变号(SCN),SCN在重做日志文件中与事务的重做条目记录在一起。SCNs记录在重做日志文件中因此RAC和分布式系统中的恢复操作才能同步。
在系统活跃时期,LGWR利用组提交来写重做日志文件。例如,假设一个用户提交了一个事务,LGWR需要将事务的redo条目从缓存写到磁盘里,当这件事发生以后,其他用户发布COMMIT语句。然而,LGWR不能写重做日志文件来提交这些事务,直到LGWR完成以前的写操作。在第一个事务的条目写到重做日志文件后,正在等待的事务的整个redo条目表通过一次操作后都写到磁盘里,比单独一条一条的提交要更节省I/O。这样的话,Oracle减少了磁盘I/O,提高了LGWR的性能。如果请求提交的事务持续在一个高比率,那么每次从log buffer cache写到磁盘的条目包含多个commit记录。
Checkpoint Process(CKPT)当一个checkpoint发生时,Oracle需要更新所有数据文件的头部来记录checkpoint的细节。这个动作是由CKPT进程来完成的。CKPT进程不会把数据块写到磁盘里;这个工作是由DBWn来完成的。
由Enterprise Manager中System_Statistics监控显示的DBWR checkpoint数据指示了checkpoint请求完成的次数。
System Monitor Process(SMON)System Monitor Process(SMON)必要的时候在系统启动时执行系统恢复。SMON还负责清理不再使用的临时段和合并字典管理模式表空间中互相连接的空闲扩展。任何由于在实例恢复过程中因为读文件或离线错误被忽略的已结束的事务,SMON在表空间或文件重新上线时恢复这些事务。SMON定期检查系统是否需要他。其他进程也能在需要SMON进程时调用他。
在高可用的系统中,某个实例的SMON进程能执行由于CPU故障或实例故障引起的错误。
Process Monitor Process(PMON)Process monitor process(PMON)在用户进程错误时执行进程恢复。PMON负责清理数据库的buffer cache和释放用户进程使用的资源。例如,PMON重置活动事务表的状态,释放锁,从活动进程列表中移除进程ID。
PMON定期的检查dispatcher和服务器进程的状态,重启其中已经停止运行的进程(不包括被Oracle主动结束的进程)。PMON还像网络监听注册实例和dispatcher进程的信息。
和SMON一样,PMON定期检查系统是否需要他。其他进程也能在需要PMON进程时调用他。
Recoverer Process(RECO)Recoverer process(RECO)是分布式数据库系统中用来解决分别事务错误的后台进程。某个节点的RECO进程自动连接到包含可疑分发事务的数据库。当RECO进程重新与这个数据库系统建立连接后,它会自动解决所有有疑问的事务,移除数据库的pending事务表的相关的行来解决可疑事务的问题。
如果RECO进程连接到远程服务是失败,RECO会自动的在一个时间间隔内重新发起连接,然而,这个重连的等待时间是不断增加的。只有允许分布式事务的实例中才存在RECO进程。并发分布式事务的数量是不受限制的。
Job Queue ProcessesJob queue进程被用来执行批处理。他们允许用户的作业。他们可以看作是数据库实例中调度PL/SQL语句或过程等作业的调度服务。给定一个开始时间和时间间隔,job队列会在下一个时间间隔出现时执行这个Job。
Job queue进程是动态管理的。这种管理模式会使工作队列的客户端在需要时尽可能多的使用更多的job queue process进程。新进程占据的资源在他们空闲时被释放。
动态的作业队列进程能在一个给定的时间间隔内并发的执行大量的作业。用户作业被CJQ进程提交给作业队列执行。
初始化参数JOB_QUEUE_PROCESSES代表了一个实例中能同时运行的最大作业队列进程数。然而,客户端不能认为所有的作业队列进程对作业运行都可用。
注意:仲裁进程在初始化参数JOB_QUEUE_PROCESSES被设置成0时不会启动。
Archiver Processes(ARCn)归档进程在日志切换发生后讲重做日志文件中的内容拷贝到一个设计好的存储设备中去。ARCn在数据库在归档模式和自动归档启用时才存在。
数据库实例最多可以有10个ARCn进程(从ARC0到ARC9)。当系统中ARCn的数量不足以处理当前的负载时LGWR进程会重新启动一个新的ARCn进程。当LGWR进程启动一个新的ARCn进程时会在alert日志中记录这个信息。
如果你能预测系统归档可能产生大量的负载,例如大量的数据加载,你可以通过初始化参数LOG_ARCHIVE_MAX_PROCESSES来指定归档进程的数量。Alter system语句能改变这个参数的值来动态的增加或减少ARCn的数量。然而,你不需要修改这个参数的值,因为系统会根据需要来决定ARCn进程的多少,LGWR会在系统负载需要的情况下自动的启动更多的ARCn进程。
Queue Monitor Processes(QMNnE)Queue Monitor Processes是Oracle流高级队列服务的一个可选后台进程,它用来监控消息队列。你最多可以配置10个队列监控进程。这个进程和作业队列进程一样,他们和其他进程的区别是当这个进程出错时不会发生数据库实例的错误。
其他后台进程Oracle中还可能运行其他的后台进程,他们包括:
MMON进程还执行许多管理有关的后台任务,例如:
MMNL执行频繁的和轻量级的管理任务,例如会话历史的捕捉和度量值的计算。
MMAN用来执行数据库内部的任务。
RBAL在自动存储管理的实例中负责调整活动磁盘组的负载平衡。RBAL在自动存储管理磁盘中负责全局的开放。
ORBn负责在自动存储管理中数据扩展移动的平衡。可能有多个进程,他们分别是ORB0,ORB1甚至更多。
OSMB在自动存储管理的实例中存在。他负责与自动存储管理的实例通信。
跟踪文件和alert日志每个服务器和后台进程都可以写到相应的跟踪文件。当一个进程探测到一个内部错误,他就将错误的详细信息导入到他的跟踪文件里,如果错误信息写到了跟踪文件里,管理员会可以联系oracle支持服务。
所有跟踪文件的名字中都包含产生这个文件的进程的名字。一个例外就是左右队列进程的跟踪文件的名字中不包含作业进程的名字,而是Jnnn。
跟踪文件中还可能包含调整实例或应用的调优指导。在合适的时候后台进程会把这些信息写到跟踪文件里。
每个数据库还包含alert.log。数据库的alert日志是信息和错误的时序日志,它包含下面一些信息:
Oracle使用alert日志文件来保存这些事件的记录,它还会把一些信息显示在控制台。如果一个管理性的操作成功,一个带着时间戳的“completed”信息会写到alert日志文件里。