一. Block Cleanout 说明
文章的整理参考：http://www.orawh.com/60.html
之前的相关测试参考：
OraceITL(Interested Transaction List) 说明
http://blog.csdn.net/tianlesoftware/article/details/6573988
OracleBlock scn/commit scn/cleanout scn 说明
http://blog.csdn.net/tianlesoftware/article/details/6660530
block clean out 是指把一个块中的数据从 dirty 变为 clean，等于告诉后面的人，这个块里面的数据是干净的，可以放心的使用，本质上是更改 block header 中的一个标志位。
当commit 的时候，如果被commit 的数据块还在 data buffer 中也要被cleanout，因为 commit 的时候并不一定修改block header (delay block cleanout) 。
Clean out有2种: fast commitcleanout和delayed blockcleanout：
oracle有一个modified block list结构，用来记录每个transaction更改过的block，每个transaction大约可以记录10%buffer cache这多的modified block。这部分block就是当发生commit的时候，oracle可以根据modified block list定位到那些块并做fast commit cleanout。
如果一个transaction修改的块超过10%buffer cache,那么超过的块就执行delayed block cleanout。当做fast commit cleanout时，oracle不会清理 Row lockslb标志位，ITL lck标志位。
另一种情况是delayed block cleanout，当transaction还未commit或rollback时modified block已经被写回磁盘，当发生commit时oracle并不会把block重新读入做cleanout，这样成本太高.而是把cleanout留到下一次对此块的访问(select,update)时完成。
当delayed cleanout时候如果undo segment header的transaction table slot还没有被覆盖，那么可以找回该事务递交的exact scn，如果slot已经被覆盖（ITL被覆盖），那么将会使用undo segment header中的control scn来做为upper bound scn。
当发生fast commit cleanout，系统将transaction提交时刻的scn作为commit scn，更新block上 itl和undo segment header的Transaction table的slot上的 scn，并修改block scn，三者是一致的。
发生delayed block cleanout的时候，之前的transaction commit更新的只是undo segment header Transactiontable 上的slot scn，而并未做block上的更新，等待下次使用此block的时候，更新block scn和itl状态。block scn和itl的更新又分2种情况：
（1）当不产生slot重用的时候， delayedblock cleanout时，根据Transactiontable里面的信息，更新blockscn和itl上的Scn/Fsc为transaction曾经提交时候的scn。
（2）当产生slot重用的时候，更新对应itl上scn为undo segment 上的control scn，而block scn 为delayed block cleanout发生时刻的scn。
二. Cleanout 测试
2.1 Fast commit cleanout
--创建table并insertinto data
SYS@anqing2(rac2)> create table dvd(idnumber);
Table created.
SYS@anqing2(rac2)> insert into dvdvalues(1);
1 row created.
SYS@anqing2(rac2)> insert into dvdvalues(2);
1 row created.
SYS@anqing2(rac2)> commit;
Commit complete.
SYS@anqing2(rac2)>
--查看table 的block信息
SYS@anqing2(rac2)> Selectdbms_rowid.rowid_block_number(rowid) block,dbms_rowid.rowid_relative_fno(rowid) fileno, ora_rowscn from dvd;
BLOCK FILENO ORA_ROWSCN
---------- ---------- ----------
305914 1 7316063
305914 1 7316063
--更新并提交数据
SYS@anqing2(rac2)> update dvd set id=77where id=1;
1 row updated.
SYS@anqing2(rac2)> commit;
Commit complete.
--Dump block
SYS@anqing2(rac2)> oradebug setmypid
Statement processed.
SYS@anqing2(rac2)> alter system dumpdatafile 1 block 305914;
System altered.
SYS@anqing2(rac2)> oradebugtracefile_name
/u01/app/oracle/admin/anqing/udump/anqing2_ora_31100.trc
Dump 文件的ITL 信息如下：
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0010.011.000003c6 0x01400038.00ae.2d C--- 0 scn 0x0000.006fa25f
0x02 0x0011.01c.000004a9 0x01400070.0111.26 --U- 1 fsc 0x0000.006fa357
此时的操作就是fast commit cleanout，并且该操作不清除lck,lb标志。
2.2 Delayed block cleanout
当我们update 数据之后，并且没有commit，此时我们flush buffer cache，将修改的数据块，flush 到硬盘，那么此时发生的就是delay block cleanout。
SYS@anqing2(rac2)> update dvd set id=168where id=2;
1 row updated.
SYS@anqing2(rac2)> Selectxidusn,xidslot,xidsqn from v$transaction;
XIDUSN XIDSLOT XIDSQN
---------- ---------- ----------
13 15 980
SYS@anqing2(rac2)> alter system flushbuffer_cache;
System altered.
--flush 会把我们之前修改的block 直接flush 到硬盘，虽然我们没有commit。
SYS@anqing2(rac2)> commit;
Commit complete.
--此时我们commit了，正常情况下，会去修改block里的相关SCN。 但是实际上此时Oracle 并没有回去修改这些block，因为再次调用成本太大。 Oracle只更新了undosegment header slot。 当下次再次访问这个block时，在根据undo segment 来更新block scn 和 itl 上的scn。 如果此时对应的undo segment 已经不存在，就会出发ORA-01555,快照过旧的错误。
--此时还没有再次访问之前的block，即没有发生delayedblock clean，我们dump 一下数据块
SYS@anqing2(rac2)> alter system dumpdatafile 1 block 305914;
System altered.
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x000d.00f.000003d4 0x0140002e.00aa.21 ---- 1 fsc 0x0000.00000000
0x02 0x0011.01c.000004a9 0x01400070.0111.26 --U- 1 fsc 0x0000.006fa357
tab 0, row 0, @0x1f9a
tl: 6 fb: --H-FL-- lb: 0x2 cc: 1
col 0: [ 2] c1 4e
tab 0, row 1, @0x1f8d
tl: 7 fb: --H-FL-- lb: 0x1 cc: 1
col 0: [ 3] c2 02 45
--结果是fast commit cleanout
--访问之前之前的block，产生delayedblock cleanout
SYS@anqing2(rac2)> select * from dvd;
ID
----------
77
168
--在次dump block
SYS@anqing2(rac2)> alter system dumpdatafile 1 block 305914;
System altered.
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x000d.00f.000003d4 0x0140002e.00aa.21 C--- 0 scn 0x0000.006fa4e6
0x02 0x0011.01c.000004a9 0x01400070.0111.26 C--- 0 scn 0x0000.006fa357
tab 0, row 0, @0x1f9a
tl: 6 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 2] c1 4e
tab 0, row 1, @0x1f8d
tl: 7 fb: --H-FL-- lb:0x0 cc: 1
col 0: [ 3] c2 02 45
--做了delayed block cleanout之后，itl 变成了SCN。 此时lck,lb标志为都被清零，scn也是从undo segment header transactiontable slot里面得到。如果undosegment header 上的slot被覆盖了，那么会把undo segment 上的control scn拿来当作upper bound scn。
关于上面那段block 的格式，之前整理的一个资料里有说明：
http://blog.csdn.net/tianlesoftware/article/details/6654786
(1) fb :
K = Cluster Key(Flags may change meaning ifthis is set to show HASH cluster)
C = Cluster table member
H = Head piece of row
D = Deleted row
F = First data piece
L = Last data piece
P = First column continues from previous piece
N = Last column continues in next piece
（2）lb : 和上面的 ITL 的lck相对应表示这行是否被 lock 了
在汪海的blog 上，他还测试了另一个结论：
当delayed block cleanout 发生时，依赖与undo segment来保证，如果undo segment 被删除了，那么会Oracle 会使用system 表空间下的undo$ 基表来保证delayed block cleanout。
关于这个测试过程，参考汪海的blog：http://www.orawh.com/60.html
三. Delayed block cleanout 与select redo 说明与测试
一般来说，select 是不会产生redo的。 但如果发生了delayed block cleanout，那么就会产生redo。 当然这只是一种情况，开启审计等，也会造成select 产生redo。
在itpub上有2个相关的链接：
http://www.itpub.net/thread-1467473-1-2.html
http://www.itpub.net/thread-728163-1-1.html
下面我们测试一下。
--先对dvd insert 一些测试数据
SYS@anqing2(rac2)> Declare
2 I number;
3 Begin
4 For I in 1..100 loop
5 Insert into dvd values(i);
End loop;
Commit;
End;
/
6 7 8 9
PL/SQL procedure successfully completed.
SYS@anqing2(rac2)> select count(*) fromdvd;
COUNT(*)
----------
102
--直接select
SYS@anqing2(rac2)> set timing on
SYS@anqing2(rac2)> set autot on stat
SYS@anqing2(rac2)> select count(*) fromdvd;
COUNT(*)
----------
102
Elapsed: 00:00:00.00
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net toclient
400 bytes received via SQL*Netfrom client
2 SQL*Net roundtrips to/fromclient
0 sorts (memory)
0 sorts (disk)
1 rows processed
测试产生的redo 为0.
--制造delayedblock cleanout
SYS@anqing2(rac2)> update dvd set id=0where id>50;
52 rows updated.
Elapsed: 00:00:00.02
Statistics
----------------------------------------------------------
5 recursive calls
52 db block gets
8 consistent gets
0 physical reads
14424 redo size
667 bytes sent via SQL*Net toclient
564 bytes received via SQL*Netfrom client
3 SQL*Net roundtrips to/fromclient
1 sorts (memory)
0 sorts (disk)
52 rows processed
SYS@anqing2(rac2)> alter system flush buffer_cache;
System altered.
Elapsed: 00:00:00.10
SYS@anqing2(rac2)> commit;
Commit complete.
Elapsed: 00:00:00.02
--再此select
SYS@anqing2(rac2)> select count(*) fromdvd;
COUNT(*)
----------
102
Elapsed: 00:00:00.02
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
2 physical reads
116 redo size
412 bytes sent via SQL*Net toclient
400 bytes received via SQL*Netfrom client
2 SQL*Net roundtrips to/fromclient
0 sorts (memory)
0 sorts (disk)
1 rows processed
--第三次select
SYS@anqing2(rac2)> select count(*) fromdvd;
COUNT(*)
----------
102
Elapsed: 00:00:00.00
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net toclient
400 bytes received via SQL*Netfrom client
2 SQL*Net roundtrips to/fromclient
0 sorts (memory)
0 sorts (disk)
1 rows processed
第二次select 因为delayed block cleanout的原因，需要做一些善后工作，所以产生了redo。 当第三次select 时，第二次select 已经把工作做完了，所以没有产生redo。
简单的就是说： select 在delayed block cleanout 时也会产生redo。
-------------------------------------------------------------------------------------------------------
Blog： http://blog.csdn.net/tianlesoftware
Weibo: http://weibo.com/tianlesoftware
Email: dvd.dba@gmail.com
DBA1 群：62697716(满); DBA2 群：62697977(满) DBA3 群：62697850(满)
DBA 超级群：63306533(满); DBA4 群： 83829929(满) DBA5群： 142216823(满)
DBA6 群：158654907(满) 聊天 群：40132017(满) 聊天2群：69087192(满)
--加群需要在备注说明Oracle表空间和数据文件的关系，否则拒绝申请
来源：https://www.cnblogs.com/tianlesoftware/archive/2011/08/05/3609608.html