Redo Log Buffer sizing problem

My pc has 512mb RAM and i was trying to increase the redo log buffer size. Initially the log_buffer size was 2899456 bytes. So i tried to increase it to 3099456 by issuing the command:
ALTER SYSTEM SET LOG_BUFFER=3099456 SCOPE=SPFILE;
And i issued SHUTDOWN IMMEDIATE. Upon restarting my database, when i queried SHOW PARAMETERS LOG_BUFFER . The value has been changed to 7029248 bytes not 3099456 which i wanted. How did this happen?

1.) We are all volunteers.
2.) It was only 5 hours between posts and you're complaining that there are no answers?
3.) You didn't bother to mention platform or Oracle version, even after being specifically asked for it? Which part of "What is your Oracle version?" do you not understand? And yes, the platform may be useful too....
From memory, there could a couple of things going on. First off, starting in 9i, Oracle allocates memory in granules, so, allocating chunks smaller than granule size can result in being rounded up to granule size. Second, on some platforms, Oracle protects the redo buffer with "guard pages", i.e., extra memory that serves simply to try to prevent accidental memory overflows from corrupting the redo buffer.
If you want a specific answer, or at least a shot at one, post:
1.) Oracle version (specific version: 8.1.7.4, 9.2.0.8, 10.2.0.3, etc).
2.) Platform
3.) O/S and version
4.) Current SGA size
Reposting the same question, or threatening to do so, will get you nowhere.
-Mark

Similar Messages

To where does the LGWR write information in redo log buffer ?

Suppose my online redo logfiles are based on filesystems .I want to know to where the LGWR writes information in redo log buffer ? Just write to filesystem buffer or directly write to disk ? And the same case is associated with the DBWR and the datafiles are based on filesystems too ?

It depends on the filesytem. Normally there is also a filesystem buffer too, which is where LGWR would write.Yes but a redo log write must always be a physical write.
From http://asktom.oracle.com/pls/ask/f?p=4950:8:15501909858937747903::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:618260965466
Tom, I was thinking of a scenario that sometimes scares me...
**From a database perspective** -- theoretically -- when data is commited it
inevitably goes to the redo log files on disk.
However, there are other layers between the database and the hardware. I mean,
the commited data doesn't go "directly" to disk, because you have "intermediate"
structures like i/o buffers, filesystem buffers, etc.
1) What if you have commited and the redo data has not yet "made it" to the redo
log. In the middle of the way -- while this data is still in the OS cache -- the
OS crashes. So, I think, Oracle is believing the commited data got to the redo
logs -- but is hasn't in fact **from an OS perspective**. It just "disapeared"
while in the OS cache. So redo would be unsusable. Is it a possible scenario ?
the data does go to disk. We (on all os's) use forced IO to ensure this. We
open files for example with O_SYNC -- the os does not return "completed io"
until the data is on disk.
It may not bypass the intermediate caches and such -- but -- it will get written
to disk when we ask it to.
1) that'll not happen. from an os perspective, it did get to disk
Message was edited by:
Pierre Forstmann

What exactly is Redo log buffer?

I know that Redo log buffer is a part of SGA and it sotores each and every change in it. But i want to know whether it stores all the updates and other changes as it is stored in DB Buffer Cache.? Or if not what exactly is sotored in it and when...?
null

Hi,
Redo Log Buffers are part of SGA and they store each and every entry that is made in the DB.
This is also stored in the Redo Log FIles. This information is used during recovery of a Crashed DB.
A Redo Log does not Store the Data but oinly the Stmt. that was executed in the DB.
A DB Buffer Stores data and not the command.
If u need more information Pls Refer to The Oracle 8 Concepts on the Oracle Documentation.
Hope this helps.
Regards,
Ganesh R
null

Buffer, library,dictionary, shared pool, redo log buffer chache hit ratios

Can please one provide information and sql queries to calculate Buffer, library,dictionary, shared pool, redo log buffer chache hit ratios and if any other ratio for investigation of performance issues in oracle 10g database (10g.1 and 10g.2 both). thanks in advance.

