玉面飞龙的BLOG

Oracle10g中的redo log buffer大小不是由参数文件initSID.ora中的log_buffer决定的了。而是由oracle内部的算法计算而出。

From Bug 4592994:

In 10G R2, Oracle combines fixed SGA area and redo buffer [log buffer] together. If there is a free space after Oracle puts the combined buffers into a granule, that space is added to the redo buffer. Thus you see redo buffer has more space as expected. This is an expected behavior.

当数据库升级到10g后,往往会发现log_buffer变大了。但也没有发现大的log_buffer给系统带来什么影响。而且在做要产生很多redo的batch job的时候，大的log-buffer反而能够减少log buffer space等待事件。

最近反而发现一些10g数据库的log buffer”不正常”，如下，明显log_buffer+fix_size << Granule_zie

SQL>  select * from v$sgainfo;

NAME                                  BYTES RES
——————————– ———- —
Fixed SGA Size                      2194776 No
Redo Buffers                        2162688 No
Buffer Cache Size                2.4696E+10 Yes
Shared Pool Size                 3221225472 Yes
Large Pool Size                   402653184 Yes
Java Pool Size                    402653184 Yes
Streams Pool Size                         0 Yes
Granule Size                       67108864 No
Maximum SGA Size                 2.8790E+10 No
Startup overhead in Shared Pool   335544320 No
Startup NUMA Shared Pool memory 603979776 No
Free SGA Memory Available                 0

12 rows selected.

观察该数据库与其他数据库的不同，明显多了个NUMA的设置。

SQL>show parameters numa
NAME                       VALUE              DESCRIPTION
——————————————–
_db_block_numa       3                    Number of NUMA nodes

该参数默认数值和硬件平台有关。在enable NUMA的情况下,log buffer的大小计算不得而知了。