DBA-I第一章ORACLE体系结构(四).doc

第一章ORACLE体系结构（四）本节将重点来学习ORACLE实例的进程部分。Process我们先了解进程的概念和进程的类型图例 1ORACLE进程执行特定任务的一系列的操作，ORACLE里有多种类型的进程，分别是用户进程：我们可以理解为客户端进程，是用户提出某个请求建立的一个进程，如我们的SQLPLUS、一些第3方工具、一些应用代码等等都是。服务器进程：它是用来服务于用户请求的ORACLE进程。可以是专有服务器进程和共享服务器进程，并把处理的结果返回给用户进程。后台进程：这些进程通常是伴随着数据库的启动而启动的，并执行各种维护工作，例如块磁盘写，维护联机重做日志，清理异常进程等。也可以在数据库打开后启动非强制的后台进程。当然这里还有一种称为从属进程和伪进程。从属进程是类似后台进程，但它们是代表后台进程或服务器进程执行额外工作的进程上图是建立一个专有的服务器进程，其中这里最重要的进程是后台进程。图例 2不同数据库版本，不同产品，有着不同的后台进程，但有些是最基础的最核心的后台进程。每个ORACLE版本都被强制启动一些后台进程，如LGWR，DBWR，但是进程在我们OS上表现的形式不一样，在WINDOWS是通过线程的方式来处理进程的任务，从而把所有的线程组合成一个ORACLE进程。在UNIX环境，我们就可以清晰的看到后台进程、服务器进程及客户端进程。ps -ef | grep ora_ | grep -v grep可以用ps来查看后台进程，客户端进程可以跟服务器进程分离，并可以在不同的机器上，我们先来了解（进程/会话/连接）之间的关系。服务器进程/用户会话/连接服务器进程和用户建立会话，在专有模式下有服务器进程和用户进程，我们可以通过v$process来查看信息。 Select sid from v$mystat where rownum=1 是查看当前会话的sessionid上图可以通过当前会话来查看服务器进程号和用户进程号。用户进程号就是客户端进程，上图绿色框LOCAL=YES和BEQ表示客户端通过IPC进行本机连接。客户端进程由V$PROCESS.CLIENTPID指出,看蓝色框值是5112,我们可以通过ps查看该进程是sqlplus客户端。而红色框是服务器进程是SPID(SERVER PROCESS IDENTIFIED)，值为5114可以通过ps 查看是10g的服务器进程。连接：连接是客户端到数据库实例的物理通道连接可以经过网络NET8或者通过IPC（内部协议接口）实现一个典型连接客户段进程 专有服务器进程 （专有模式）客户段进程 调度器进程 （共享模式）我们来用SQLPLUS来建立一个连接当前连接上有一个会话和一个进程，会话ID=16，进程地址070000004B481688上图执行完set autot on后，该专有连接方式的连接上，出现两个会话，而进程地址相同。SID=18就是用于统计时用的会话。当关闭统计时，统计的会话自动关闭，只有原始会话用ps查看该进程我们用disconect关闭连接，但是进程还在会话也在。只是物理通道没有了，我们来看内存使用情况内存资源仍然被占有，所以单个连接可以有多个会话关联到单个进程，即使在专有模式。单个连接可以有0个、1个或者多个会话，但是专有模式单个会话对应单个进程。在没有连接的情况下，会话和进程可以一直存在。我们再来看共享服务模式我们看到连接到了S000共享服务器进程。但是当该会话休眠时会怎么样呢前面的共享服务器去服务别的会话了，所以当前会话只是跟调度程序D000关联，进入了响应队列。那当前会话再次活动时会怎么样呢故意激活另一个会话，好让刚才S000服务于它，那当前会话可能就不是由S000来服务了。上图看到由S001来服务了，这里大家应该联想到了司机和船长了吧。这些核心的后台进程涉及到很多内核的操作，它关系到ORACLE正确安全有效的运行，并直接跟我们的实例中个内存模块和其它后台进程关联着，所以要了解后台进程的机制，要温固我们前面内存的知识。后台进程也分强制后台进程和可选后台进程。强制后台进程我们首先按时间触发次序，来介绍第1个强制后台进程LGWR。谈到LGWR，他关联最主要的内存组件是REDO LOG BUFFER。另外还涉及REDO LOGFILE，它是物理组件。REDO是我们记录了数据库提供的服务的所有交易历史，包括买卖和退货，也就是REDO和UNDO。UNDO其实也是记录在REDO中一REDO记录形势存在，只是它的日志关系到的是保留回退的数据，所以也记在REDO里了。那这些交易历史记录必须有一个地方保存，我们会有三个地方保存redo bufferredo logfilearchive logfile这3个部分都有相应的进程去完成，并有一套严格的触发机制。而我们图的右边讲了从 redo buffer = redo logfile的触发机制，LGWR工作（触发将redo buffer的日志项写入redo logfile）的主要条件如下：1. 用户提交2. 有1/3重做日志缓冲区未被写入磁盘3. 有大于1MB重做日志缓冲区未被写入磁盘4. 超时（每3秒）5. DBWR需要写入数据的SCN号大于LGWR纪录的SCN号，DBWR触发LGWR写入 -这个例子最好跳过，太难为了更好的了解这三个部分的运作,我们也用一些生活化的故事来描述。这个故事比前面都要复杂,而且也跟很多性能有关系,涉及很底层知识我们就不讲了,希望能更通俗的理解它的机制。我先画出ORACLE各组件的名字及流程图,然后大家照着这个图去理解我们这个故事。1server process 2redo copy 3redo allocation 4redo copy 5redo allocation release 6 redo log buffer finished 7 modify block8redo entry valid 9 releases redo copy 10LGWR logfile 10-1 1/3 10-2 _log_io_size 10-3 commit10-4 dbwr 11redo writing finished 12dbwr1-12是这个redo请求到redo的数据到物理数据文件的确认过程，10下面有4个触发条件,分别是lgwr的触发条件。我们用一个寄信到收到信来描述这个流程。我们先罗列出几个主要的机构和人员一个邮局有：8个信件登记员1个信件登记归档员1个信件登记管理员多个发送邮递员多个接收邮递员比如小丽是某厂的收发室收发员，今天要发一批寄到北京的信（是基于一批同一目的的信），我再把前面的流程发一遍,大家对照下。 1server process 2redo copy 3redo allocation 4redo copy 5redo allocation release 6 redo log buffer finished 7 modify block 8redo entry valid 9 releases redo copy 10LGWR logfile 10-1 1/3 10-2 _log_io_size 10-3 commit10-4 dbwr 11redo writing finished 12dbwr我们来看邮寄的对应流程 1她打电话到邮局2邮局会分配一个信件登记员A先记录这些信来自哪里,寄到哪里等信息,信件登记员A来负责这件事情。3请求信件登记管理员，让他帮忙评估这次登记所需要帐本的大小,并提供此大小的帐本。信件登记员A请求信件登记管理员,让他帮忙评估这次登记所需要帐本的大小,并提供此大小的帐本。 4信件登记员A在此帐本上登记这次发往北京信的信息. 5信件登记管理员服务完信件登记员A,服务其它信件登记员 6信件登记员A完成这批信的登记7请求发送邮递员去收发室拿这批信发到邮箱。那为什么先登记再发送到邮箱呢?因为如果信件登记员A不先登记信息,那小丽不打算发信的话,要回退,邮递员会忘掉刚才是从哪儿拿来的. 8信件登记员A标注这次登记有效 9信件登记员A服务完小丽这次请求,将服务其它请求前面知道redo分下面三大步1 redo buffer2 redo logfile3 archive logfile这前面9步是完成这三大步的第一步（redo生成,并修改了相关的块），接下来是第二步是生成redo logfile 10LGWR logfile 10-1 1/3邮局会有一个记录整个邮局每天的信件记录进行归档的信件登记归档员。把所有8个信件登记员这次没有被信件登记归档员归档的条目进行归档。假如整个邮局最大可登记信件交易量是8000封。而且这8000封物理上顺序分配。所有邮箱里的信满三分之一(2400封信了)，这些登记的信的有效条目需要进行确认归档,以便这些信通过火车飞机传递到不同的目的地时,想返回,而找不到如何回到原来寄信人的位置 10-2 _log_io_size 满1000封信了,可以设置当然还有比如每天凌晨9点 10-3 commit小丽这批信确认一定要发送到北京,那一旦信件登记员登记的条目被以外丢失,而信又还在邮局的邮箱,还可以从信件归档条目里找到,这些信要寄的位置 10-4 dbwr 确定要把信发到北京时 11redo writing finished 12dbwr这些信最终通过火车飞机等送到北京的邮局前由信件登记归档员对这些信做信件登记归档。我使用一个行列表格来说明：进程动作生活例子1server process 1她打电话到邮局2redo copy 2邮局会分配一个信件登记员A先记录这些信来自哪里,寄到哪里等信息。信件登记员A来负责这件事情3redo allocation 3请求信件登记管理员，让他帮忙评估这次登记所需要帐本的大小,并提供此大小的帐本。信件登记员A请求信件登记管理员,让他帮忙评估这次登记所需要帐本的大小,并提供此大小的帐本。4redo copy 4信件登记员A在此帐本上登记这次发往北京信的信息5redo allocation release 5信件登记管理员服务完信件登记员A,服务其它信件登记员6 redo log buffer finished 6信件登记员A完成这批信的登记7 modify block7请求发送邮递员去收发室拿这批信发到邮箱。 为什么先登记再发送到邮箱呢? 因为如果信件登记员A不先登记信息,那小丽不打算发信的话,要回退,邮递员会忘掉刚才是从哪儿拿来的。8redo entry valid8信件登记员A标注这次登记有效9 releases redo copy9信件登记员A服务完小丽这次请求,将服务其它请求1 redo buffer2 redo logfile3 archive logfile这前面9步是完成这3大步的第1步redo生成,并修改了相关的块10LGWR logfile 邮局会有一个记录整个邮局每天的信件记录进行归档的信件登记归档员。10-1 1/3 把所有8个信件登记员这次没有被信件登记归档员归档的条目进行归档。假如整个邮局最大可登记信件交易量是8000封。而且这8000封物理上顺序分配。这些信最终通过火车飞机等送到北京的邮局前由信件登记归档员对这些信做信件登记归档。10-2 _log_io_size 10-3 commit10-4 dbwr11redo writing finished12dbwr我们用一个SQL来看下lgwr和dbwr是如何触发这儿大家注意3个session的时间点Alter system checkpoint 干嘛的，谁知道？此命令触发了一个全局检查点，就是后面要讲得CKPT进程然后CKPT进程触发DBWR讲数据缓冲区的脏数据（简称脏缓冲）写入到数据文件里，所以alter system checkpoint 后，你修改了的数据即使没有提交，也会写入到数据文件，明白了吧？根据前面执行的时间及对lgwr和dbwr的影响我们画出这张图也就是说小丽即使提交了10000,数据文件里还是5000的值而小王没有提交,数据文件反而已经写进去了更新后的值8000,因为DBWR前已经更新成8000了。那这时准确的数据是什么呢所以我们看到数据文件现在的值全错了，我们这时在查询小王薪水时需要小王从8000变为5000，小丽从5000到10000，那怎么让小丽从5000到10000，让小王回到5000呢？我们看下图要让已经提交为10000元的小丽实际数据文件从5000到10000，则需要应用logfile前滚到10000。要让未提交小王实际数据文件从8000回到一致性读的5000，则需要应用undofile回滚到5000。我们这里主要涉及到两个文件LOGFILE 日志记录了修改成8000前的记录是5000写到UNDOFILE的UNDO块里，而日志文件只是记录了UNDO块的改动向量，所以我们称这时的REDO为记录UNDO改动的REDO，也就是UNDO性质的REDO。它的改动向量是8000变成5000，这个5000记录在UNDO块中，并记录了这个UNDO块所关联的实际数据文件DATA 块地址，我们看到正真回滚不是LOGFILE中UNDO性质的REDO来做的，而是需要UNDOFILE来做，这样避免了回滚操作读取在线日志，从而减少了对LGWR的冲突，让日志文件通常只用于写操作，而不去读操作。要读UNDO就要去读UNDOFILE，这就是ORACLE和其它数据库区别的本质。UNDOFILE 将所有数据前滚后，发现有些事务没有提交的标志，此时若用户发出ROLLBACK，或者一致性读的时候，那么将应用对应事务的UNDO链，回滚到事务前的状态，8000的事务前的状态是5000，这个5000是在回滚段块上（UNDO块），这时才找到小王准确的值5000。所以得到小王值的是在UNDOFILE回滚段里，并得到上图红色框。上面的知识点，大家有问题没？LGWR、DBWR都只是写，WR就是Write嘛LGWR主要负责将重做日志缓冲区（redo log buffer）的数据写入重做日志文件（redo log file）。当数据被修改的时候，系统会产生一个重做日志并纪录在重做日志缓冲区内。而DBWR主要负责将数据缓冲区内的脏数据（脏缓冲）定期写入数据文件。好，我再帮大家理一理因为LOGFILE里会有UNDO性质的REDO，而UNDOFILE里也有这部分UNDO数据，我们以前介绍个一致性读（CR），那我们在SELECT一个未提交的块时，需要一致性读。那一执行读应该究竟去读LOGFILE里 UNDO性质的REDO呢？还是直接读UNDOFILE里的UNDO BLOCK？对，会读UNDO BLOCK，这样就不用去读LOGFILE了，LOGFILE是LGWR在写的，这样就没有一致性读的IO跟LGWR竞争了。好，我再给大家说下前滚和回滚。回滚是读取UNDO，比如ROLLBACK，刚才说的一致性读，都会读取UNDO的信息，回滚到更改前的值。而前滚一般用在恢复上，这里涉及到备份恢复，又超纲了。比如你有5000块前，现在update成10000块了，而且还commit了，但是这时候突然断电了，你的10000块钱还没落实到你口袋，就消失了。那么来电了，数据库要进行崩溃恢复，这时就需要前滚，把提交的部分前滚，你的5000就变成10000了，然后前滚的时候还会检查到未提交的，那未提交的就要回滚，这就是恢复过程中前滚和回滚的区分。恢复的时候大家记住一句话，先前滚再回滚我再整个例子，这块大家第一次容易晕，你如果是周1 周2 周3 周4存5000元存5000元COMMIT存4000元如果数据在周四你刚存完4000还没来得及COMMIT的时候就DOWN了，坏了你得用备份来还原恢复吧，我们假设有周1做的备份，周一做备份的时候当时账户还没有钱。好，那我们先把周1的备份还原，还原后还不行啊，你存的钱都丢了，还得用日志来恢复，那恢复就要用到重做日志。这个时候我们的恢复目标是要恢复到帐号里有10000元，对吧？那恢复的过程是前滚周1的5000,周2的5000,周3的COMMIT,周4的4000，直至最后一笔交易，那现在帐户里是不是14000全部前滚完就是14000,但是14000是不正确的,因为我在周4存4000的时候,没有按确定,数据库就崩了，正确帐户余额是10000。那是不是得把周四的交易(改动向量)回滚，交易我们可以理解成REDO的向量回滚也要应用REDO（UNDO性质的REDO）,这个REDO会去找UNDOFILE整个过程就是：先从redo(REDO性质的REDO)找到DATAFILE,再应用REDO记录的数据来写DATAFILE（前滚），再从REDO(UNDO性质的REDO)找到UNDOFILE,再应用UNDOFILE的块,完成回滚这里涉及到日志写、脏缓冲写、UNDO数据脏缓冲写和REDO数据脏缓冲写有先后次序的问题。第一个问题UNDO、REDO数据脏缓冲写顺序那如果dbwr将小王从5000写到8000元,如果这时候停电,小王的当前数据文件是8000,正确的是5000,这5000的记录redo buffer或者logfile有,它是UNDO性质的REDO。但是可能会出现类似DOWN机，停电等事件，内存马上被刷了，那如果没有先没记录UNDO性质的REDO，你如果日志、脏缓冲区里先记录了5000变为8000，此时数据库down，那要想小王回到5000元是不可能的了，因为人事部不知道，小王加薪前工作5000。当然小王是开心死了,没有存3000,结果拿到了8000。这是绝对不允许的，所以在修改一个数据前，第一步是保存修改前的值后（包括记录UNDO性质的REDO、写UNDOFILE的脏缓冲）才能做真正的修改。第二个问题日志缓冲写、脏缓冲写顺序我们知道脏缓冲是业务数据的变化记录在内存的区域，它通过dbwr写到磁盘数据文件，但是ORACLE为了提高磁盘写的效率，采用了延迟内存写的技术，会很长时间才会从SGA中数据库高速缓冲中脏缓冲写到磁盘。那如果这么长时间的内存数据一定很多，如果突然停电，意味着要丢失脏缓冲的所有修改。这会造成一些客户明明提交了一笔交易（比如存入100万），却最后被内存丢失了，磁盘里再也没有这笔交易了，这在ORACLE是绝对不允许的，数据的准确性和安全性是数据库最重要的基础，所以ORACLE会强制在COMMIT后已经确认的交易必须从内存到磁盘得到确认，但是如果通过脏缓冲确认会对性能有很大影响，于是这项任务就交给LGWR来完成，一旦有COMMIT就必须从REDO BUFFER写到磁盘的LOGFILE。这样安全就得到保证。正是因为这一点，我们如果先在脏缓冲了确认了一笔交易，再记录这比交易的历史，那会存在很大风险，如果写脏缓冲成功，并做COMMIT，接着数据库DOWN了，还没来得及记录日志，那这笔100万就完全丢失了。因为100万只记录在内存，没有记录在LOGFILE，也没有记录在DATAFILE，这是非常危险的。所以ORACLE强制先写日志BUFFER，再写脏缓冲。我们总结下修改数据的步骤修改数据的步骤写UNDOFILE变更的日志改动向量，如8000修改前的值5000到UNDOFILE的这次改动向量到REDO BUFFER。写8000修改前的值5000写到UNDOFILE对应的脏缓冲。写5000修改后的值8000到DATAFILE的这次改动向量到REDO BUFFER。写5000修改后的值8000到DATAFILE对应的脏缓冲。接下来我们来学习一个非常重要的后台进程，检查点进程。检查点 检查点是一个维护数据库一致性的重要的后台进程，跟DBWR，LGWR及备份与恢复原理有着密切的联系，也涉及到非常多的理论，所以大家要学习它的时候请回忆下我们前面学过的内存和进程的架构。检查点是一个数据库事件，它将已修改的数据从脏缓存里刷新到磁盘，并更新控制文件和数据文件的一致性信息。它是一个数据库一致性的快照，可以针对一个文件，一组文件，一个实例，所有集群实例。检查点只是一个事件，触发了别的进程，而自己只是改变一些数据文件和控制文件里的一致性信息。它触发的是DBWR，真正干活的是DBWR。当检查点触发时，会将记录在检查点队列里的脏缓冲中生成的改动刷新到磁盘，这里涉及检查点队列。关于检查点那么多概念我们可以举一个简单生活的例子：我们坐火车到深圳火车站旅游集散中心，火车站有专门的等候旅游大巴的站台，有专门的交通协调员会拉一根绳子，为我们旅客排队。旅行团可以理解成是重做向量改动的实体，每个旅行团我们看成ORACLE的一个块，旅行团的每个人好比是ORACLE中的一行记录，每个旅行团的个体的动作在ORACLE中称为改动向量，比如小王去厕所。而等待排队的是谁？只需要旅行团的导游小姐，导游小姐就好比数据块的块头BUFFER。所以每个旅行团导游小姐在开始排队到坐上大巴这一任务可能有一系列的动作（改动向量），而这个等待队列是先进先出的，最先排队的，最先得到旅游大巴的服务。但是这时导游小姐排在第5位。旅行团的小丽去买饮料，表示一个块的行的变更，有了改动向量，但是导游小姐仍然排在队列的第5号位置。也就是导游小姐的位置不受旅行团每个旅客的影响。而交通协调员当排队长度达30人的时候统一放前10个旅行团去坐大巴。接着又有10个新的旅行团的导游来排队的时候，交通协调员再次放行。这将是我们后面将到的快速检查点。另外放行的规则非常多，还有比如到固定时间就得放人，我们后面详细介绍。开始备课（2010.08.19）上节课我们学习了ORACLE非常重要的两个后台进程：LGWR和CKPT，我们还是来简单复习下。第一个问题：我们知道ORACLE后台进程也分强制后台进程和可选后台进程。那大家说下ORACLE的强制后台进程有哪几个？DBWR,LGWR.CKPT.SMON,PMON。第二个问题：LGWR进程触发的条件有哪些？1用户提交2. 有1/3重做日志缓冲区未被写入磁盘3. 有大于1MB重做日志缓冲区未被写入磁盘4. 超时（每3秒）5. DBWR需要写入数据的SCN号大于LGWR纪录的SCN号，DBWR触发LGWR写入谈到LGWR这个后台进程，它关联最主要的内存组件是REDO LOG BUFFER，另外还涉及REDO LOGFILE（它是个物理组件）第三个问题：COMMIT触发写脏数据到DATAFILE吗？checkpoint触发写脏数据吗？第四个问题：看下图：上图大家都还记得吧？好，那大家结合上图，总结出我们修改一个数据后，日志缓冲写，脏缓冲写的顺序（顺序写出4步）。写UNDOFILE变更的日志改动向量，如8000修改前的值5000到UNDOFILE的这次改动向量到REDO BUFFER。 -（UNDO的REDO）写8000修改前的值5000写到UNDOFILE对应的脏缓冲。写5000修改后的值8000到DATAFILE的这次改动向量到REDO BUFFER。（REDO的REDO）写5000修改后的值8000到DATAFILE对应的脏缓冲。为什么先要纪录UNDO性质的REDO？ 第五个问题：什么是检查点队列？检查点队列是按照数据块最初变脏时的顺序排列的脏数据块链接列表。大家还记得我们那个 导游小姐排队等大巴的生活例子吧？我们的大巴等待队列 就相当于检查点队列Oracle从8i开始引入了检查点队列这么一种概念，用于记录数据库里面当前所有的脏数据块的信息。检查点队列是存的我们的脏缓冲的地址及相关信息，也就是导游小姐记录了旅行团的信息。导游小姐相当于什么？是不是脏BUFFER的块头？DBWR根据这个队列而将脏数据块写入到数据文件中。好，我们今天继续来学习检查点大家还是先回顾下我们上节课导游小姐带旅行团那个生活例子，帮助我们理解。在ORACLE中一样，我们来对上面的过程做个对比。旅行团：对应ORACLE的脏块旅行团导游小姐：ORACLE脏缓冲块头，在检查点队列里存放的是块头信息旅行团的旅客：ORACLE脏块的行旅行团的旅客买饮料：ORACLE脏块新的改动向量大巴等待队列：检查点队列交通协调员放行：触发检查点一个块可以在刷新到磁盘之前，在脏缓冲中被修改了多次。比如从5000改成8000，又从8000改成10000。但是它在检查点队列的位置是不边的，也就是被DBWR刷到磁盘的顺序是定的，第5个旅行团永远是第5个最早坐上旅游大巴的旅行团。等你下次从组团到旅游集散中心排队的时候，会领取一个新的位置。上图蓝色框组成了检查点队列，就是我们前面举例的旅游大巴候车队列，而右边框的每条记录就是重做向量2/123是第2个文件的第123块，我们好比2/123这个导游小姐是第2个早排队的，她关联到2/123整个旅行团。但是在REDOLOG中第6行还是2/123这个块的第41行的改动向量，这时候好比2/123旅行团的第41个旅客去买饮料了，但是不要紧，导游小姐仍然在第2号的位置，你去买饮料也不影响我们上大巴的进度。好，我们知道了检查点队列是存的我们的脏缓冲的地址及相关信息，也就是导游小姐记录了旅行团的信息。每条改动就是一次改动向量，当CKPT/DBWR触发时，就相当于交通协调员把绳子送开，让这一批旅行团上车。这个过程就是DBWR，但是我们这里要谈的是检查点触发的条件。那我们来归纳下什么是改动向量？什么是重做记录？重做向量（改动向量）：是单个块的单次改动，我们看到2-123被改了2次，就有2个重做向量，分别称两个版本。我们分别用SCN - DBA -SEQ来标识这个改动向量，它是用来唯一标识块的版本。SCN就好比系统的时钟，在ORACLE提交时才会增加1。也就是我们（数据块地址DBA）这次旅行团（事务SCN）上火车有一个系统的SCN（2009-5-1 14：00），SEQ=1小王上厕所有个SCN（2009-5-1 14：05），SEQ=1小丽买饮料有个SCN（2009-5-1 14：05），SEQ=2，我们发现小王和小丽在同一个SCN上做的动作，所以为了区别他们前后的版本，使用SEQ增加1来表示。大家一起吃饭有个SCN（2009-5-1 14：10）那DBWR对于在检查点队列里有多个REDO的，通过记录了LOWER RBA对应的脏数据块地址去写脏缓存（DBWR好比交通协调员放行时只要去联系导游就行了）。这个脏数据块已经修改了多次，只要刷新当前的脏块到数据文件就可以了。好，这儿我问下大家，什么LOWER RBA？RBA是Redo Block Address的简称。 检查点队列按时间先后记录着数据库里面脏数据块的信息检查点队列中的每个条目包含对应脏数据块的标识符（即文件编号与块编号），以及该数据块最初变脏时在重做日志中所处的位置（称为重做字节地址）这个脏块最初变脏时在重做日志中所处的位置，就叫LOWER RBA。大家想下我们的例子，检查点队列（等待大巴队列）里放的是不是导游小姐的信息？导游小姐就是第一个变脏的，不管旅行团你下面的其他人怎么动，都不会影响到我导游小姐的排队位置。检查点队列中的第一个条目标识数据库缓冲区高速缓存中最早的脏数据块，DBWn按检查点队列中的顺序从缓冲区高速缓存中写入块，随着数据块的写入，对应的每个条目将被删除 这个RBA的概念大家先记住，这个是后面我们讲备份恢复的关键知识点。 Checkpoint RBA又叫检查点位置，重做日志中开始恢复的位置就叫检查点位置，在该检查点之前的所有引用数据块都已由DBWR写入磁盘，这就是我们恢复的起点了。这是后面备份恢复的知识，又超纲了。好，改动向量的概念非常重要，接下来我们来了解下重做记录。重做记录：描述数据库中一个原子改动比如update table some_rows set col3 = 2009-3-9 where id = 1000;这是一次原子改动，它会生成多个改动向量，比如要先修改回滚段事务头，写回滚信息到回滚段，写2009-3-9到数据行，col3可能有索引，要写索引的UNDO和索引的REDO等。就好比我今天去东方明珠游玩，我会先起床、吃饭、打车、上东方明珠、上厕所、打车、回家。这一系列其实都是去东方明珠游玩这个原子的重做记录好，我们介绍两个重要的东东：改动向量和重做纪录。那我问下大家，我们的重做记录由什么组成的呢？重做记录就是由重做向量（改动向量）组成。检查点类型检查点类型非常多，基于刷新检查点队列的频率和方式和数据量的不同，我们要将检查点分很多种类，但归类起来有大的三种局部检查点单个实例执行数据库数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件。它属于完全检查点。我们大部分数据库是单实例的触发局部检查点的条件：alter system checkpoint local;日志切换 alter system switch logfile;fast相关参数触发 通过show parameter fast参数查看全局检查点所有实例（对应并行数据服务器或RAC）执行所有所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件。触发全局检查点的条件：alter system checkpoint global;文件检查点所有实例需要执行数据文件集的一个检查点操作，如使用热备份命令begin backup触发文件检查点的条件alter tablespace USERS begin backupalter tablespace USERS offline其它的检查点如:快速检查点：是一个重要的检查点概念增量检查点：是一个重要的检查点概念数据库检查点线程检查点慢速检查点对象检查点我们来看下重做日志，再来理解不同检查点对检查点队列的处理我们这里有个增量检查点（后面详细介绍），当把箭头以前的REDO向量全部写到磁盘后，前面的数据就不需要实例恢复了，我们看红色箭头。凡是存在需要实例恢复的REDO所在日志文件，则状态不是CURRENT就是ACTIVE。黑色箭头所指向的地址（RBA）就是实例恢复的起点。我们来看第一种检查点类型，完全检查点完全检查点是当你在完全检查点时确定一个当前的地址，我们看到上图是T4 3 20之前的REDO向量全部被写到磁盘，这里是指全部，也就是说，你在火车站旅游集散中心等候旅游大巴的导游小姐全都放行，就叫完全检查点，这显然IO很大。所以为了避免IO性能，完全检查点频率肯定不会很高。完全检查点完全检查点是在几种情况下实现：alter system checkpointshuwdown注意，日志切换不做完全检查点。接下来学习一个重要的概念，增量检查点增量检查点图例 3这个图我们先看右边，左边暂时不看。右边表示了redolog的改动，由上到下表示改动的顺序t1、t87是事务，file-文件号block-块号。 增加检查点只写一部分，不像全局检查点全部写 绿色部分表示的是对应的脏块已经被DBWR刷到了磁盘。 我在前面给大家补充了RBA的知识，刚刚才讲的。 RBA就好像导游小姐排队的位置 在检查点期间不论数据块更改几次，它在检查点队列里面的位置始终保持不变，检查点队列也只会记录它最早的RBA，从而保证最早更改的数据块能够尽快写入。 再看上图，上面的图的事务T1、文件3，块12有几次改变？ 是不是两次？ 不管你后面的旅客怎么改变，我导游小姐的位置是始终不变的。 我们看绿色部分的由DBWR将检查点队列里面的脏数据块写入到数据文件后，现在检查点位置（Checkpoint RBA）到哪儿了？ 是不是绿色结束的部分？ 好，我按照术语给大家总结下： checkpointqueue是按照脏BUFFER的lowerRBA排序的 也就是说按照buffer第一次发生变化的时候的时间点排序的 这样dbwr根据checkpointqueue中顺序写出脏buffer就一定能保证是按照buffer首次发生变化的时间顺序写到磁盘的。 checkpointqueue的出现支持了Oracle的增量检查点的功能的实现。 没有这个队列，无从谈起增量检查点 当增量检查点发生的时候，告诉dbwr写脏buffer要一直写到checkpointqueue中的一个最新位置 在这个检查点过程中，可以继续产生dirtybuffer，dbwr也不是一次要把所有dirtybuffer全部写到磁盘（不同于完全检查点的地方），这样就提高了检查点的效率 而且使得数据库要做恢复的时候从这个最新的检查点位置（Checkpoint RBA）开始做恢复，而不是从数据文件中的checkpointscn（上一个完全检查点位置）开始做恢复，这样将缩短恢复时间。 所以说，增量检查点的好处除了避免了IO性能，还能缩短恢复的时间。 这里问一个以后才学的问题？我看看大家基础，不知道也没事，目前不作要求。 我刚刚说到，增量检查点而且使得数据库要做恢复的时候从这个最新的检查点位置（Checkpoint RBA）开始做恢复。 那这个检查点位置记录在哪儿呢？这个检查点位置不停得被更新，肯定ORACLE要拿个地方要保存记录，记录在哪儿？ 记录在ORACLE的控制文件里。 我们知道增量检查点是每3秒一次，则每3秒种ckpt会在控制文件中更新dbwr写到那个最新的位置了，这样实例恢复的时候就从控制文件中记录的最新位置开始，减少了实例恢复的时间。 CKPT每三秒会在控制文件中记录检查点的位置，以表示InstanceRecovery时开始恢复的日志条目，这个概念称为检查点的heartbeat。 每3秒更新控制文件，但不会更新数据文件头，只在控制文件中记录checkpoint的执行情况。 好，这个是后面的知识了，暂时不讲多了。增量检查点是在上一次检查点被写后评估出3秒的redo 向量，再把这部分REDO量来指定出下一个刷新的增量检查点的位置。就好比现在满了10个旅行团在等待，交通协管员知道这次3秒钟大概要放行前3个旅行团。接着之后3秒钟又来了5个旅行团来排队。那么这次交通协管员过3秒后放行5个旅行团。红色框是要DBWR刷新脏数据的部分，目标增量检查点地址是3，也称为检查点RBA，或者LOWER RBA，RBA是REDO BLOCK 的地址。检查点完成后我们发现检查点队列的前3个旅行团被DBWR刷掉了，再经过3秒后，共有新的5个旅行团来排队。知道3秒种增量了5个团，就可以确定下个增量检查点的目标位置这时刷新8以前的数据刷新后只剩下9以后的旅行团，以此类推，这就是增量检查点。通过增量检查点来减少实例恢复的时间。当然这里还有很多其它因素影响到增量检查点。我们看上图，前面的红色部分表示已经被DBWR写到磁盘了。箭头指的地方就是目前的检查点位置。好，上面的图过了一会儿后，见下图：图例 4上图大括号那一截就是3秒内增加的redo我们看到在刷新的过程后，有更多的redo进来，那它评估出进来3秒内有大括号部分的redo。图例 5它会按这个redo量刷新最早的这么多量的redo，我们看大括号。这个大括号就好比 我们刚才排队例子的3秒后又来了5个旅行团，来了5个就得放行5个。而蓝色部分是大家都知道的，必须在FAST_START_IO_TARGET或FAST_START_MTTR_TARGET指定的部分。这两个参数我待会稍微介绍一下。 大家再结合刚刚讲那个来5个刷5个的旅行团例子比较理解下。我们知道，有的时候增量检查点刷新早期的旅行团的速度比新增的旅行团慢，这就造成检查点队列很长，为了控制检查点队列太长，我们设置了一个快速检查点。我们有几个方法来控制：检查点队列最长不超过一定的IO，比如队列最多排10个团。FAST_START_IO_TARGET。过了10个团，就必须全部放行。 这个参数就是控制一次的IO量。 比如说你本来的队列全部刷到磁盘要10000的IO，你的FAST_START_TO_TARGET设置为12000，那么再来了3000的IO后，即使没到增量检查点的时间（3秒内），也会全部马上刷磁盘。 这个参数在9I就废了，一般不怎么用。检查点队列最长不超过10分钟的队列。FAST_START_MTTR_TARGETMTTR是故障平均恢复时间，而这部分检查点队列所花的时间就是涉及到平均恢复时间。比如，你设置该参数为10分钟，那么过了10分钟就是没有其他团来排队也会刷新到磁盘。fast_start_mttr_target数用于表示检查点位置和重做日志尾之间的时间间隔,以秒为单位,默认情况下是1800秒,这个参数实际上表示了脏块保持脏状态的最长时间.如果它被定为1800秒,没有脏块保持1800秒后,还是为脏. 就是说脏块1800秒以后，必定被写入 好，这两个参数了解下就行，不过多讨论。在ORACLE在受一个日志文件大小的90%的限制。看下图：图例 6当前检查点的位置不能同当前日志在不同的位置，保证蓝色条不能超过整个日志的90%，也就是意味着FAST_START_IO_TARGET不能大于一个最小日志的90%。 这里的90%其实就是为了防止检查点位置跨越多个日志。好，检查点还有很复杂的过程，我们今天的课就把检查点介绍到这里。接下来学习另外几个重要的后台进程SMON我们前面已经学了三个重要的必选后台进程LGWRCKPTDBWR他们之间都是密切关联切有一定的执行顺序，我们接下来学习另外两个必选后台进程。SMON和PMON我们首先来学SMON图例 7SMON用来维护和监控整个数据库的安全和完整性。它的主要职责有如下：实例恢复每3秒整理区碎片清理临时段我们接着详细讲这3部分，我们用静安书店来比喻这个实例，SMON就相当于公司的行政部长，处理这个公司的日常运做。比如停电、公司处理大的活动、还有像一些场地的分配等。那我们的SMON第1个重要任务就是处理实例的异常DOWN机（类似停电）。我们知道，ORACLE为了实现高效，会把最近的数据和日志记录在内存，定期会去刷新，这就是前面的LGWR，DBWR的进程干的活。所以DOWN机也就意味着你的磁盘数据不是最新和最终的数据。那最新最终的数据在哪里呢？在DB BUFFER，还有及少部分在REDO BUFFER，那还有一个地方有：LOGFILEdb bufferlogfileredo buffer：这个部分肯定没提交，否则写到logfile所以停电了会有什么结果，db buffer、redo buffer没了，因为电没了，内存就没了。那新的数据要想不丢失，只能从logfile里拿，而redo buffer丢了也不要紧，反正没提交。我们用图来了解这个过程图例 81. SMON在实例启动时完成实例恢复，应用没有写到磁盘的改动向量，并回滚没有提交事务的改动向量。停电后SMON等于要做两个动作。a) 我们看增量检查点将写最早的3秒钟的重做向量（图上绿色部分）b) 前滚 -前滚那些没有写到磁盘的改动向量（白色箭头部分），这些脏缓存被停电丢了。最后的重做向量是T4,这时箭头以下的部分还没被应用，这时候停电，停电时数据文件是在黑色箭头的状态，日志文件在最后t4的状态，我们看到前滚后，有些事