select命令产生redo日志问题的分析

近期，某用户在进行SQL优化时，通过sqlplus的set autotrace on命令跟踪SQL执行情况时，发现这条SELECT命令竟然也产生了REDO日志；与我们通常理解的DML/DDL语句才产生REDO日志的认识存在差异~

对ORACLE数据库的特性了解比较清楚的话，特别是数据块、事务处理方面有较深入学习理解，会知道ORACLE数据库的事务、数据块中ITL事务槽的一些原理、结构信息；会知道一个概念叫“延迟块清除”--delayed block cleanout，在约9年前我在学习了解这一块知识时，对相关概念原理进行总结并进行了测试，可以查看当时的BLOG:关于延迟块清除的概念及实验_还不算晕的博客-CSDN博客

简单说就是：

在大事务时可能会操作很多数据块；而BUFFER CACHE中被修改的脏数据写入数据文件中的时机不是COMMIT而是DBWR按规则进行的；所以存在事务相关的数据块先被刷出了 buffer cache，而此时COMMIT还未执行。

当本次事务COMMIT提交后，事务相关的data block ,undo block 上的事务信息，锁信息不会被清除。
当下一次数据块读取到buffer cache（可能是SELECT读取或其它DML）， oracle在读取这类数据块时作事务信息、锁信息的清除处理。

Statistics
----------------------------------------------------------
        105  recursive calls
          0  db block gets
    1343685  consistent gets
     550158  physical reads
      28532  redo size   ====>>>> SELECT时产生的REDO
       2940  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
         11  sorts (memory)
          0  sorts (disk)
         15  rows processed