In and by themselves most of the standard ratio calculations are useless to misleading. All the ratios should always be considered in relation to other data such as total requests for a resource, existence of any outlying values in the associated events, etc ....
The proper warning being given then you can find most of the standard ratios mentioned with SQL for their calculation in the Performance and Tuning manual for your version of Oracle.
HTH -- Mark D Powell --

Redo log buffer question

hi masters,
this seems to be very basic, but i would like to know internal of this process.
we all know that LGWR writes redo entries to online redo log files on disk. on commit SCN is generated and tagged to transaction. and LGWR writes this to online redo log files.
but my question is, how these redo entries comes to redo log buffer??? look all required data is fetched into buffer cache by server process. it is modified there, and committed. DBWR writes this to datafiles, but at what point, which process writes this committed transaction (i think redo entry) into log buffer cache????
does LGWR do this?? what internally happens exactly???
if you can plz focus some light on internals, i will be thankfull....
thanks and regards
VD

Hi Vikrant,
DBWR writes this to datafiles, but at what point, which process writes this committed transaction (i think redo entry) into log buffer cache????Remember that, Before DBWR Acts on flushing the dirty Blocks to Data files, Before this server process, makes sure that LGWR finishes the writing Redo Log Buffer to Online Redo Log files. Since as per ORACLE Architecture poting of Recovering data till point of time @ Crash is important and this is achieved by Online Redo Logs files.
Rest how the data is Updated in to the Redo Log Buffer Aman had stated the clear steps.
- Pavan Kumar N

High redo log buffer wait

Hi,
I can see "high redo log buffer wait" event. The instance spent 23% of its resources waiting for this event. Any suggestion to tune redo log buffer?
DB version : 10.2.0.4.0
Os : AIX
SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo log space requests';
NAME VALUE
redo log space requests 3542
SQL> sho parameter buffer
NAME TYPE VALUE
buffer_pool_keep string
buffer_pool_recycle string
db_block_buffers integer 0
log_buffer integer 14238720
use_indirect_data_buffers boolean FALSE
SQL> select GROUP#,BYTES from v$log;
GROUP# BYTES
1 1073741824
4 1073741824
3 1073741824
2 1073741824
SQL> show parameter sga
NAME TYPE VALUE
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 5G
sga_target big integer 5G
Thanks

Gowin_dba wrote:
I can see "high redo log buffer wait" event. The instance spent 23% of its resources waiting for this event. Any suggestion to tune redo log buffer?
SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo log space requests';
NAME VALUE
redo log space requests 3542 How are you getting from 3,542 "redo log space requests" to 23% of the instance resources waiting for "high redo log buffer wait" (which is not a wait event that can be found in v$event_name in any version of Oracle) ?
"redo log space requests" is about log FILE space, by the way, not about log BUFFER space.
Regards
Jonathan Lewis

REDO LOG BUFFER

Whenever a DML like Insert statement is issued it gets written to the Database buffer cache first by the server process(dedicated server).
Which process writes this DML activity to the redo log buffer ?
I guess DML is first written to the redolog files and only after that the same DML is committed to the data files.Is this correct ?
Can get any references to read on how any activity/DML is processed with a Oracle architecture perspective.
Thanks

Yes. Only the server process for that session knows what changes were made to the buffer cache. So it is the only one that can write the change vectors to the redo log buffer.
Hemant K Chitale

Where can I find redo log buffer advice

Hi,
Our customer needs the information about redo log buffer. But In administrator--database configuration--memory parameters item of grid control 10g, I can only get the information about buffer cache & shared pool, as well as the corresponding advice. I cannot find information about redo log buffer in this page. I wonder why the information about redo log buffer is not included in this page.Where can I find it?

The Log Buffer is part of your Intialization Parameters.
So, from EM, you can find the information you need when you select the Database > Adminstration > All Initialization Parameters (under Database Configuration)

What does redo log buffer holds, changed value or data block?

Hello Everyone,
i am new to database side and have one query as i know redo log buffer contain change information , my doubt is does it store the value only or the changed data block? because if we can see data buffer cache size is more as it holds data block and redo log buffer size is less .

