在怎樣的條件下，select操作會生成redo資訊

當存在延遲塊清除的時候：
由於資料塊上儲存了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的日誌。