Skip to Main Content
  • Questions
  • Redo Log Buffer Size - why is it 512k?

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Shabbir.

Asked: October 30, 2000 - 1:00 am UTC

Last updated: December 30, 2003 - 10:10 am UTC

Version: 8.0.3

Viewed 1000+ times

You Asked

Hi Tom,

This is what I came across for Oracle 8.0.3 Ent on NT 4.0, SP 4.

The size of the redo log buffer does not change but remains constant at 50K. Whatever value I specify in the parameter file, only 50K is the size that is displayed.

The value specified in the parameter file currently is 164K. When u fire a select on v$parameter, it shows 164 K but on running "show sga" from server manager, it shows 50K.

I even tried with a redo size of 8K as well. But the same thing happens again.

Do get back at the earliest.

The following is the server manager output that u require.

Connected.
SVRMGR> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle8 Release 8.0.3.0.0 - Production
PL/SQL Release 8.0.3.0.0 - Production
CORE Version 4.0.3.0.0 - Production
TNS for 32-bit Windows: Version 8.0.3.0.0 - Production
NLSRTL Version 3.3.0.0.0 - Production
5 rows selected.

SVRMGR> show sga
Total System Global Area 148294072 bytes
Fixed Size 46136 bytes
Variable Size 105780608 bytes
Database Buffers 41943040 bytes
Redo Buffers 524288 bytes

SVRMGR> set charwidth 30
Charwidth 30
SVRMGR> select name, value
2> from v$parameter
3> where name= 'log_buffer';
NAME VALUE
------------------------------ ------------------------------
log_buffer 163840
1 row selected.


One more correction that I would like to make, this is Oracle 8 Std and not Ent as I had mentioned earlier in my query earlier.

Regards,
Shabbir.

and Tom said...

Your redo buffers are 512k, not 50k.

The log_buffer parameter can be set smaller than 512K but
if it is less than a port-specific value then it is increased to
this value. The default minimum is 512K but this can be changed
on a platform basis dependant upon what is felt to be the most
optimum value for the given port. That value is compiled into
Oracle and cannot be changed. On your platform -- it must be
512k.

So, if you set it larger then 512k, you'll see a difference in show SGA. Setting it lower will have no effect.




Rating

  (5 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

help, please

nadya, December 24, 2002 - 8:31 am UTC

How can we know port-specific walue?

Oracle 8.1.6.0.0 Ent on NT 4.0, SP 4.

1. system> show sga

Total System Global Area 67183884 bytes
Fixed Size 70924 bytes
Variable Size 34267136 bytes
Database Buffers 32768000 bytes
Redo Buffers 77824 bytes

2. Init.ora:
log_buffer = 32768 (this value was suggested Oracle during installation and we agree).

3. system> select * from v$sgastat
2 where name='log_buffer';

POOL NAME BYTES
----------- -------------------------- ----------
log_buffer 66560

4. system> select name,value from v$sga where name='Redo Buffers';

NAME VALUE
-------------------- ----------
Redo Buffers 77824
5. system> select value from v$parameter where
2 name='log_buffer';

VALUE
--------------------------------------------
32768

Why Redo Buffers=77824 bytes, not 512K, as documented?
And what does this strange number 32768 mean?



Tom Kyte
December 24, 2002 - 8:42 am UTC

You now know what the port specific minimum is -- you just found it. 

32768 is not a "strange" number -- it is 32K


ops$tkyte@ORA920> select 32768/1024 from dual;

32768/1024
----------
        32

and the other numbers are also kbytes:

ops$tkyte@ORA920> select 66560/1024, 77824/1024 from dual;

66560/1024 77824/1024
---------- ----------
        65         76


Apparently, the smallest you are going to make your redo log buffers in that version of Oracle will be 76K


 

Thanks

Nadya, December 25, 2002 - 1:06 am UTC

Tom, thanks for your help,
I realize, of cource, that 77 824 bytes=76K and so on,
but I was confused because the discription of parameter
log_buffer is "....Default Value : Maximum 500K or 128K * CPU_COUNT, whichever is greater". We have one CPU, so I expected to see the default value 500K, not 76K.



Tom Kyte
December 25, 2002 - 8:37 am UTC

but you set it to 32k -- hence the default value is meaningless here in this context. You overrode the default, with a value that is too small -- so we simply increased to the minimum allowed on your platform.

Reader

A reader, December 28, 2002 - 11:33 am UTC

Tom,

The difference of 76 - 65 = 11k. Is the 11k blocks used
to protect log_buffer from corruption. If so , what is the
s/w logic used, so that the log_buffer corruption is
prevented in certain scenarios

Thanks

Tom Kyte
December 28, 2002 - 11:48 am UTC

some things are just rounded up (especially in 9i) but there are also "guard" pages.

A number of the Oracle Database ports attempt to protect these global regions
(particularly the log buffer) from erroronious access by stray pointers (e.g.
pointers writing past the end of a valid region) using a guard page above and
below the region.

About log_buffer

Bobby, December 30, 2003 - 1:05 am UTC

In the below example (taken from previous question)
select * from v$sgastat where name='log_buffer';

POOL NAME BYTES
----------- -------------------------- ----------
log_buffer 66560

select value from v$parameter where name='log_buffer';

VALUE
--------------------------------------------
32768

Why is value from v$parameter is different from v$sgastat ?

Tom Kyte
December 30, 2003 - 10:10 am UTC

because we impose OS specific minimums on log_buffer.

(see original answer to this question!)

CPU_COUNT

Bobby, December 30, 2003 - 1:14 am UTC

Hi,
Is there any way to find out CPU_COUNT from any of the v$ views ?

Tom Kyte
December 30, 2003 - 10:10 am UTC

ops$tkyte@ORA9IR2> show parameter cpu_count;
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cpu_count                            integer     1
ops$tkyte@ORA9IR2> select value from v$parameter where name = 'cpu_count';
 
VALUE
----------------------
1