《深分析学习教程.pptx》由会员分享，可在线阅读，更多相关《深分析学习教程.pptx（84页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、buffercache所能提供的功能主要包括：1）通过缓存数据块，从而减少I/O。2）通过构造CR块，从而提供读一致性功能。3）通过提供各种lock、latch机制，从而提供多个进程并发访问同一个数据块的功能。第1页/共84页buffer cache概述概述oracle内部在实现其管理的过程中，有两个非常有名的名词：链表和hash算法。链表是一种数据结构，通过将对象串连在一起，从而构成链表结构。这样，如果要修改、删除、查找某个对象的话，都可以先到链表中去查找，而不必实际的访问物理介质。oracle中最有名的链表大概就是LRU链表了，我们后面会介绍它。第2页/共84页hash算法则是为了能够进行
2、快速查找定位所使用一种技术。所谓hash算法，就是根据要查找的值，对该值进行一定的hash算法后得出该值所在的索引号，然后进入到该值应该存在的一列数值列表（可以理解为一个二维数组）里，通过该索引号去找它应该属于哪一个列表。然后再进入所确定的列表里，对其中所含有的值，进行一个一个的比较，从而找到该值。这样就避免了对整个数值列表进行扫描才能找到该值，这种全扫描的方式显然要比hash查找方式低效很多。其中，每个索引号对应的数值列在oracle里都叫做一个hashbucket。第3页/共84页我们来列举一个最简单的hash算法。假设我们的数值列表最多可以有10个元素，也就是有10个hashbucket
3、s，每个元素最多可以包含20个数值。则对应的二维数组就是t1020。我们可以定义hash算法为nMOD10。通过这种算法，可以将所有进入的数据均匀放在10个hashbucket里面，hashbucket编号从0到9。比如，我们把1到100都通过这个hash函数均匀放到这10个hashbucket里，当查找32在哪里时，只要将32MOD10等于2，这样就知道可以到2号hashbucket里去找，也就是到t220里去找，2号hashbucket里有10个数值，逐个比较2号hashbucket里是否存在32就可以了。第4页/共84页buffercache就是使用多个hashbucket来管理的，其h
4、ash算法当然比我们前面列举的要复杂多了。我们先来看下面这个图。这副图从逻辑上说明了整个buffercache的结构是怎么样的。这副图的右上角列出了三个名词：hashbucket、bufferheader和hashchain。第5页/共84页这里的hashbucket就是我们前面说明hash算法中提到的二维数组的第一维。它是通过对bufferheader里记录的数据块地址和数据块类型运用hash算法以后，得到的组号。这里的hashchain就是属于同一个hashbucket的所有bufferheader所串起来的链表。实际上，hashbucket只是一个逻辑上的概念。每个hashbucket都
5、是通过不同的hashchain而体现出来的。每个hashchain都会由一个cachebufferschainslatch来管理其并发操作。第6页/共84页对于bufferheader来说，每一个数据块在被读入buffercache时，都会先在buffercache中构造一个bufferheader，bufferheader与数据块一一对应。bufferheader包含的主要信息有：1）该数据块在buffercache中实际的内存地址。就是上图中的虚线箭头所表示的意思。2）该数据块的类型，包括data、segmentheader、undoheader、undoblock等等。3）该buffer
6、header所在的hashchain，是通过在bufferheader里保存指向前一个bufferheader的指针和指向后一个bufferheader的指针的方式实现的。4）该bufferheader所在的LRU、LRUW、CKPTQ等链表（这些链表我们后面都会详细说明）。也是通过记录前后bufferheader指针的方式实现。5）当前该bufferheader所对应的数据块的状态以及标记。6）该bufferheader被访问（touch）的次数。7）正在等待该bufferheader的进程列表（waiterlist）和正在使用该bufferheader的进程列表（userlist）。buf
7、fercache中，缺省的hashbucket的数量或者说缺省有多少条hashchain链表，是由一个隐藏参数：_db_block_hash_buckets决定的。置于该参数的取值，8i下，该参数缺省为db_block_buffers2；但是到了9i以后，该参数取的是小于且最接近于db_block_buffers2的素数。第7页/共84页转储转储buffer cache就象实例中的其他内存结构一样，oracle提供了可以将buffercache转储到跟踪文件的方法。方法如下：这里的level有很多值，分别可以转储buffercache中的不同的内容。level的可选值包括：1只转储buffer
8、header2在level1的基础上再转储数据块头3在level2的基础上再转储数据块内容4转储bufferheader和hashchain5在level1的基础上再转储数据块头和hashchain6在level2的基础上再转储数据块内容和hashchain8转储bufferheader和hashchain以及users/waiters链表9在level1的基础上再转储数据块头、hashchain以及users/waiters链表10在level2的基础上再转储数据块内容、hashchain以及users/waiters链表第8页/共84页我们创建一个简单的测试表，然后看看转储出来的buffe
9、rheader是什么样子的。第9页/共84页这时我们知道buffer_test表的object_id是54286，同时，该表中只有2个block具有数据。1个是segmentheader，另一个就是实际存放了1这个值的数据块。接着我们把bufferheader转储出来：到user_dump_dest所定义的目录下，找到跟踪文件并打开，可以看到类似下面的信息，这里我们列出前两个bufferheader以及我们建立的object_id为54286的buffer_test表所对应的bufferheader的内容：第10页/共84页这个BH的hash值指向前一个BH的hash指向后一个BH的hash可
10、以判断是否在一个chain上，进而判断是否在一个Bucket上。同样的，我们还可以看到类似结构的lru、ckptq、fileq，这些都是管理bufferheader的一些链表结构。第11页/共84页我们来看我们创建的buffer_test表所对应的bufferheader。首先，我们看到class，表示该bufferheader所对应的数据块的类型，具体的值与含义的对应为：1=datablock；2=sortblock；3=saveundoblock；4=segmentheader；5=saveundoheader；6=freelist；7=extentmap；8=1stlevelbmb；9=
11、2ndlevelbmb；10=3rdlevelbmb；11=bitmapblock；12=bitmapindexblock；13=unused；14=undoheader；15=undoblock。我们可以看到与buffer_test表相关bufferheader有两个：一个是4（segmentheader），另一个是1（datablock）。第12页/共84页我们看到rdba，这表示bufferheader所对应的数据块的地址。我们可以看到class为1的bufferheader的rdba为0 x00410452(1/66642)。说明该数据块的位置是1号文件的66642号block里。00
12、4表示数据文件号乘以4，而10452表示数据块的号。我们看到，该bufferheader指向的就是1号文件里的66642号数据块。我们可以再来看看表buffer_test里的rowid所告诉我们的文件号以及数据块号，从下面可以看到，结果是一样的。这个对象的obj=54286第13页/共84页这个是对象的segmentheader所对应的bufferhandle。Obj=54286第14页/共84页我们可以来看一下st，这表示buffercache所指向的数据块的状态。一共有六种状态：FREE(0)=可以被重用的数据块；XCURRENT(1)=实例以排他方式获取的当前模式数据块；SCURRENT
13、(2)=可以与其他实例共享的当前模式数据块；CR(3)=作为一致性读镜像的数据块，永远不会被写入磁盘；READING(4)=正在从磁盘读出的数据块；MRECOVERY(5)=正在进行介质恢复的数据块；IRECOVERY(6)=正在进行实例恢复的数据块。从状态说明中我们可以看到，现在表buffer_test的数据块都是当前模式的数据块。我们可以来构造一个CR状态的数据块。这个Bufferheader所指向的数据块的状态。第15页/共84页分别建立两个session，在一个session中，执行：不要提交，然后在另外一个session中，执行：第16页/共84页我们转储bufferheader后，
14、到跟踪文件中找到obj为54286的记录，可以看到类似如下的内容。可以看到该bufferheader的状态就是CR。另外，我们还可以看到tch，就是表示该数据块被扫描的次数。以上这些是转储出来的内容。Oracle还提供了视图来显示bufferheader的内容，这就是X$BH。这个视图就是把转储到平面文件以后所看到的诸如hash、st、tch等的值以列的方式呈现出来。第17页/共84页buffercache的内部管理机制在buffercache中获取所需要的数据块的过程当前台进程发出SELECT或者其他DML语句时，oracle根据SQL语句的执行计划确定所要找的数据块，会构造一个名为数据块描
15、述（bufferdescriptor）的内存结构。该bufferdescriptor位于session的PGA中，所包含的内容主要是数据块所在的物理地址、数据块的类型、数据块所属对象的objectid等信息。随后，oracle会把对数据块请求的锁定模式以及所构造出来的bufferdescriptor传入专门搜索数据块的函数中。在该函数中，oracle根据bufferdescriptor所记录的信息，应用hash算法以后，得到要找的数据块所处的hashbucket，也就是确定该数据块在哪条hashchain上。然后，oracle进入该hashchain，从上面所挂的第一个bufferheader
16、开始搜索，一直搜索到最后一个bufferheader。第18页/共84页在hashchain上搜索的逻辑如下：1)比较bufferheader上所记录的数据块的地址，如果不符合，则跳过该bufferheader。2)跳过状态为CR的bufferheader。3)如果遇到状态为READING的bufferheader，则等待，一直等到该bufferheader的状态改变以后再比较所记录的数据块的地址是否符合。4)如果发现数据块地址符合的bufferheader，则查看该bufferheader是否位于正在使用的列表上，如果是，则判断已存在的锁定模式与当前所要求的锁定模式是否兼容，如果是，则返回该
17、bufferheader所记录的数据块地址，并将当前进程号放入该bufferheader所处的正在使用的列表上。5)如果发现锁定模式不兼容，则根据找到的bufferheader所指向的数据块的内容，构建一个新的、内容一样的、状态为XCURRENT的复制数据块，并且构造一个状态为CR的bufferheader，同时该bufferheader指向所新建立的复制数据块。然后，返回该复制数据块的地址，并将当前进程号放入该bufferheader所处的正在使用的列表上。6)如果比较完整个hashchain以后还没发现所要找的bufferheader，则从磁盘上读取数据文件。并将读取到的数据块所对应的bu
18、fferheader挂到hashchain上。第19页/共84页LRU和LRUW链表结构概述在前面，我们已经知道了oracle是如何在hashchain中搜索要找的数据块所对应的bufferheader的过程，我们也知道如果在hashchain上没有找到所要的bufferheader时，oracle会发出I/O调用，到磁盘上的数据文件中获取数据块，并将该数据块的内容拷贝一份到buffercache中的内存数据块里（顺带提一句，内存数据块通常叫做buffer，而数据文件里的数据块通常叫做block，二者是一个意思）。这个时候，假如buffercache是空的，比较好办，直接拿一个空的内存数据块来
19、用即可。但是如果buffercache中的内存数据块全都被用掉了，没有空的内存数据块了，怎么办？应该重新使用哪一个内存数据块？当然我们可以一个一个的比较内存数据块与其对应在数据文件中的数据块的内容是否一致，如果一致则可以将该数据块拿来，将其内容清空，然后拷贝上当前数据块的内容；如果不一致，则跳过，再找下一个。毫无疑问，这种方式效率低下。为了高效的管理buffercache中的内存数据块，oracle引入了LRU和LRUW等链表等结构。第20页/共84页在buffercache中，最耳熟能详的链表可能就是LRU链表了。在前面描述buffercache结构的图上，也可以看到有两个链表：LRU和LR
20、UW。在介绍LRU和LRUW前，先说明几个概念。1）脏数据块（dirtybuffer）：buffercache中的内存数据块的内容与数据文件中的数据块的内容不一致。2）可用数据块（freebuffer）：buffercache中的内存数据块为空或者其内容与数据文件中的一致。注意，可用数据块不一定是空的。3）钉住的数据块（pingbuffer）：当前正在更新的内存数据块。4）数据库写进程（DBWR）：这是一个很底层的数据库后台进程。既然是后台进程，就表示该进程是不能被用户调用的。由oracle内置的一些事件根据需要启动该进程，该进程用来将脏数据块写入磁盘上的数据文件。LRU表示LeastRece
21、ntlyUsed，也就是指最近最少使用的bufferheader链表。LRU链表串连起来的bufferheader都指向可用数据块。而LRUW则表示LeastRecentlyUsedWrite，也叫做dirtylist，也就是脏数据块链表，LRUW串起来的都是修改过但是还没有写入数据文件的内存数据块所对应的bufferheader。某个bufferheader要么挂在LRU上，要么挂在LRUW上，不能同时挂在这两个链表上。第21页/共84页随着硬件技术的发展，电脑的内存越来越大。buffercache也是越来越大，只用一条LRU和一条LRUW来管理bufferheader已经不够用了。同时or
22、acle还引入了多个DBWR后台进程来帮助将buffercache中的脏数据块写入数据文件，显然，多个DBWR后台进程都去扫描相同的LRUW链表会引起争用。为此oracle引入了workingset的概念。每个workingset都具有它自己的一组LRU和LRUW链表。每个workingset都由一个名为“cachebufferslruchain”的latch（也叫做lrulatch）来管理，所以从这个意义上说，每一个lrulatch就是一个workingset。而每个被加载到buffercache的bufferheader都以轮询的方式挂到workingset上去。也就是说，当bufferc
23、ache加载一个新的数据块时，其对应的bufferheader会去找一个可用的lrulatch，如果没有找到，则再找下一个lrulatch，直到找到为止。如果轮询完所有的lrulatch也没能找到可用的lrulatch，该进程只有等待latchfree等待事件，同时出现在v$session_wait中，并增加“latchmisses”。如果启用了多个DBWR后台进程的话，每个DBWR进程都会对应一个不同的workingset，而且每个DBWR只会处理分配给它的workingset，不会处理其他的workingset。我们已经知道一个lrulatch就是一个workingset，那么workin
24、gset的数量也就是lrulatch的数量。而lrulatch的数量是由一个隐藏参数：_db_block_lru_latches决定的。该参数缺省值为DBWR进程的数量8。该参数最小必须为8，如果强行设置比8小的数值，oracle将忽略你设置的值，而使用8作为该参数值。第22页/共84页我们已经知道LRU链表是用来查找可以重用的内存数据块的，那么oracle是怎么使用LRU链表的呢？这里需要分为8i之前和8i以后两种情况。在8i之前，我们举一个例子。假设buffercache只能容纳4个数据块，同时只有一个hashchain和一个LRU。当数据库刚刚启动，buffercache是空的。这时前台
25、进程发出SELECT语句获取数据块时，oracle找一个空的内存数据块，并将其对应的bufferheader挂到hashchain上。同时，oracle还会把该bufferheader挂到LRU的最尾端。随后前台进程又发出SELECT语句，这时所找到的bufferheader在LRU上会挂到前一个bufferheader的后面，也就是说第二次SELECT语句所找到的bufferheader现在变成了LRU的最尾端了。假设发出4句SELECT以后找到了4个bufferheader，从而用完了所有的buffercache空间。这个时候的LRU可以用下图来表示。第23页/共84页这个时候，发来了第五
26、句SELECT语句。这时的buffercache里已经没有空的内存数据块了。但是既然需要容纳下第五个数据块，就必然需要找一个可以被替换（后面会看到类似牺牲、重用的字样，它们和替换都是一个意思）的内存数据块。这个内存数据块会到LRU上去找。按照oracle设定的最近最少使用的原则，位于LRU最尾端的BH1将成为牺牲者，oracle会把该BH1对应的内存数据块的内容清空，并将当前第五句SQL所获得的数据块的内容拷贝进去。这个时候，BH1就成了LRU的首端，而BH2则成为了LRU的尾端。如下图所示。在这种方式下，经常被访问的数据块可以一直靠近LRU的首端，也就保证了这些数据块可以尽可能的不被替换掉，
27、从而保证了访问的效率。第24页/共84页到了8i以后，oracle引入了一种更加复杂的机制来管理LRU上的数据块。8i以后，LRU和LRUW链表都具有两个子链表，分别叫做辅助链表和主链表。同时还对bufferheader增加了一个属性：touch数量，也就是每个bufferheader曾经被访问过的次数，来对LRU链表进行管理。oracle每访问一次bufferheader，就会将该bufferheader上的touch数量增加1，因此，touch数量“近似”的体现了某个内存数据块总共被访问的次数。注意，这只是近似，并不精确。因为touch的增加并没有使用latch来管理并发性。这只是一个大概
28、值，表示趋势的，不用百分百的精确。还是用上面的这个例子来说明。还是假设buffercache只能容纳4个数据块，同时只有一个hashchain和一个LRU（确切的说应该是一对LRU主链表和辅助链表）。读入第一个数据块时，该数据块对应的bufferheader会挂到LRU辅助链表（注意，这里是辅助链表，而不是主链表）的最末端，同时touch数量为1。读取第二个不同的数据块时，该数据块对应的bufferheader会挂到前一个bufferheader的后面，从而位于LRU辅助链表的最末端，同样touch为1。假设4个数据块全都用完以后的LRU链表可以用下图四描述。每个bufferheader的to
29、uch数量都为1。BH1T1BH4T1第25页/共84页从上图中我们可以看到辅助LRU链表都挂满了，而主LRU链表还是空的。这个时候，前台发出第五句SQL语句，要求返回指定的数据块。这时，oracle发现buffercache里已经没有空的内存数据块了，于是从辅助LRU链表的尾部开始扫描，也就是从BH1开始扫描，以查找可以被替代的数据块。扫描的过程中按照下面的逻辑来选择被牺牲的（也就是可以被替代的）数据块：1)如果被扫描到的bufferheader的touch数量小于隐藏参数_db_aging_hot_criteria（该参数缺省为2）的值，则选中该bufferheader作为牺牲者，并立即返
30、回该bufferheader所含有的数据块的地址。2)如果当前bufferheader的touch数量大于_db_aging_hot_criteria的值，则不会使用该bufferheader。但是如果当前的_db_aging_stay_count的值小于_db_aging_hot_criteria的值，则会将当前该bufferheader的touch值赋值给_db_aging_stay_count；否则将当前bufferheader的touch数量减掉一半。按照上述的逻辑，这时将选出BH1作为牺牲者（因为BH1的touch数量为1，小于_db_aging_hot_criteria的值），并将
31、其对应的内存数据块的内容清空，同时将当前第五个数据块的内容拷贝进去。但是这里要注意，这个时候该BH1在LRU链表上的位置并不会发生任何的变化。而不会像8i之前的那样，BH1变成LRU链表的首端。第26页/共84页接下来，前台发来了第六句和第七句SQL，分别要返回与第五句和第四句SQL一样的数据块，也就是要返回当前的BH1和BH4。这个时候，oracle会增加BH1和BH4的touch数量，同时将该BH1和BH4从辅助LRU链表上摘下，转移到主LRU链表的中间位置。可以用下图描述。这个时候，如果发来了第八句SQL，要求返回与第三句SQL相同的数据块，也就是当前的BH3，则这时该BH3会插入主LR
32、U链表上的BH1和BH4中间，注意每次向主LRU列表插入bufferheader时都是向中间位置插入。如果发来了第九句SQL要求返回BH2，则我们可以知道，BH2会转移到主LRU链表的中间。这个时候，辅助LRU链表就空了，没有bufferheader了。第27页/共84页这时，如果又发来第十句SQL，要求返回一个新的、buffercache中不存在的数据块时。oracle会先扫描辅助LRU链表，发现上面没有任何的bufferheader时，则必须扫描主LRU链表。从尾部开始扫描，采用前面说到的与扫描辅助LRU链表相同的规则挑选牺牲者。挑出的可以被替代的bufferheader将从主LRU链表上
33、摘下，放入辅助LRU链表。从上面所描述的bufferheader在辅助LRU链表和主LRU链表之间交替的过程中，我们可以看出，oracle改进LRU链表的管理方式的目的，就是想千方百计的能够将多次被访问的数据块保留在内存里，同时又要平衡有限的内存资源。这种方式相比较8i之前而言，无疑是进步很多的。在8i之前中，某个数据块可能只会被访问一次，但是就这么一次的访问就将该数据块放到了LRU的首端，从而可能就挤掉了一个LRU上不是那么经常被访问，但是也会多次访问的数据块。而8i以后，将访问一次的数据块和访问一次以上的数据块彻底分开，而且查找可用数据块时，始终都是从辅助LRU链表开始扫描。实际上也就使得
34、越倾向于只访问一次的数据块越快的从内存中清理出去。第28页/共84页LRUW链表管理从前面我们已经知道SELECT语句读取数据块到buffercache的过程。那么我们必然会产生另外一个疑问，就是当使用DML等语句修改了buffercache里的内存数据块以后的过程是怎样的？实际上，为了能够最有效、安全的完成将内存数据块写入数据文件的过程，oracle提供了比读取数据块更为复杂的机制。我们已经知道LRUW表示脏数据块链表，该链表上的bufferheader指向的都是已经从LRU链表上摘下来、其对应的内存数据块里的内容已经被修改、但是还没有被写入数据文件的内存数据块。在这些脏数据块在能够被重用之
35、前，它们必须要被DBWR写入磁盘。从8i以后，LRUW链表同样包含两个子链表：辅助LRUW链表和主LRUW链表。那么LRUW链表是如何产生bufferheader的呢？oracle又是如何对其进行管理的呢？第29页/共84页我们还是接着上面图所示的例子来说明。假设这个时候，前台用户发出DML语句，要求修改BH2所指向的内存数据块。这时，按顺序发生下面的动作：1)oracle会将BH2从辅助LRU链表上摘下，同时插入主LRU链表的中间，也就是插入BH1和BH4中间，同时增加BH2的touch的数量。2)将该BH2的标记设置为钉住（ping）。3)更新BH2对应的内存数据块的内容。4)更新完以后，
36、取消钉住的标记。5)将BH2从主LRU链表转移到主LRUW链表上。6)如果这个时候又有进程发出更新BH2所对应的内存数据块的内容，则BH2再次被钉住，更新，取消钉住。7)DBWR启动以后，在扫描主LRUW链表时会将BH2转移到辅助LRUW链表上。8)DBWR将辅助LRUW链表上的BH2对应的数据块写入数据文件。9)确认成功写入数据文件以后，将BH2从辅助LRUW链表上转移到辅助LRU链表上。第30页/共84页从上面的描述中，我们可以看到，主LRUW链表上包含的bufferheader要么是已经更新完了的数据块，要么是被钉住正在更新的数据块。而当DBWR进程启动以后，它会扫描主LRUW链表，并跳
37、过正在被钉住更新的bufferheader，而将已经更新完了的bufferheader从主LRUW链表上摘除，并转移到辅助LRUW链表上去。扫描完主LRUW链表，或扫描的bufferheader的个数达到一定限度时，DBWR会转到辅助LRUW上，将上面的bufferheader所对应的数据块写入数据文件。所以说，对于辅助链表上的bufferheader来说，要么是正在等待被写入的；要么就是已经发出写入请求，正在写入而还没写完的。这里要注意的是，bufferheader进入LRUW链表，是从尾端进入；而DBWR扫描LRUW链表时，则是从首端开始。第31页/共84页顺带提一句，这里将主LRUW链表
38、和辅助LRUW链表分开，主要就是为了提高DBWR在主LRUW链表上扫描的效率。如果只有主LRUW链表而没有辅助LRUW链表的话，势必造成三种类型bufferheader交织在LRUW链表上：1）正在被钉住更新的bufferheader；2）已经更新完，而正在等待被写入数据文件的bufferheader；3）已经发出写请求，正在写而尚未写完的bufferheader。在这种情况下，必然造成DBWR为了找到第二种类型的bufferheader而需要扫描不该扫描的第三种类型的bufferheader。第32页/共84页DBWR进程我们已经知道DBWR进程负责将脏数据块写入磁盘。它是一个非常重要的进程
39、。selectc.sid,a.name,a.descriptionfromv$bgprocessa,v$processb,v$sessioncwherea.paddr=b.addrandb.addr=c.paddr;第33页/共84页随着内存的不断增加，1个DBWR进程可能不够用了。所以从8i起，我们可以为系统配置多个DBWR进程。初始化参数：db_writer_processe决定了启动多少个DBWR进程。每个DBWR进程都会分配一个lrulatch，也就是说每个DBWR进程对应一个workingset。因此oracle建议配置的DBWR进程的数量应该等于lrulatch的数量，同时应该小于
40、CPU的数量。系统启动时，就确定好了workingset与DBWR进程的对应关系，每个DBWR进程只会将分配给自己的workingset上的脏数据块写入数据文件。注意:每个latch对应多个lruchain.第34页/共84页DBWR作为一个后台进程，只有在某些条件满足了才会触发。这些条件包括：1)当进程在辅助LRU链表和主LRU链表上扫描以查找可以覆盖的bufferheader时，如果已经扫描的bufferheader的数量到达一定的限度（由隐藏参数：_db_block_max_scan_pct决定）时，触发DBWR进程。_db_block_max_scan_pct表示已经扫描的buffer
41、header的个数占整个LRU链表上bufferheader总数的百分比。这时，搜索可用bufferheader的进程挂起，在v$session_wait中表现为等待“freebufferwait”事件，同时增加v$sysstat中的“dirtybuffersinspected”的值。2)当DBWR在主LRUW链表上查找已经更新完而正在等待被写入数据文件的bufferheader时，如果找到的bufferheader的数量超过一定限度（由隐藏参数：_db_writer_scan_depth_pct决定）时，DBWR就不再继续往下扫描了，而转到辅助LRUW链表上将其上的脏数据块写入数据文件。_d
42、b_writer_scan_depth_pct表示已经扫描的脏数据块的个数占整个主LRUW链表上bufferheader总数的百分比。第35页/共84页3)如果主LRUW链表和辅助LRUW链表上的脏数据块的总数超过一定限度，也将触发DBWR进程。该限度由隐藏参数：_db_large_dirty_queue决定。4)发生增量检查点（incrementalcheckpoint）或完全检查点（completecheckpoint）时触发DBWR。5)每隔三秒钟启动一次DBWR。6)将表空间设置为离线（offline）状态时触发DBWR。7)发出命令：altertablespacebeginbacku
43、p，从而将表空间设置为热备份状态时触发DBWR。8)将表空间设置为只读状态时，触发DBWR。9)删除对象时（比如删除某个表）会触发DBWR。第36页/共84页当DBWR要写脏数据块时，并不是说立即将所有的脏数据块都同时写入磁盘。为了尽量减少物理的I/O的次数，DBWR会将要写的脏数据块所对应的bufferheader拷贝到一个名为批量写（writebatch）的结构中。每个workingset所对应的DBWR进程都可以向该结构里拷贝bufferheader。当writebatch的bufferheader的个数达到一定限额时，才会发生实际的I/O，从而将脏数据块写入磁盘。这个限额为硬件平台所能
44、支持的同时并发的异步I/O的最大数量。8i之前是可以用隐藏参数（_db_block_write_batch）来控制这个限额的。但是8i以后，取消了该参数，而由oracle自己来计算。第37页/共84页DBWR、CKPT、LGWR进程之间的合作将内存数据块写入数据文件实在是一个相当复杂的过程，在这个过程中，首先要保证安全。所谓安全，就是在写的过程中，一旦发生实例崩溃，要有一套完整的机制能够保证用户已经提交的数据不会丢失；其次，在保证安全的基础上，要尽可能的提高效率。众所周知，I/O操作是最昂贵的操作，所以应该尽可能的将脏数据块收集到一定程度以后，再批量写入磁盘中。直观上最简单的解决方法就是，每当
45、用户提交的时候就将所改变的内存数据块交给DBWR，由其写入数据文件。这样的话，一定能够保证提交的数据不会丢失。但是这种方式效率最为低下，在高并发环境中，一定会引起I/O方面的争用。oracle当然不会采用这种没有扩展性的方式。oracle引入了CKPT和LGWR这两个后台进程，这两个进程与DBWR进程互相合作，提供了既安全又高效的写脏数据块的解决方法。第38页/共84页用户进程每次修改内存数据块时，都会在日志缓冲区（redobuffer）中构造一个相应的重做条目（redoentry），该重做条目描述了被修改的数据块在修改之前和修改之后的值。而LGWR进程则负责将这些重做条目写入联机日志文件。只
46、要重做条目进入了联机日志文件，那么数据的安全就有保障了，否则这些数据都是有安全隐患的。LGWR是一个必须和前台用户进程通信的进程。LGWR承担了维护系统数据完整性的任务，它保证了数据在任何情况下都不会丢失。LGWR将重做条目写入联机日志文件的情况分两种：后台写（backgroundwrite）和同步写（syncwrite）。触发后台写的条件有四个：1）每隔三秒钟，LGWR启动一次；2）在DBWR启动时，如果发现脏数据块所对应的重做条目还没有写入联机日志文件，则DBWR触发LGWR进程并等待LRWR写完以后才会继续；3）重做条目的数量达到整个日志缓冲区的1/3时，触发LGWR；4）重做条目的数量
47、达到1MB时，触发LGWR。而触发同步写的条件就一个：当用户提交（commit）时，触发LGWR。第39页/共84页假如DBWR在写脏数据块的过程中，突然发生实例崩溃。我们已经知道，用户提交时，oracle是不一定会把提交的数据块写入数据文件的。那么实例崩溃时，必然会有一些已经提交但是还没有被写入数据文件的内存数据块丢失了。当实例再次启动时，oracle需要利用日志文件中记录的重做条目在buffercache中重新构造出被丢失的数据块，从而完成前滚和回滚的工作，并将丢失的数据块找回来。于是这里就存在一个问题，就是oracle在日志文件中找重做条目时，到底应该找哪些重做条目？换句话说，应该在日志
48、文件中从哪个起点开始往后应用重做条目？注意，这里所指的日志文件可能不止一个日志文件。因为oracle需要随时预防可能的实例崩溃现象，所以oracle在数据库的正常运行过程中，会不断的定位这个起点，以便在不可预期的实例崩溃中能够最有效的保护并恢复数据。同时，这个起点的选择非常有讲究。首先，这个起点不能太靠前，太靠前意味着要处理很多的重做条目，这样会导致实例再次启动时所进行的恢复的时间太长；其次，这个起点也不能太靠后，太靠后说明只有很少的脏数据块没有被写入数据文件，也就是说前面已经有很多脏数据块被写入了数据文件，那也就意味着只有在DBWR启动的很频繁的情况下，才能使得buffercache中所残留
49、的脏数据块的数量很少。但很明显，DBWR启动的越频繁，那么所占用的写数据文件的I/O就越严重，那么留给其他操作（比如读取buffercache中不存在的数据块等）的I/O资源就越少。这显然也是不合理的。第40页/共84页从这里也可以看出，这个起点实际上说明了，在日志文件中位于这个起点之前的重做条目所对应的在buffercache中的脏数据块已经被写入了数据文件，从而在实例崩溃以后的恢复中不需要去考虑。而这个起点以后的重做条目所对应的脏数据块实际还没有被写入数据文件，如果在实例崩溃以后的恢复中，需要从这个起点开始往后，依次取出日志文件中的重做条目进行恢复。考虑到目前的内存容量越来越大，buffe
50、rcache也越来越大，buffercache中包含几百万个内存数据块也是很正常的现象的前提下，如何才能最有效的来定位这个起点呢？第41页/共84页为了能够最佳的确定这个起点，oracle引入了名为CKPT的后台进程，通常也叫作检查点进程（checkpointprocess）。这个进程与DBWR共同合作，从而确定这个起点。同时，这个起点也有一个专门的名字，叫做检查点位置（checkpointposition）。oracle为了在检查点的算法上更加的具有可扩展性（也就是为了能够在巨大的buffercache下依然有效工作），引入了检查点队列（checkpointqueue），该队列上串起来的都是