log buffer及日志管理深入分析及性能调整（五）

3. log buffer的优化

我们一般不太会关注日志缓冲区的优化。这是因为日志缓冲区的争用一般不会是数据库的主要性能问题。前面我们已经知道，日志块的都是按照顺序往里写，不存在更新日志块的以前的内容，同时每个日志块大小都很小，所以几乎不会有多个进程抢同一个日志块的情况。其争用主要是进程由于找不到可用的日志块而必须等待的情况。而我们知道LGWR负责释放脏的日志块从而提供可用日志块，LGWR在日志缓冲区中的脏日志块超过1M或者超过日志缓冲区的1/3时就会启动，而且在将重做记录写入联机日志文件时，都是按照顺序写入，不存在类似DBWR的随机写入，所以写入的速度是非常快的，除非硬盘的I/O速度有很大的问题。可以执行下面的SQL语句来判断硬盘的I/O是否过慢。

SQL > select total_waits,time_waited,average_wait,time_waited/total_waits as avg

 2 from v$system_event where event = 'log file parallel write';

TOTAL_WAITS TIME_WAITED AVERAGE_WAIT       AVG

----------- ----------- ------------ ----------

 314346633  129581305           0 .41222425

我们可以看到，AVERAGE_WAIT表示LGWR完成一次写入平均需要多少时间，是用等待时间除以等待次数得出的、并四舍五入以后得到的平均值（AVG是没有四舍五入以后的值）。如果AVERAGE_WAIT大于1，就表示硬盘的I/O比较慢。

不过，对于整个数据库的健康检查来说，还是需要衡量一下数据库的日志缓冲区是否存在健康隐患。所以也还是需要了解一些有关日志缓冲区性能的一些指标。

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

             我们可以看到有些统计信息发生了变化，而有些则没有。这些统计信息都是累计值，自从实例启动以

来就一直累加而产生的。我们依次解释一些重要的统计信息。

<!--[if !supportLists]--&gt1)     <!--[endif]--&gtredo 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）。

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

<!--[if !supportLists]--&gt3)     <!--[endif]--&gtredo 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在记录日志方面，确实是比较消耗磁盘空间的。所以对于更新频繁的系统而言，产生的日志量会非常大。

<!--[if !supportLists]--&gt4)     <!--[endif]--&gtredo 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就表示日志切换的总次数。

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

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

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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/751371/viewspace-567587/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/751371/viewspace-567587/