延迟块清除导致rac节点传输undo header块

来源：这里教程网时间：2026-03-03 16:57:00 作者：

节点1	1）创建表及索引，并插入数据：create table cwdtest.tab91 (id number,name varchar2(100),created date); create index cwdtest.idx_tab91_01 on cwdtest.tab91(id) pctfree 0; 2）节点1 进行update: SYS@t1nnps1> update cwdtest.tab91 set id=id+1; 100 rows updated. 3)此时能看到buffer中存在存放表及索引的数据块，其master节点是1，owner节点是1。 4）此时先刷新buffer cache后再commit。 alter system flush buffer_cache; commit;
节点2	开启10046：向表中插入一行数据，观察数据块的传输情况，发现只有undo header 增加一次。观察10046情况：其中grant 2-way请求的对象主要是obj#=896778 obj#=896779，他们分别是测试表及索引的块：有一个gc cr block 2-way 的对象号是0，它就是undo header块：
节点1：在节点1将块延迟清除提前	在以上节点1同样的步骤下，再进行对表进行查询，将延迟块清除操作提前，表块与索引块都要被扫描到：此时做一个select 查询，目的是让数据块先做完延迟块清除操作。以下测试了139号块是索引块，必须指定索引查询。 oradebug setmypid oradebug tracefile_name alter system dump datafile 2433 block 139; Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000 0x02 0x0016.00e.0059ab8c 0x01881354.da6f.0f ---- 309 fsc 0x0b49.00000000 ITL中此时的flag是‘----’，表示正处于活动事务，Lock 为309表示锁住309行 select count() from cwdtest.tab91 ; -------------------------------------------------------------------- \| Id \| Operation \| Name \| Rows \| Cost (%CPU)\| Time \| -------------------------------------------------------------------- \| 0 \| SELECT STATEMENT \| \| 1 \| 3 (0)\| 00:00:01 \| \| 1 \| SORT AGGREGATE \| \| 1 \| \| \| \| 2 \| TABLE ACCESS FULL\| TAB91 \| 103 \| 3 (0)\| 00:00:01 \| -------------------------------------------------------------------- Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000 0x02 0x0016.00e.0059ab8c 0x01881354.da6f.0f ---- 309 fsc 0x0b49.00000000 select /+index_ffs(a,idx_tab91_01)*/ count(id) from cwdtest.tab91 a; -------------------------------------------------------------------------------------- \| Id \| Operation \| Name \| Rows \| Bytes \| Cost (%CPU)\| Time \| -------------------------------------------------------------------------------------- \| 0 \| SELECT STATEMENT \| \| 1 \| 13 \| 2 (0)\| 00:00:01 \| \| 1 \| SORT AGGREGATE \| \| 1 \| 13 \| \| \| \| 2 \| INDEX FAST FULL SCAN\| IDX_TAB91_01 \| 103 \| 1339 \| 2 (0)\| 00:00:01 \| -------------------------------------------------------------------------------------- Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000 0x02 0x0016.00e.0059ab8c 0x01881354.da6f.0f C-U- 0 scn 0x0f72.8d4e637b ITL中此时的flag是‘C-U-’，表示事务已经提交，lock也变为0.
节点2：	此时再去节点2插入数据,是不会再去请求undo header块的：