3.1 log buffer的统计信息
    有关log buffer的统计信息，我们都可以从v$sysstat里找到。我们可以运行一个DML语句，然后比较前后的统计信息，看看都发生了哪些变化。

SQL> select name,value from v$sysstat where name like '%redo%' order by name;
NAME VALUE
---------------------------------------------------------------- ---------- 
redo blocks read for recovery 110
redo blocks written 13617
redo buffer allocation retries 0
redo entries 16868
redo log space requests 0
redo log space wait time 0
redo log switch interrupts 0
redo ordering marks 1
redo size 6228264
redo subscn max counts 0
redo synch time 207
redo synch writes 2475
redo wastage 519976
redo write time 1105
redo writer latching time 0
redo writes 1991

SQL> update redo_test set name='cdf' where id=1;
SQL> commit;
SQL> select name,value from v$sysstat where name like '%redo%' order by name;
NAME VALUE
---------------------------------------------------------------- ---------- 
redo blocks read for recovery 110
redo blocks written 13619
redo buffer allocation retries 0
redo entries 16869
redo log space requests 0
redo log space wait time 0
redo log switch interrupts 0
redo ordering marks 1
redo size 6228856
redo subscn max counts 0
redo synch time 207
redo synch writes 2476
redo wastage 520376
redo write time 1105
redo writer latching time 0
redo writes 1992

    我们可以看到有些统计信息发生了变化，而有些则没有。这些统计信息都是累计值，自从实例启动以
来就一直累加而产生的。我们依次解释一些重要的统计信息。

1) redo writes、redo blocks written、redo write time：这三个统计信息是主要的统计信息，在LGWR写完重做记录以后更新，而且只能由LGWR负责更新。redo writes表示写了多少次，我们可以看到上例中写了1次（1992-1991）；redo blocks written表示总共写了多少日志块，可以看到写了2个日志块（13619-13617），由此我们可以知道平均写一次可以写2个日志块。redo write time表示将重做记录写入日志文件花了多少时间，单位是10个毫秒，我们可以看到为了写这2个日志块所需要的时间都几乎为0（1105-1105）。

2) redo size、redo entries：这两个统计信息是在重做记录拷贝到日志缓冲区之前更新的。它们都表示产生了多少量的重做记录，redo size以字节为单位，而redo entries以个数为单位。比如，上例中产生了592（6228856-6228264）个字节的重做记录，共1（16869-16868）个重做记录，平均每个重做记录为592个字节。

3) redo wastage：该记录表示当日志缓冲区的日志块被写入日志文件时，日志块中没有被利用的空间数量，以字节为单位。因为当把重做记录拷贝到日志缓冲区中的日志块时，需要格式化日志块以后才能实际存放日志信息，这样就会“浪费”一些日志缓冲区空间。上例中，我们可以看到为了格式化日志块而浪费了大约400（520376-519976）个字节的空间。

    注意：上例中，我们写了2个日志块（redo blocks written）。我们知道一个日志块的大小是512个字节，那么两个日志块的应该占用1024个字节。但是实际重做记录只占了592个字节（redo size）。其中，为了格式化日志块而“浪费”了400个字节（redo wastage）。同时每个日志块头需要16个字节，两个日志块就是32个字节。那么我们有：592+400+32=1024。这正是两个日志块的容量。由此我们可以推导出这样的公式：“redo blocks written”דredo block size”=16דredo blocks written” + “redo size” + “redo wastage”
由此我们可以看出，oracle为了更新3个字节（'cdf'），需要消耗1024个字节的日志文件的空间。看来oracle在记录日志方面，确实是比较消耗磁盘空间的。所以对于更新频繁的系统而言，产生的日志量会非常大。

4) redo log space requests、redo log space wait time：redo log space requests表示对联机日志文件空间请求的次数，redo log space wait time表示在发出请求空间以后的等待时间。这两个统计信息只有在前台进程请求联机日志文件空间未果的情况下才会增加，这时前台进程等待日志切换完成。在没有人为的发出alter system switch logfile命令的前提下，redo log space requests就表示日志切换的总次数。

5) redo buffer allocation retries：表示再次尝试在日志缓冲区中分配可用空间的次数。当进程第一次没能在日志缓冲区中获得可用空间时，该进程必须等待LGWR刷新日志缓冲区或者等待日志切换完成等，然后会再次尝试获取空间。理想情况下，该统计信息应该为0。

    注意：这里我们可以获得在拷贝到日志块时必须等待的重做记录的数量所占的比例，计算公式为：redo buffer allocation retries / redo entries。该比例应该接近于0，不应大于1%。如果这个值不断变大则说明服务器进程在获得日志块之前必须等待，这时应该增加日志缓冲区，或者提高LGWR写的效率，也就是提高硬盘物理I/O的速度。

6) redo synch writes，redo synch time：这两个统计信息是在用户每次提交（commit）时增加。redo synch writes表示由于提交而刷新日志缓冲区的次数，而redo synch time表示由于提交而刷新日志缓冲区所花的时间，以10个微妙为单位。