在怎样的条件下，select操作会生成redo信息

最新推荐文章于 2025-09-14 13:43:51 发布

转载最新推荐文章于 2025-09-14 13:43:51 发布 · 213 阅读

文章标签：

本文通过实验演示了Oracle数据库中的延迟块清除机制。当数据块不在BUFFERCACHE时，提交不会立即进行块清除，而是等到下次访问该数据块时执行，并记录日志。实验显示这种情况下产生了大量日志。

当存在延迟块清除的时候：
由于数据块上存储了ITL事务槽信息与锁定位信息，因此在事务提交后，需要清除。清除的内容主要为在TIL事务槽里记录事务提交标志与提交SCN，清除记录的锁定位信息。
但是ORACLE有一个规则，如果修改的数据块接近BUFFER CACHE的约10%，或者数据块已经不在BUFFER CACHE里了，那么会进行延迟块清除，清除的这个过程也会导致数据块的变化，因此会记录日志。
下面我演示下，数据块已经不在BUFFER CACHE里的情况：
SQL> conn scott/tiger
已连接。
SQL>
SQL> spool d:\\ss.txt
SQL> create table pp as select * from dba_objects;

表已创建。

SQL> insert into pp select * from pp;

已创建49844行。

SQL> /

已创建99688行。

SQL> /

已创建199376行。

SQL> /

已创建398752行。

SQL> /

已创建797504行。

SQL> alter system flush buffer_cache;

系统已更改。

SQL> commit;

提交完成。

SQL> set autotrace trace stat
SQL> select /*+ full(pp) */count(*) from pp;

统计信息
----------------------------------------------------------
      6  recursive calls
      1  db block gets
   43137  consistent gets
   21903  physical reads
1523104  redo size
      411  bytes sent via SQL*Net to client
      385  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      0  sorts (memory)
      0  sorts (disk)
      1  rows processed

从实验可以看出，由于刷新了BUFFER CACHE，导致数据块都不在BUFFER CACHE里了，那么提交的时候就不会去做块清除，等待下一次操作此数据块的时候才进行延迟块清除，此清除会产生日志。这个实验中产生了1523104byte的日志。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22034023/viewspace-662245/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22034023/viewspace-662245/