这次会继续说明写入时所需的数据块数会因为写入REDO日志文件的时间不同而有所改变的现象。

──下面举例说明写入时所需的数据块数会因为写入REDO日志文件的时间不同而有所改变的现象──

*************************************************************
※事务1
瞬间执行下面两个UPDATE语句，中间没有间隔。

●SQL语句

Update work03 set ename = 'haneda' where empno = 1002 ;
Update work03 set ename = 'haneda' where empno = 1003 ;
Commit ;

●统计信息(差)
Redo size                    652
Redo wastage                 340
Redo blocks written            2
*************************************************************

事务1是没有间隔的、瞬间对ENAME字段(6byte)执行2个记录的更新，这个处理对磁盘上的在线REDO日志文件执行2个数据块(1K byte)的写入，其中有340 byte因为格式问题而未使用。换句话说，有效的REDO信息只有652byte，以数据块为单位进行写入的时候，因为格式的问题导致340byte变成未使用空间，空间自然有点浪费。 (各个数据块的首部分别容纳了16 byte的Header信息。)看这里的结果应该就能理解为什么对REDO日志执行的写入量很大。

现在我们看看如果和上面处理1更新完全一样的内容，但中间有一定的时间间隔，结果会怎样呢？

*************************************************************
※事务2
执行下列2个UPDATE语句，中间有间隔。

●SQL语句
Update work03 set ename = 'haneda' where empno = 1002 ;
【间隔】
Update work03 set ename = 'haneda' where empno = 1003 ;
Commit ;

●统计信息(差)
Redo size                    652
Redo wastage                 836
Redo blocks written            3
*************************************************************

内容和事务1完全相同，可是Redo wastage和Redo blocks written的值却都增加了，这就说明了写入时所需的数据块数会因为写入REDO日志文件的时间不同而有所改变。之前曾说过，LGWR不是每次发生transaction就会对REDO日志文件执行写入，而是在某些时间启动，其中一个时间就是“上次写入之后经过3秒钟”。

处理1的情况是在上次写入之后3秒之内，创建2个record的更新以及commit的REDO record，所以写入REDO日志文件只用到两个数据块。然而处理2在每个REDO record创建的过程中，产生了间隔，所以即使REDO record尚未全部创建完成，上次的写入已经经过3秒钟，LGWR会把在那之前创建的REDO record写到REDO日志文件中去。结果，本来只需要2个数据块的REDO讯息，因为中途发生写入操作，于是需要新的空间。大致概念如下：

日志管理-10