oracle服务器进程解析.doc

Oracle进程：【1】：后台进程：是oracle的程序，用来管理数据库的读写，恢复和监控等工作，维护和保障数据库的正常运行；$ ps -ef | grep ora_Sql select name,description from v$bgprocess where paddr!=00;DBWN=数据库写入进程- DBWN:通过LRU算法管理数据缓冲区，将修改后的dirty缓冲区数据写入数据文件，维护数据缓冲区的clean，以便用户进程总能找到足够的空闲缓冲区，通过延迟写数据来优化磁盘I/O读写；LGWR=日志写入进程-LGWR:管理日志缓冲区，将数据库的更改写入日志文件，以便维护数据的一致性，为数据丢失后进行恢复提供依据，通过延迟写日志来优化磁盘I/O读写；ARCH=归档进程-管理redolog日志文件，归档保存因循环复写而将被覆盖的日志文件，为数据丢失后进行恢复提供依据；SMON=系统监控进程- 负责对数据库进行恢复操作，若上次数据库为非正常关闭则下次启动时 会自动读取重做日志文件，对数据库进行恢复，同时还负责在临时段或临时表空间中回收不再使用的存储空间，将各个表空间中的空闲碎片进行合并；PMON=进程监控进程-在用户进程出现故障时进行恢复，清除失效的用户进程，负责清理内存区域和释放该进程所使用的资源，同时监控oracle所以后台进程；RECO=恢复进程-负责自动解决分布式事物中的故障；SQLselect server,count(*) from v$session group by server ;(查询当期服务器运行模式)CKPT=检查点进程-什么是checkpoint在数据库系统中，写日志和写数据文件是数据库中IO消耗最大的两种操作，在这两种操作中写数据文件属于分散写，写日志文件是顺序写，因此为了保证数据库的性能，通常数据库都是保证在提交（commit）完成之前要先保证日志都被写入到日志文件中，而脏数据块着保存在数据缓存（buffer cache）中再不定期的分批写入到数据文件中。也就是说日志写入和提交操作是同步的，而数据写入和提交操作是不同步的。这样就存在一个问题，当一个数据库崩溃的时候并不能保证缓存里面的脏数据全部写入到数据文件中，这样在实例启动的时候就要使用日志文件进行恢复操作，将数据库恢复到崩溃之前的状态，保证数据的一致性。检查点是这个过程中的重要机制，通过它来确定，恢复时哪些重做日志应该被扫描并应用于恢复。一般所说的checkpoint是一个数据库事件（event），checkpoint事件由checkpoint进程（LGWR/CKPT进程）发出，当checkpoint事件发生时DBWn会将脏块写入到磁盘中，同时数据文件和控制文件的文件头也会被更新以记录checkpoint信息。checkpoint的作用checkpoint主要2个作用：1. 保证数据库的一致性，这是指将脏数据写入到硬盘，保证内存和硬盘上的数据是一样的；2. 缩短实例恢复的时间，实例恢复要把实例异常关闭前没有写出到硬盘的脏数据通过日志进行恢复。如果脏块过多，实例恢复的时间也会很长，检查点的发生可以减少脏块的数量，从而提高实例恢复的时间。通俗的说checkpoint就像word的自动保存一样。检查点分类 完全检查点（Normal checkpoint） 增量检查点（Incremental checkpoint）checkpoint相关概念术语在说明checkpoint工作原理之前我们先了解一些相关的术语。RBA（Redo Byte Address）, Low RBA（LRBA）, High RBA（HRBA）RBA就是重做日志块（redo log block）的地址，相当与数据文件中的ROWID，通过这个地址来定位重做日志块。RBA由三个部分组成：1. 日志文件序列号（4字节）2. 日志文件块编号（4字节）3. 重做日志记录在日志块中的起始偏移字节数（2字节）通常使用RBA的形式有：LRBA数据缓存（buffer cache）中一个脏块第一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为LRBA。HRBA数据缓存（buffer cache）中一个脏块最近一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为HRBA。checkpoint RBA当一个checkpoint事件发生的时候，checkpoint进程会记录下当时所写的重做日志块的地址即RBA，此时记录的RBA被称为checkpoint RBA。从上一个checkpoint RBA到当前的checkpoint RBA之间的日志所保护的buffer cache中的脏块接下来将会被写入到数据文件当中去。Buffer checkpoint Queues （BCQ）Oracle将所有在数据缓存中被修改的脏块按照LRBA顺序的组成一个checkpoint队列，这个队列主要记录了buffer cache第一次发生变化的时间顺序，然后有DBWn进程根据checkpoint队列顺序将脏块写入到数据文件中，这样保证了先发生变更的buffer能先被写入到数据文件中。BCQ的引入是为了支持增量checkpoint的。Active checkpoint Queue （ACQ）ACQ中包含了所有活动的checkpoint请求。每次有新checkpoint请求是都会在ACQ中增加一条记录，ACQ记录中包含了相应的checkpoint RBA。checkpoint完成以后相应的记录将被移出队列。完全检查点 （normal checkpoint）完全检查点工作过程一个checkpoint操作可以分成三个不同的阶段： 第一阶段，checkpoint进程开始一个checkpoint事件，并记录下checkpoint RBA，这个通常是当前的RBA。 第二阶段，checkpoint进程通知DBWn进程将所有checkpoint RBA之前的buffer cache里面的脏块写入磁盘。 确定脏块都被写入磁盘以后进入到第三阶段，checkpoint进程将checkpoint信息（SCN）写入/更新数据文件和控制文件中。更新SCN的操作由CKPT进程完成，在Oracle 8.0之后CKPT进程默认是被启用的，如果CKPT进程没有启用的话那相应的操作将由LGWR进程完成。什么时候发生normal checkpoint下面这些操作将会触发checkpoint事件： 日志切换，通过ALTER SYSTEM SWITCH LOGFILE。 DBA发出checkpoint命令，通过ALTER SYSTEM checkpoint。 对数据文件进行热备时，针对该数据文件的checkpoint也会进行，ALTER TABLESPACE TS_NAME BEGIN BACKUP/END BACKUP。 当运行ALTER TABLESPACE/DATAFILE READ ONLY的时候。 SHUTDOWN命令发出时。特别注意：1. 日志切换会导致checkpoint事件发生，但是checkpoint发生却不会导致日志切换。2. 日志切换checkpoint是一个数据库事件，它将已修改的数据从高速缓存刷新到磁盘，并更新控制文件和数据文件。我们知道了checkpoint会刷新脏数据，但什么时候会发生checkpoint呢？以下几种情况会触发checkpoint。1.当发生日志组切换的时候2.当符合LOG_CHECKPOINT_TIMEOUT，LOG_CHECKPOINT_INTERVAL，fast_start_io_target,fast_start_mttr_target参数设置的时候3.当运行ALTER SYSTEM SWITCH LOGFILE的时候4.当运行ALTER SYSTEM CHECKPOINT的时候5.当运行alter tablespace XXX begin backup，end backup的时候6.当运行alter tablespace ,datafile offline的时候;增量checkpoint增量checkpoint工作过程因为每次完全的checkpoint都需要把buffer cache所有的脏块都写入到数据文件中，这样就是产生一个很大的IO消耗，频繁的完全checkpoint操作很对系统的性能有很大的影响，为此Oracle引入的增量checkpoint的概念，buffer cache中的脏块将会按照BCQ队列的顺序持续不断的被写入到磁盘当中，同时CKPT进程将会每3秒中检查DBWn的写入进度并将相应的RBA信息记录到控制文件中。有了增量checkpoint之后在进行实例恢复的时候就不需要再从崩溃前的那个完全checkpoint开始应用重做日志了，只需要从控制文件中记录的RBA开始进行恢复操作，这样能节省恢复的时间。发生增量checkpoint的先决条件 恢复需求设定 （FAST_START_IO_TARGET/FAST_START_MTTR_TARGET） LOG_checkpoint_INTERVAL参数值 LOG_checkpoint_TIMEOUT参数值 最小的日志文件大小 buffer cache中的脏块的数量增量checkpoint的特点 增量checkpoint是一个持续活动的checkpoint。 没有checkpoint RBA，因为这个checkpoint是一直都在进行的，所以不存在normal checkpoint里面涉及的checkpoint RBA的概念。 checkpoint advanced in memory only 增量checkpoint所完成的RBA信息被记录在控制文件中。 增量checkpoint可以减少实例恢复时间。增量checkpoint相关参数设置log_checkpoint_interval设定两次checkpoint之间重做日志块（重做日志块和系统数据块是一样的）数，当重做日志块数量达到设定值的时候将触发checkpoint。log_checkpoint_timeoutSql alter system set log_checkpoint_timeout=60;设定两次checkpoint之间的间隔时间，当超时值达到时增量checkpoint将被触发。Oracle建议不用这个参数来控制，因为事务（transaction）大小不是按时间等量分布的。将此值设置成0时将禁用此项设置。fast_start_io_target因为log_checkpoint_interval主要看的时候重做日志块的数量，并不能反应buffer cache中脏数据块的修改，因此Oracle又引入了这个参数来实现当脏数据块达到一定数量的时候触发checkpoint，不过此参数实际上控制的是恢复时所需IO的数量。fast_start_mttr_target 此参数是在9i中引入用来代替前面的三个参数的，它定义了数据块崩溃后所需要的实例恢复的时间，Oracle在实际上内在的解释成两个参数:fast_start_io_target和log_checkpoint_interval.如果这两个参数没有显式的指定,计算值将生效.。 fast_start_mttr_target可以设定的最大值是3600，即一个小时。它的最小值没有设限，但是并不是说可以设置一个任意小的值，这个值会受最小dirty buffer（最小为1000）的限制，同时还会受初始化时间以及文件打开时间的限制。 在设置此参数的时候要综合考虑系统的IO，容量以及CPU等信息，要在系统性能和故障恢复时间之间做好平衡。 将此参数设置成0时将禁用 fast-start checkpointing，这样能见效系统负载但同时会增加系统的恢复时间。 如果fast_start_io_target or log_checkpoint_interval被指定，他们会自动覆盖由fast_start_mttr_target参数计算出来的值。在10g中，数据库能根据各种系统参数的设置值来自动调整检查点的执行频率，以获得最好的恢复时间以及系统的正常运行影响最小。通过自动checkpoint调整，Orach能在系统低IO操作的时候将脏块写入到数据文件中，因此即时DBA没有设置checkpoint相关的参数值或是设置了一个不合理的值的时候系统还是能获得一个很合理的系统恢复时间。10g中的增量checkpoint更能体现它持续活动的特点，在10g中，增量checkpoint不是在某一个特定的条件下触发，而是由数据库根据系统参数设置自动触发。与完全checkpoint的区别 完全checkpoint会将checkpoint的信息写入到控制文件以及数据文件头中 增量checkpoint只会将RBA信息写入到控制文件中。查看系统的checkpoint动作我们可以通过将LOG_checkpointS_TO_ALERT设置成TRUE来打开checkpoint的trace，这样就可以跟踪checkpoint的操作了。ALTERSYSTEMSETLOG_checkpointS_TO_ALERT=TRUE;这设置以后系统的checkpoint将会被记录alert_$SID.log文件中。Sql select current_scn from v$database; 查看系统当前最新scn时间点Sql select checkpoint_change# from v$database;查看控制文件最后被更新scnSql select checkpoint_change# from v$datafile_header;查看数据文件最后被更新scnSql alter system set log_checkpoints_to_alert=true;准备跟踪检查点触发信息$ tail -f /u01/app/oracle/admin/ora10/bdump/alert_ora10.log;在V$DATAFILE_HEADER里面也保存了发生完全checkpoint的时候一些相关信息，包括checkpoint发生时间、对应SCN已经checkpoint的次数。selectfile# NO, status, tablespace_name, name, dbms_flashback.get_system_change_number CUR_SCN,to_char（resetlogs_time,YYYY-MM-DD HH24:MI:SS）RST_DT,resetlogs_change# RST_SCN,to_char（checkpoint_time,YYYY-MM-DD HH24:MI:SS）CKPT_DT,checkpoint_change# CKPT_SCN, checkpoint_count CKPT_CNTfromv$datafile_header;完全检查点- 我们先执行一个ALTERSYSTEMcheckpoint;- 下面是alert文件中的数据结果MonAug422:22:082008BeginningglobalcheckpointuptoRBA0x8.c9d4.10,SCN:533714CompletedcheckpointuptoRBA0x8.c9d4.10,SCN:533714- 我们能看到完全checkpoint发生的SCN 533714- 下面我们再对照下V$DATAFILE_HEADER中的结果NOSTATUSTABLESPACE_NAMECUR_SCNRST_DTRST_SCNCKPT_DTCKPT_SCNCKPT_CNT- - - - - - - - -1ONLINESYSTEM5337902008-01-1216:51:534460752008-08-0422:22:08533714662ONLINEUNDOTB01-1216:51:534460752008-08-0422:22:08533714293ONLINESYSAUX5337902008-01-1216:51:534460752008-08-0422:22:08533714664ONLINEUSERS5337902008-01-1216:51:534460752008-08-0422:22:08533714655ONLINEEXAMPLE5337902008-01-1216:51:534460752008-08-0422:22:0853371425- 看到了么，checkpoint时间和checkpoint的SCN已经被记录到数据文件头中了。日志切换时的检查点- 我们先做一次日志切换ALTERSYSTEMSWITCHLOGFILE;- 然后看看alert里面的记录MonAug422:31:392008BeginninglogswitchcheckpointuptoRBA0x9.2.10,SCN:534450Thread1advancedtologsequence9Currentlog# 2 seq# 9 mem# 0: /u/app/oracle/oradata/orcl/redo02.logMonAug422:35:582008CompletedcheckpointuptoRBA0x9.2.10,SCN:534450- 我们能看到checkpoint是在过了一段时间（这里是4分钟）之后才完成的- 接着我们来看下V$DATAFILE_HEADER中的结果NOSTATUSTABLESPACE_NAMECUR_SCNRST_DTRST_SCNCKPT_DTCKPT_SCNCKPT_CNT- - - - - - - - -1ONLINESYSTEM5347702008-01-1216:51:534460752008-08-0422:31:44534450672ONLINEUNDOTB01-1216:51:534460752008-08-0422:31:44534450303ONLINESYSAUX5347702008-01-1216:51:534460752008-08-0422:31:44534450674ONLINEUSERS5347702008-01-1216:51:534460752008-08-0422:31:44534450665ONLINEEXAMPLE5347702008-01-1216:51:534460752008-08-0422:31:4453445026- 在这里我们能发现下V$DATAFILE_HEADER里面记录的SCN和日志切换发生的checkpoint的SCN是一样的，- 这就证明了日志切换是会更新数据文件头的，同时日志切换的checkpoint是一个级别比较低的操作，- 它不会立即完成，这也是出于性能上考虑的。增量checkpoint查看当前所知只有在LOG_checkpoint_TIMEOUT设置了非0值之后触发的增量checkpoint会在alert文件中有记录，其他条件触发的增量checkpoint都不会记录在alert文件中。- 下面是当LOG_checkpoint_TIMEOUT设置为1800s的时候所产生的增量checkpoint记录Sun Aug3 19:08:56 2008Incremental checkpoint up to RBA 0x8.e17.0, current log tail at RBA 0x8.1056.0Sun Aug3 19:39:00 2008Incremental checkpoint up to RBA 0x8.1be0.0, current log tail at RBA 0x8.1c6e.0Sun Aug3 20:09:04 2008Incremental checkpoint up to RBA 0x8.2af5.0, current log tail at RBA 0x8.2b6a.0Sun Aug3 20:39:07 2008Incremental checkpoint up to RBA 0x8.3798.0, current log tail at RBA 0x8.3851.0Sun Aug3 21:09:10 2008Incremental checkpoint up to RBA 0x8.47b9.0, current log tail at RBA 0x8.48bb.0Sun Aug3 21:39:14 2008Incremental checkpoint up to RBA 0x8.548d.0, current log tail at RBA 0x8.5522.0Mon Aug4 21:05:18 2008查看fast_start_mttr_target通过查看V$INSTANCE_RECOVERY动态性能视图可以查看一些MTTR相关的信息。SELECT TARGET_MTTR,ESTIMATED_MTTR,CKPT_BLOCK_WRITES,CKPT_BLOCK_WRITES FROM V$INSTANCE_RECOVERYTARGET_MTTR用户设置的参数FAST_START_MTTR_TARGET的值.ESTIMATED_MTTR根据目前脏块数目和日志块数目,评估的现在进行恢复所需要的时间.CKPT_BLOCK_WRITES检查点写完的块数目.CKPT_BLOCK_WRITES额外的因为检查点引起的数据库写入操作 （因为不必要的检查点的产生,设置一个非常小的系统恢复时间将会对性能产生负面影响,为了帮助管理员监测这个参数设置较小时对数据库的影响,这个视图显示了这个列）相关视图V$视图V$DATAFILE_HEADER查看数据文件的完全checkpoint信息。V$INSTANCE_RECOVERY查看fast_start_mttr_target设置以及系统MTTR相关信息。X$视图X$BH用于查看脏块的LRBA和HRBA（There is also a recovery RBA which is used to record the progress of partial block recovery by PMON.） 。X$TARGETRBA查看增量checkpoint RBA，target RBA和on-disk RBA。X$KCCCP这里面也有增量checkpoint RBA，target RBA的信息。X$KCCRT完全checkpoint（full thread checkpoint）RBA信息。补充说明写完这篇文章之后又看了写在itpub上的讨论，更新下观点。(/viewthread.php?tid=1053847)关于增量checkpoint和完全的checkpoint的区别这方面的争论里来不少，特别是对于日志切换到底是增量还是完全的争论更是如此，但是其实翻遍Oracle的文档就没有发现有提到增量checkpoint(incremental checkpoint)或是完全checkpoint(full checkpoint)这两个概念。我的观点是根本就没有必要可以的区分是增量还是完全，真正要理解的是不同情况下的checkpoint都会有些什么样的行为，然后根据这些行为来对数据库进行配置，设置相应的参数，制定相应的备份/恢复策略，就此而已。下面列出写常见的checkpoint行为：1. 类似于alter system checkpoint这样的语句所产生的，先记录下当前的scn，然后推动DBWn进程去写脏数据，当写到所记录的scn时候检查点结束，然后ckpt进程将记录的scn写入到控制文件和数据文件头。2. 设置参数log_checkpoint_timeout之后产生的，在超时值达到的时候，ckpt进程记录当时DBWn写脏数据的进度，也就是写到那个scn了，此时检查点信息只记录到控制文件中，同时如果设置了LOG_checkpointS_TO_ALERT的话我们会在alert中得到这样的信息：Sun Aug3 19:08:56 2008Incremental checkpoint up to RBA 0x8.e17.0, current log tail at RBA 0x8.1056.03. ckpt进程每3s起来一次记录checkpoint的进度到控制文件中，这种情况跟上面的类似，只不过在alert里面是看不到的，而且也不是每次唤醒都会写控制文件的，而是有就记，没有就拉倒。4. 类似于alter system switch logfile所产生的，先记录下发出命令时刻的scn，ckpt进程不会推动DBWn去写脏数据，而是让DBWn按照自己的状态去写脏数据，等到写到记录的scn时，chpt进程再去更新控制文件和数据文件头。这种情况在alert也能看到信息：Mon Aug4 22:31:39 2008Beginning log switch checkpoint up to RBA 0x9.2.10, SCN: 534450Thread 1 advanced to log sequence 9Current log# 2 seq# 9 mem# 0: /u/app/oracle/oradata/orcl/redo02.logMon Aug4 22:35:58 2008Completed checkpoint up to RBA 0x9.2.10, SCN: 534450问题：假如DBWR在写脏数据块的过程中，突然发生实例崩溃时，该怎么办？我们知道，用户提交时，Oracle不一定会把提交的数据块写入到数据文件的。那么实例崩溃时，必然有一些已经提交但是还没来得及写入数据文件的内存数据块。当实例再次启动时，Oracle就需要利用重做日志文件中记录的重做条目在buffer cache中重新构造出被丢失的数据块，从而完成前滚和回滚的工作，并将丢失的数据块找回来。于是这里有一个问题，就是Oracle在重做日志文件中找重做条目时，到底应该找哪些重做条目？换句话说，应该在重做日志文件中从哪个起点开始往后应用重做条目？为了解决这个问题，Oracle在数据库正常运行过程中，会不断地定位这个起点，以便在不可预期的实例崩溃中能够最有效地保护并恢复数据。同时，这个起点的选择非常哟讲究。首先，这个起点不能太靠近日志文件的头部，太靠近日志文件的头部以为着要处理很多的重做条目，这样会导致实例再次启动时所进行恢复的时间太长；其次，这个起点也不能太靠近日志文件的尾部，太靠近日志文件的尾部说明只有很少的脏数据块没有被写入数据文件，也就是说前面已经有很多脏数据块被写入数据文件，那也就意味着只有在DBWn进程很频繁地写数据文件的情况下，才能使得buffer cache中所残留的脏数据块的数量很少。但很明显，DBWn 写得越频繁，那么所占用写数据文件的I/O就越严重，那么留给其他操作的I/O资源就越少。综上所述，在日志文件中位于这个起点之前的重做条目所对应的再buffer cache中的脏数据块已经被写入数据文件中，从而在实例崩溃以后的恢复中不需要去考虑。而这个起点之后的重做条目所对应的脏数据块还没有被写到数据文件，如果在实例崩溃以后的恢复中，需要从这个起点开始往后，依次取出日志文件中的重做条目进行恢复。从而引入了CKPT（检查点进程）的后台进程。CKPT与DBWn共同合作，从而确定这个起点。同时，这个起点也有一个专门的名字叫做检查点位置（这个检查点位置记录在控制文件中，由SMON读取，这个SMON每次在实例启动时，自动启动，检出是否需要恢复）。Oracle引入了检查点队列，该队列上串起来的都是脏数据块所对应的buffer header。而每次DBWn写脏数据块是，也是从检查点队列上扫描脏数据块，并将这些脏数据块实际写入数据文件中的。当写完以后，DBWn会将这些已经写入数文件的脏数据块从检查点队列上摘下来。这样即便是在巨大的buffer cache下工作，CKPT也能偶快速的确定哪些脏数据块已经被写入数据文件，而哪些还没有写入数据文件，显然，只要在检查点队列上的数据块都是还没有写入数据文件的脏数据块。而且，为了更加有效的处理单实例和多实例（RAC）环境下表空间的检查点处理，比如将表空间设置为离线转台或者为热备份状态灯。Oracle还专门引入了文件队列。文件队列的原理与检查点队列是一样的，只不过每个数据文件会有一个文件队列，该数据文件锁对应的脏数据块会被串在同一个文件队列上；同时为了能够尽量减少实例崩溃后的恢复时间，Oracle还引入了增量检查点，从而增加了检查点启动的次数。如果每次检查点启动的间隔时间过长的话，再加上内存很大，可能会使得恢复的时间过长。因为前一次检查点启动后，标识出了这个起点。然后再第二次检查点启动之前，DBWn可能已经将很多脏数据块已经写入了数据文件，而假如在第二次检查点启动之前发生实例崩溃，导致在日志文件中，所标识的起点仍然是上一次检查点启动时所标识的，导致Oracle不知道这个起点以后的很多重做条目所对应的脏数据块实际上已经写入数据文件，从而使得Oracle在实例恢复时重复地处理一遍。由于Oracle中LGWR和DBWR工作的不一致，Oracle引入了检查点的概念，用于同步数据库，保证数据库的一致性。在Oracle里面，检查点分为两种：完全检查点和增量检查点。下面我们分别介绍这两种检查点的作用：ITPUB个人空间 O a ?%w H/S6| C n r01、完全检查点m m-l | g Z%O/h0ITPUB个人空间+A3 J0H q S c)J在Oracle8i之前，数据库的发生的检查点都是完全检查点。完全检查点会将数据缓冲区里面所有的脏数据块写入相应的数据文件中，同时将最新的checkpoint scn更新到所有的数据文件头部及控制文件。保证数据库的处于一致的状态。需要注意的是，完全检查点产生的时候，CKPT并不是把当前完全检查点发生那一时刻的SCN更新到控制文件和数据文件头，而是将这个触发检查点时刻DBWn当前刚写完 dirty buffer对应的SCN更新到控制文件和数据文件头，也就是说，更新控制文件和数据文件头的SCN是滞后于完全检查点的发生那一时刻的SCN的，这个从恢复的原理也很容易理解，因为检查点发生的时候要写入dirty buffer还没有写入，自然不能立即更新成当前的SCN了。需要注意的是, 在oracle8之前，由于没有chekpoint queue，也没有增量检查点的概念，发生完全检查点时，DBWn会以一种无序的方式将所有的 dirty buffer写出到数据文件，这个时候Oracle会冻结所有DML操作等候所有dirty buffer被写出，巨大的IO往往会影响到数据库的性能。后来随着Oracle数据库的发展和buffer cache的不断增大，oracle 意识到这个单一的Full checkpoint机制已经不能满足需要，所以在Oracle 8i后提出增量检查点的概念，建立了checkpoint queue ，让dirty buffer header根据首次变化时候的顺序(LRBA)排列在queue里面。 这样DBWn只要顺着queue的顺序写，而其他进程不必等候dbwr的写完成就可以继续。 因此增量检查点的概念就由此产生了。x y&y T m #L a/Q0ITPUB个人空间 s-#L L 1y G /s完全检查点在8i之后只有在下列两种情况下才会发生：ITPUB个人空间 X.4W m S Z Z M X f L L _/P:0DBA手工执行alter system checkpoint的命令；ITPUB个人空间 A0Q/!U-_5E&j Z W u0数据库正常shutdown (immediate,transcational,normal)。1n6R s n-A8k v0t$ K X0T0ITPUB个人空间6*| A2f ITPUB个人空间 i G+l t2、增量检查点ITPUB个人空间,d r ;K(H l K: c S#c j6w$U Z H3f0说白了，就是+r Z5w E w%Y,U0ITPUB个人空间-z p-? u+f _CKPT每3秒一次的检查DBWn写进度并在控制文件中记录检查点位置(checkpoint position)和更新heartbeat信息9r z x I:!v ? r0ITPUB个人空间!y.e Q%l k P以及o Q7? Q)s*Z0ITPUB个人空间 W6G N P3x l c Y!b s gCKPT定期触发DBWn去写checkpoint queue中的脏数据+B-R W)X 5Y j0ITPUB个人空间,N |:k n*M V o U G-s这两项操作合一起被称为增量检查点。 -可能这块描述的过于笼统，大家继续往下看:-)ITPUB个人空间33C/ 9DITPUB个人空间 L6K r8 h c我们都知道被修改过的数据块，在oracle中都被统称为脏数据块(dirty buffer)。所有的脏块被一个链表串起来,称做检查点队列(checkpoint queue)。在buffer cache中,每一个块都有一个buffer header简称BH, 在BH中有一个ckptq项, 此项目中记录了指向检查点队列上一个块和下一个块的指针。 如果某一个块不在检查点队列中,他的ckptq项为空.通过ckptq项oracle将所有的脏块串成了一个双向链表。这个双向链表就是检查点队列了。B K&c 7y6A O02 C,a)s Y0Oracle 从8i开始引入了检查点队列(checkpoint queue)的概念，用于记录数据库里面当前所有的dirty buffer的信息，这些dirty buffer的信息按被修改的时间先后存放在checkpoint queue里面(当块首次被更改时，块会立即被加进检查点队列)，所涉及的条目主要包含RBA (Redo Block Address，重做日志里面用于标识事务期间数据块在重做日志里面发生更改的编号)和数据块的数据文件号和块号。f3h s$!V6N J Hg0-V c*#z N0不论数据块(buffer)更改几次，它在checkpoint queue里面的位置始终保持不变，checkpoint queue也只会记录它最早的RBA(这个最早的RBA其实就是Low RBA，也就是数据块第一次被修改时所对应的RBA)，从而保证最早更改的数据块能够尽快从内存写入数据文件。DBWR每到一定的时机，就会被触发 (DBWn并不是只有当检查点发生的时候才写，它大约有10几种条件触发写操作)，沿着检查点队列的顺序刷新脏块，同时CKPT进程，会监控着检查点队列的长度，当检查点队列的长度达到一定限制时(具体有几个参数来确定checkpoing queue的长度，下面会提到比如log_checkpoint_timeout,fast_start_mttr_target等)，CKPT会通知 DBWR写脏块。CKPT会根据几个参数的设置和I/O的速度以及繁忙程度，计算出来一个Target rba(目标rba)，DBWn会沿着检查点队列，按照dirty buffer的Low RBA顺序将所有Target rba之前对应的脏块从内存写入数据磁盘文件。当CKPT通知完DBWn Target rba后，CKPT的任务就结束了。他并不会等待DBWn写完所有的Target rba之前的脏块。因此这里CKPT只是起到了一个通知DBWn进程写入的作用。ITPUB个人空间 R$ k f Kq#i n;| $q)O m(R Z0当