The Redo Log buffer contains OpCodes that represent the SQL commands, the "address" (file,block,row) where the change is to be made and the nature of the change.
It does NOT contain the data block.
(the one exception is when you run a User Managed Backup with ALTER DATABASE BEGIN BACKUP or ALTER TABLESPACE BEGIN BACKUP : The first time a block is modified when in BEGIN BACKUP mode, the whole block is written to the redo stream).
The log buffer can be and is deliberately smaller than the blocks buffer cache. Entries in the redo log buffer are quickly written to disk (at commits, when it is 1/3rd or 1MB full, every 3seconds, before DBWR writes a modified data block).
Hemant K Chitale

Redo log buffer is in cretical position

hi Experts,
please try to solve my query, here in my system redo log buffer shows(alert monitoring) 99<4000 and message is '4000 redo entries per redo log space requests'
so i think i need to increase log_buffer parameter value upto required level ,then i entered in database
splplus / as sysdba
and i try to check my file is in which type (spfile or in pfile) by executing command
" SHOW PARAMETER pfile"
it shows
name--- spfile
type---string
value---/oracle/qty/102_64/dbs/spfileqty.ora
when i Excute 'SHOW PARAMETER spfile' also the same result
now in here i have doubt please clarify me
1) my file is spfile or pfile ?
2) how can i increase my parameter value (alter system set log_buffer = xxx scope=pfile (or) spfile )
3) is that my process correct for that error
please clarify me
thanks & regards

Hi,
As per my knowledge, Oracle 10g by default starts with SPFILE and if you are setting the parameter with alter command then yes the scope should be SPFILE. After that when you schedule any DB related activity(backup, update statistics etc.,) it will create pfile from spfile.
Before doing any changes take the backup of the existing files both (pfile and spfile) at os level.
Regards,
Sharath

Redo Log Buffer 32.8M, Seems to Big?

I just took over a database (Mainly used for OLTP on 11gR1) and I am looking at the log_buffer parameter it is set to 34412032 (32.8M). Not sure why it is so high.
select
    NAME,
    VALUE
from
    SYS.V_$SYSSTAT
where
    NAME in ('redo buffer allocation retries', 'redo log space wait time');
redo buffer allocation retries     185
redo log space wait time          5180(database has been up for 7.5 days)
Any opinions on this? I Normally keep try to stay below 3M and have not really seen it above 10M.

