+++++buffer cache 深度解析(11) _链表

我们用一个简单的例子来描述这个过程。假设系统中发生了一系列的事务，导致日志文件如下所示：
【+++++buffer cache 深度解析】事务号数据文件号block号行号列值RBAT182510110101T17623122a102T3880563b103T39981247e104T57623133abc105Commit SCN#timestamp106T12388763221089107
这时，对应的检查点队列则类似如下图六所示。我们可以看到，T1事务最先发生，所以位于检查点
图六
队列的首端，而事务T123最后发生，所以位于靠近尾端的地方。同时，可以看到事务T1和T5都更新了7号数据文件的623号数据块。而在检查点队列上只会记录该数据块的第一次被更新时的RBA，也就是事务T1对应的，而事务T5对应的并不会被记录。因为根本就不需要在检查点队列上记录。当DBWR写数据块的时候，在写时，自然就把所修改的内容写入数据文件了。日志文件中所记录的提交标记也不会体现在检查点队列上，因为提交本身只是一个标记而已，不会涉及到修改数据块。
这时，假设发生三秒钟超时，于是增量检查点启动。增量检查点会将检查点队列的第一个脏数据块所对应的RBA记录到控制文件中去。在这里，也就是会作为记录到控制文件中。
然后，DBWR后台进程被某种条件触发而启动。DBWR根据一系列参数及规则，计算出应该写的脏数据块的数量，从而将到之间的这5个脏数据块写入数据文件，并在写完以后将这5个脏数据块从检查点队列上摘除，而留下了4个脏数据块在检查点队列上。如果在写这5个脏数据块的过程中发生实例崩溃，则下次实例启动时，会从开始应用日志文件中的重做条目。
图七
而在9i以后，在DBWR写完这5个脏数据块以后，还会在日志文件中记录所写的脏数据块的块号。如下图所示。这主要是为了在恢复时加快恢复的速度。
图八
这时，又发生三秒钟超时，于是增量检查点启动。这时它发现为，于是将写入控制文件。如果接着发生实例崩溃，则在下次启动时，就会从开始应用日志。(待续..........)
4.cache的优化
4.1cache的设置优化
cache的设置随着版本的升级而不断变化。8i下使用来设置，该参数表示 cache中所能够包含的内存数据块的个数；9i以后使用来设置，该参数表示 cache的总共的容量，可以用字节、K、M为单位来进行设置。而到了10g以后则更加简单，甚至可以不用去单独设置 cache的大小。因为10g引入了ASMM（）这样一个可以进行自我调整的组件，该组件可以自动调整 pool size、db cache size等SGA中的组件。只需要设置参数，则其他组件就能够根据系统的负载和历史信息自动的调整各个部分的大小。要启动ASMM，只需要设置为或all 。
.0以前只能设置一种 cache，而从8.0以后，提供了三种类型的 cache，分别是、keep、。keep和是可选的，必须存在。8i以前使用设置、设置keep、设置。

文章插图
而8i以后使用设置、
设置keep、
e设置。
10g不能自动设置和e，必须手工设置。
同时，8i以前，这三种 cache是独立指定的，互不制约。而8i以后，这三种 cache是有相互制约关系的。如果指定了keep和的 cache，则类型的 cache的大小就是 --。
通常将经常访问的对象放入keep类型的 cache里，而将不常访问的大表放入类型的 cache里。其他没有指定 cache类型的对象都将进入类型的 cache里。为对象指定 cache类型的方法如下：
SQL> create table test (n number) storage (buffer_pool keep);SQL> alter table test storage (buffer_pool recycle);
如果没有指定短语，则表示该对象进入类型的 cache 。