原文地址:http://yumianfeilong.com/html/2009/04/08/340.html(转自玉面飞龙的博客)
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 012 rows selected.
观察该数据库与其他数据库的不同,明显多了个NUMA的设置。
SQL>show parameters numa
NAME VALUE DESCRIPTION
——————————————–
_db_block_numa 3 Number of NUMA nodes
该参数默认数值和硬件平台有关。在enable NUMA的情况下,log buffer的大小计算不得而知了。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10805681/viewspace-607472/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/10805681/viewspace-607472/