*************************************************************
UPDATE WORK03
SET ENAME = 'haneda'
WHERE EMPNO = 1001 ;
1行更新了。

COMMIT ;
Commit结束。
※ EMPNO尚未创见索引。
*************************************************************

下图显示了一些必须的统计信息，用于确定对REDO日志实际执行的写入量。

这些是累计值，所以必须求出更新前后的差，为了调查写入量所需的统计信息在更新前后的差如下。
1. redo size = 448
2. redo wastage = 544
3. redo blocks written = 2

请先注意看redo blocks written，这里的数据块不是Oracle的数据块，而是OS的数据块，因此512×2，也就是写入了1024byte。接下来，再看看代表实际入的byte数的redo size，结果是448，未满1024。以16进制打开OS上的文件以确定内容，发现数据块里面的确有很多部分并未写入任何东西。

REDO日志文件的16进位表示结果

换句话说，执行写入的时候是以要写到REDO日志文件的格式为基准，所以会有空白部分。redo wastage表示没有写入任何数据的量，至于实际上的写入量则是从redo wastage和redo blocks written求得，结果如下。
1024(redo blocks written)-544(redo wastage)-16(Header)×2(数据块数)=448(redo size)
※在各个数据块的Header分别有16byte的标题信息，所以要除去这个部分。

换句话说，为了更新6byte，结果消耗1K byte的空间，其中有544 byte是因为以512byte为单位执行写入——也就是因为格式原因导致的浪费。以OS的数据块大小为单位(512byte)执行写入可以提高性能。“浪费”的说法也许不是很恰当，但即使采用优先考虑性能的格式执行写入，还是有可以改善的地方的。

下次我们要讨论即使内容完全一样，写入时所需的数据块数也会因为写入REDO日志文件的时间不同而有所改变的现象。