Oracle Study之案例--延迟块清除（deferred block cleanout）

缺乏、安全感 2022-08-07 10:38 220阅读 0赞

**Oracle Study之案例--延迟块清除（deferred block cleanout）**

在Oracle中数据锁（这里主要指TX类型行锁）实际上是数据的属性，存储在块首部，称之为事务槽(ITL)。COMMIT操作的职责包括释放块上的锁，实际的释放方式即清除块上相应的事务槽，但这里存在一个性能的考量。设想一个UPDATE大量数据的操作，因为执行时间较长，一部分已修改的块已被缓冲池flush out写至磁盘，当UPDATE操作完成执行COMMIT操作时，则需要将那些已写至磁盘的数据块重新读入，这将消耗大量I/O，并使COMMIT操作十分缓慢；为了解决这一矛盾，Oracle使用了延迟块清除的方案，对待存在以下情况的块COMMIT操作不做块清除：

**在更新过程中，被缓冲池flush out写至磁盘的块**

**若更新操作涉及的块超过了块缓冲区缓存的10%时，超出的部分块。**

虽然COMMIT放弃对这些块的块清除(block cleanout)操作，但COMMIT操作仍会修改回滚段的段头，回滚段的段头包括了段中的事务的字典，COMMIT操作将本事务转化为非ACTIVE状态。

当下一次操作如SELECT,UPDATE,INSERT或DELETE访问到这些块时可能需要在读入后完成块清除，这样的操作称之为块延迟清除（deferred block cleanout）；块延迟清除通过事务槽上的回滚段号，槽号等信息访问回滚段头的事务字典，若事务不再活跃或事务过期则完成清除块上的事务槽，事务槽清除后继续执行相应的操作。

块延迟清除的影响在SELECT操作过程中体现的最为明显。总结来说块延迟清除是COMMIT操作的一个延续，始终是一种十分轻微的操作，且该种操作是行级的，不会使段(Segment)的属性有所改变。

**案例分析：**

场景一：  
会话一更新一小表，更新的block数小于db\_block\_buffers\*10%，当会话一进行commit时，更新的block还存在于buffer cache中。  
由于更新的块数较少，Oracle采用SO（state block）列表来管理更新块。SO主要包括了更新块的事物状态信息。  
当会话一进行提交时，会从SO列表中获取更新块的事物信息，从而进行更新块的事物信息清理。清理主要包括块头itl状态列的更新（Flag，Lck ，Scn/Fsc）和行锁标记的清理。Oracle对于这种块清理称之为快速块清理。（Fast Block Cleanout）。  
发生延迟块清除后，块头的Flag往往显示如下：  
Itl              Xid                             Uba                              Flag Lck Scn/Fsc  
0x01 0x0009.01f.0000bed8 0x04c00016.13bf.28 --U- 3 fsc 0x0000.063f1a51  
其中U表示upper bound（上界），意味着快速块清除。  
场景二：  
会话一更新一大表，更新的blocks数大于db\_block\_buffers\*10%，当会话一进行commit前，部分更新的block由于种种原因已经刷新至至数据文件。  
当会话进行commit时，Oracle对存在于SO列表的更新块进行快速块清理，同时更新undo segment head中的事物槽（将事物槽state标记从10置回9，表示该事务已经提交）。  
但需要注意的是，Oracle在commit时，并不会处理已刷新在数据文件中的block（此时数据块头还flag标记仍然显示未提交状态，Lck依然显示该块中行锁的行数，Scn/Fsc为空，行锁标记依然为lb: 0x2）。  
Oracle采用此方进行提交时，并不需要再次将该事务涉及到的block从物理文件中读取，而只需要进行快速块清理和更新undo segment head中的事物槽即可。从而保证提交的性能最优化。  
当有另一会话再次读取已刷新至数据文件的block时，如果发现此block itl列表有未提交事物时，那么Oralce将进行延迟块清除（defered block cleanout）。  
当进行延迟块清除时，Oracle将获取数据块中未提交事物的xid中的seq和undo segment head中事物槽的seq进行比较。  
如例子所示，数据块的ITL显示如下：  
  
ITL Xid Uba Flag Lck Scn/Fsc  
0x01 0x0009.018.0000bdd4 0x04c00016.13a5.32 C-U- 0 scn 0x0a00.063f0838  
0x02 0x0009.01f.0000bed8 0x04c00016.13bf.28 ---- 3 fsc 0x0000.00000000  
  
undo segment head的和此事物相关的事物槽显示如下：  
index state cflags wrap\# uel scn dba  
\---------------------------------------------------------------  
0x1f 9 0x00 0xbed8 0xffff 0x0a00.063f1a51 0x04c00016  
  
undo segment head的事物控制列表如下：  
TRN CTL:: seq: 0x13c0 chd: 0x002d ctl: 0x001f inc: 0x00000000 nfb: 0x0000  
mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)  
uba: 0x04c0000d.13c0.04 scn: 0x0a00.063f17f1  
事物控制列表中scn主要表示事物槽被覆盖前的scn。  
  
如上所示ITL 0x02中有未提交事物，那么首先会获取0x02事物中xid（回滚段为0x0009，事物槽为0x01f，seq为 0000bed8）和undo segment head对应事物槽比较（主要比较xid.seq和事物槽的wrap\#）。  
  
如果两者相等，那么进行延迟块清除时，Oracle将获取事物槽中的scn写往ITL列表中的Scn/Fsc列。  
如果两者不相等，这里分为两种情况：  
1、undo的事物槽被其他事物覆盖，那么进行延迟块清除时，Oracle将获取undo segment head的事物控制列表的scn写往ITL列表中的Scn/Fsc列。  
这里需要注意的是,此时的scn并不是事物提交时的真正scn，而且肯定比事物提交时的scn大，那这样会不会影响事物一致性呢，接下来例子会进行说明。  
2、undo表空间被删除，此时undo$并不会将此表空间删除，只会将STATUS$从2改为1，而且每个undo segment依然保留着最近一次提交的scn。如下所示  
SQL> select SCNBAS,SCNWRP,STATUS$,file\#,name from undo$;  
  
SCNBAS SCNWRP STATUS$ FILE\# NAME  
\---------- ---------- ---------- ---------- ------------------------------  
258954408 2560 1 13 \_SYSSMU127$  
258954399 2560 1 13 \_SYSSMU128$  
258954395 2560 1 13 \_SYSSMU129$  
258954404 2560 1 13 \_SYSSMU130$  
那么进行延迟块清除时，Oracle会去undo$中对获取对应的undo segment中的scn写往ITL列表中的Scn/Fsc列。  
同样需要注意的是，此时的scn并不一定事物提交时的真正scn，可能会比提交的scn大。发生延迟块清除后，块头的Flag往往显示如下：  
ITL Xid Uba Flag Lck Scn/Fsc  
0x01 0x0009.018.0000bdd4 0x04c00016.13a5.32 C-U- 0 scn 0x0a00.063f0838  
**其中C表示该事物已结束，U表示Upper bound（上界），C-U-往往表示延迟块清除。**