Sky13 wrote:
I just took over a database (Mainly used for OLTP on 11gR1) and I am looking at the log_buffer parameter it is set to 34412032 (32.8M). Not sure why it is so high.
In 11g you shouldn't set the log_buffer parameter - let Oracle set the default.
The value is derived from the setting for the CPU count and the transactions parameter, which may be derived from sessions, which may be derived from processes. Moreover, Oracle is going to allocate at least a granule (which may be 4MB, 8MB, 16MB, 64MB or 256MB depending on the size of the SGA, so you are unlikely to save memory by reducing the log buffer size.
Here's a link to a discussion which shows you how to find out what's really behind that figure.
Re: Archived redo log size more less than online redo logs
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b>

DB Cache Full or Redo Log Full?

Is there any way that Oracle can write to datafiles in the middle of a transaction?
Iam reading, processing and writing very large sized lobs which gives error that "no free buffers available in buffer pool".
When in lobs, a lob is not written until the whole tranaction finishes - but in my case the lob size is large than the size of the data buffer cache.
The error is "ORA-00379: no free buffers available in buffer pool DEFAULT for block size 8K"
Exact question I would like to know now is that which buffer is full; data_buffer_cache or the redo log buffer?
If data_buffer cache, then is there a mechanism which allows to write data to dtafiles in the middle of a transaction as i have to do processing with lobs - which are 3 to 4 times the size of the db cache size.
I am referring to the same problem outlined in an earlier thread.
Thanks

Is there any way that Oracle can write to datafiles
in the middle of a transaction?
r.- Oracle writes to the datafiles only commited transactions according to some elements
Iam reading, processing and writing very large sized
lobs which gives error that "no free buffers
available in buffer pool".
r.- You have to increase the size of the buffer Pool
When in lobs, a lob is not written until the whole
tranaction finishes - but in my case the lob size is
large than the size of the data buffer cache.
The error is "ORA-00379: no free buffers available in
buffer pool DEFAULT for block size 8K"
Exact question I would like to know now is that which
buffer is full; data_buffer_cache or the redo log
buffer?
data_buffer_cache. In what version you are ?
If data_buffer cache, then is there a mechanism which
allows to write data to dtafiles in the middle of a
transaction as i have to do processing with lobs -
which are 3 to 4 times the size of the db cache
size.
r.- Oracle does not write to the datafiles in that way
I am referring to the same problem outlined in an
earlier thread.
Thanks Joel PÃ©rez
http://www.oracle.com/technology/experts

Redo log space requests VALUE high

SELECT name||' = '||value
FROM v$sysstat
WHERE name = 'redo log space requests';
I am noticing 40+ space requests for some of my Oracle 9.2.0.5 databases.
On another 7.3.4 DB I see this over 140 but this DB shutdown only on weekends so this cumulative value increases I presume.
I have 20MB of 5 groups already. Do I still add another 2 more groups or increase their sizes ?
I did read somewhere that I'd have to increase the log_buffer parameter. So how do we deal with this issue ? Any repercussions if I let this as it is for now ?
The cause of this would be redo logs are not big enough or otherwise ?
Thanks.

user4874781 wrote:
Thanks for your response Charles.
So if I understand this correctly ... Redolog Space requests corresponds to a either an incorrectly sized redo log file / DBWR / CKPT needs to be tuned.
Maybe I was interpreting this the wrong way. (Possibly)
" The statistic 'redo log space requests' reflects the number of times a user process waits for space in the redo log buffer. " If that is the case, if there was longer waits for this event, I was under the assumption that log_buffer needs to be increased.
http://www.idevelopment.info/data/Oracle/DBA_tips/Tuning/TUNING_6.shtml
* Yes, the waits have increased to 70 as of now (since 40 yesterday .. DB was started Saturday night and will run till weekend) Less activity as of now, since the day has just started ; so it would definitely rise by end of the day. I took a look at the above article, and I think I understand why the article is slightly confusing. With due respect to the author, the article was last modified 16-Apr-2001, which I believe is before the Oracle documentation was better clarified regarding these statistics. From:
http://download.oracle.com/docs/cd/B14117_01/server.101/b10755/stats002.htm
"redo log space requests: Number of times the active log file is full and Oracle must wait for disk space to be allocated for the redo log entries. Such space is created by performing a log switch. Log files that are small in relation to the size of the SGA or the commit rate of the work load can cause problems. When the log switch occurs, Oracle must ensure that all committed dirty buffers are written to disk before switching to a new log file. If you have a large SGA full of dirty buffers and small redo log files, a log switch must wait for DBWR to write dirty buffers to disk before continuing."
"redo log space wait time: Total elapsed waiting time for "redo log space requests" in 10s of milliseconds"
It is quite possible that the "redo log space requests" will increase with every redo log file switch, which should not be too much of a concern. You may want to focus a little more on the "redo log space wait time" statistic, which indicates how much wait time was involved waiting. You might also want to focus on the system-wide wait event interface, examining how the accumulated wait time increases from one sampling of each of the statistics to the next.
* I have 1 log switch every 11 minutes ; BTW ; I have 5 log groups of 20 MB each as of now. So I am assuming 40 MB of 4 or 5 log groups should be fine as per your suggestion ?If you have the disk space, considering that it is an ancient AIX box, you may want to set the redo log files to an even larger size, possibly 100MB (or larger). You may then want to force periodic switches of the redo log, for instance once an hour, or once every 30 minutes.
* This is an ancient AIX box with 512 MB Ram. Is the redo log located on a fast device ? I'd have to find that out ( any hints on that ? )
* Decreasing the log_buffer is possible on weekends since I'd have to bounce it for it to take effect.
I will increase the log files accordingly and hopefully the space waits will reduce. Thanks again.Someone else, possibly Sybrand, on the forums might be familiar with AIX and be able to provide you with an answer. If you are seeing system-wide increasing wait time for redo related waits, then that might be an indication that the redo logs are not located on a fast device.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Recursive call with commit not written to redo log

In my DBA training I was led to the belief that a commit caused the log writer to write the redo log buffer to the redo log file, but I find this is not true if the commit is inside recursive code.
I believe this is intentional as a way off reducing i/o but it does raise data integrity problems.
Apparently if you have some PL/SQL (can be sql*plus code or procedure) with a loop containing a commit,
the commit does not actually ensure that the transaction is written to the Redo log.
Instead Oracle only ensures all is written to the redo log when control is returned to the application/sqlplus.
You can see this by checking the redo writes in v$sysstat.
It will be less than the number of expected commits.
Thus the old rule of expecting all committed transation to be there after a database recovery is not necessarily true.
Does anyone know how to force the commit to ensure redo is written
-inside pl/sql or perhaps a setting in the the calling environment ?
Thanks

Thanks for your input
The trouble is that I believe if you stopped in a debugger the log writer would catch up -
Or if you killed your instance in the middle of this test you wouldn't be sure how many commits the db thought it did
ie. the db would recover to the last known commit in the redo logs
- maybe I should turn on tracing ?
Since my question I have a found a site that seems to back up the results I am getting
http://www.ixora.com.au/notes/redo_write_triggers.htm
see the note under point 3
Have a look at the stats below and you will see
redo writes 19026
user commits 100057
How I actually tested was to run
the utlbstat scipt
then run some pl/sql that
- mimiced a business transactions (4 select lookup validations, 2 inserts and 1 insert or update and a commit)
- loop * 100000
then ran utlestat.sql
i.e. test script
@C:\oracle\ora92\rdbms\admin\utlbstat.sql
connect test/test
@c:\mig\Load_test.sql
@C:\oracle\ora92\rdbms\admin\utlestat.sql
Statistic Total Per Transact Per Logon Per Second
CPU used by this session 37433 .37 935.83 79.31
CPU used when call started 37434 .37 935.85 79.31
CR blocks created 62 0 1.55 .13
DBWR checkpoint buffers wri 37992 .38 949.8 80.49
DBWR checkpoints 6 0 .15 .01
DBWR transaction table writ 470 0 11.75 1
DBWR undo block writes 22627 .23 565.68 47.94
SQL*Net roundtrips to/from 4875 .05 121.88 10.33
background checkpoints comp 5 0 .13 .01
background checkpoints star 6 0 .15 .01
background timeouts 547 .01 13.68 1.16
branch node splits 4 0 .1 .01
buffer is not pinned count 4217 .04 105.43 8.93
buffer is pinned count 649 .01 16.23 1.38
bytes received via SQL*Net 1027466 10.27 25686.65 2176.83
bytes sent via SQL*Net to c 5237709 52.35 130942.73 11096.84
calls to get snapshot scn: 1514482 15.14 37862.05 3208.65
calls to kcmgas 303700 3.04 7592.5 643.43
calls to kcmgcs 215 0 5.38 .46
change write time 4419 .04 110.48 9.36
cleanout - number of ktugct 1875 .02 46.88 3.97
cluster key scan block gets 101 0 2.53 .21
cluster key scans 49 0 1.23 .1
commit cleanout failures: b 27 0 .68 .06
commit cleanouts 1305175 13.04 32629.38 2765.2
commit cleanouts successful 1305148 13.04 32628.7 2765.14
commit txn count during cle 3718 .04 92.95 7.88
consistent changes 752 .01 18.8 1.59
consistent gets 1514852 15.14 37871.3 3209.43
consistent gets - examinati 1005941 10.05 25148.53 2131.23
data blocks consistent read 752 .01 18.8 1.59
db block changes 3465329 34.63 86633.23 7341.8
db block gets 3589136 35.87 89728.4 7604.1
deferred (CURRENT) block cl 1068723 10.68 26718.08 2264.24
enqueue releases 805858 8.05 20146.45 1707.33
enqueue requests 805852 8.05 20146.3 1707.31
execute count 1004701 10.04 25117.53 2128.6
free buffer requested 36371 .36 909.28 77.06
hot buffers moved to head o 3801 .04 95.03 8.05
immediate (CURRENT) block c 3894 .04 97.35 8.25
index fast full scans (full 448 0 11.2 .95
index fetch by key 201128 2.01 5028.2 426.12
index scans kdiixs1 501268 5.01 12531.7 1062.01
leaf node splits 1750 .02 43.75 3.71
logons cumulative 2 0 .05 0
messages received 19465 .19 486.63 41.24
messages sent 19465 .19 486.63 41.24
no work - consistent read g 3420 .03 85.5 7.25
opened cursors cumulative 201103 2.01 5027.58 426.07
opened cursors current -3 0 -.08 -.01
parse count (hard) 4 0 .1 .01
parse count (total) 201103 2.01 5027.58 426.07
parse time cpu 2069 .02 51.73 4.38
parse time elapsed 2260 .02 56.5 4.79
physical reads 6600 .07 165 13.98
physical reads direct 75 0 1.88 .16
physical writes 38067 .38 951.68 80.65
physical writes direct 75 0 1.88 .16
physical writes non checkpo 34966 .35 874.15 74.08
prefetched blocks 2 0 .05 0
process last non-idle time 1029203858 10286.18 25730096.45 2180516.65
recursive calls 3703781 37.02 92594.53 7846.99
recursive cpu usage 35210 .35 880.25 74.6
redo blocks written 1112273 11.12 27806.83 2356.51
redo buffer allocation retr 21 0 .53 .04
redo entries 1843462 18.42 46086.55 3905.64
redo log space requests 17 0 .43 .04
redo log space wait time 313 0 7.83 .66
redo size 546896692 5465.85 13672417.3 1158679.43
redo synch time 677 .01 16.93 1.43
redo synch writes 63 0 1.58 .13
redo wastage 4630680 46.28 115767 9810.76
redo write time 64354 .64 1608.85 136.34
redo writer latching time 42 0 1.05 .09
redo writes 19026 .19 475.65 40.31
rollback changes - undo rec 10 0 .25 .02
rollbacks only - consistent 122 0 3.05 .26
rows fetched via callback 1040 .01 26 2.2
session connect time 1029203858 10286.18 25730096.45 2180516.65
session logical reads 5103988 51.01 127599.7 10813.53
session pga memory -263960 -2.64 -6599 -559.24
session pga memory max -788248 -7.88 -19706.2 -1670.02
session uga memory -107904 -1.08 -2697.6 -228.61
session uga memory max 153920 1.54 3848 326.1
shared hash latch upgrades 501328 5.01 12533.2 1062.14
sorts (memory) 1467 .01 36.68 3.11
sorts (rows) 38796 .39 969.9 82.19
switch current to new buffe 347 0 8.68 .74
table fetch by rowid 1738 .02 43.45 3.68
table scan blocks gotten 424 0 10.6 .9
table scan rows gotten 4164 .04 104.1 8.82
table scans (short tables) 451 0 11.28 .96
transaction rollbacks 5 0 .13 .01
user calls 5912 .06 147.8 12.53
user commits 100057 1 2501.43 211.99
user rollbacks 56 0 1.4 .12
workarea executions - optim 1676 .02 41.9 3.55
write clones created in bac 5 0 .13 .01
write clones created in for 745 .01 18.63 1.58
99 rows selected.

Following omf for redo log files

Hi,
when DB_CREATE_ONLINE_LOG_DEST_1 IS set then I would like to
know whether 2 log groups would be created at the location specified if yes then in archive log mode whether this would create any problems .

Before DBWn can write a modified buffer, all redo records associated with the changes to the buffer must be written to disk (the write-ahead protocol). If DBWn finds that some redo records have not been written, it signals LGWR to write the redo records to disk and waits for LGWR to complete writing the redo log buffer before it can write out the data buffers.
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14220/process.htm#i21918

Redo Log Buffer sizing problem

Similar Messages

Maybe you are looking for