Log Buffer

I note that log_buffer even if set, is going to be different {more} post 10.2.x – however if it (oracle internal algorithm) sets a very high value we can see side effects of too long “LOG FILE SYNC”? In one of our instance, we have a SGA granule size of 64MB and when we set LOG_BUFFER to 16MB, i see redo buffers of more than 78MB. Since we have a mixed workload (short transactions + batch jobs) – short transactions are seeing some waits on log file sync. Earlier log_buffer was set to 150MB and oracle took nearly 210MB the waits seen on short UI house keeping transactions were waiting quite long and after reducing – we are now in a “thin acceptable limit”. Is there any other way to reduce redo buffers? anything less than 32MB not only may be enough it will bring down my log file sync even further (which is very much needed for UI house keeping transactions). Even if i unset, i think its still going to allocate 64MB? BTW, we are on 11.2.0.3.
- Abhay

Hi Jonathan,
My suspect was CPU starvation as well and may be possibly caused by high COMMIT rate, but avg CPU load on system was not even 20% - but that still doesn't warrant of what was happening per CPU core and if my UI session was hooked along with batch processes on a CORE - need to check run time CPU stats on the system when we hit this issue (typically when a lot of jobs are running). Going by the avg utilization of CPU it doesnt seem there was any CPU starvation, PS below OS stats from AWR report for the bad period (before log buffer change)
Operating System Statistics
Statistic          Value          End Value
AVG_BUSY_TIME          53,872
AVG_IDLE_TIME          308,864
AVG_SYS_TIME          3,019
AVG_USER_TIME          50,683
BUSY_TIME          3,459,745
IDLE_TIME          19,779,080
SYS_TIME          204,469
USER_TIME          3,255,276
LOAD               25          8
OS_CPU_WAIT_TIME     19,500      OS CPU wait time is not so significant hence didnt bother too much to see each CPU level stats at run time. Also below is % utilization from AWR
Operating System Statistics - Detail
Snap Time Load %busy %user %sys %idle %iowait
07-Mar 10:45:11 25.05
07-Mar 11:00:20 7.10 13.27 12.17 1.10 86.73 0.00
07-Mar 11:15:27 11.00 12.15 11.43 0.72 87.85 0.00
07-Mar 11:30:40 10.00 18.27 17.32 0.95 81.73 0.00
07-Mar 11:45:42 8.20 15.80 15.06 0.74 84.20 0.00 After log buffer change if things have improved as seen from AWRs pasted earlier, and when we factually know from AWR log file parallel writes are not taking significant amount of time - are we hitting a possible issue of serialization as described in [Tony Hasler - Log File Sync|http://tonyhasler.wordpress.com/2011/07/24/log-file-sync-and-log-file-parallel-write-part-2/] ? the whole lot of time spent in copying blocks from private redo strands? PS we have a lot of private strands, below is snippet you asked for.
Or is Oracle not registering log file parallel writes properly? as i see from 10298 event enabled for LGWR process that the issue starts when write rate drops to 1-3MPBS and when it does 6-9MBPS things look quite reasonable. Waiting less on log file sync after log buffer reduction hints us of possible IO issue but not registered by oracle, and especially after observations of bad time vs good time & consistently in bad time 10298 reported lesser IO write speed.
      INDX TOTAL_BUFS_KCRFA STRAND_SIZE_KCRFA INDEX_KCRF_PVT_STRAND SPACE_KCRF_PVT_STRAND
         0             8192           4194304                     0                     0
         1             8192           4194304                     0                     0
         2             8192           4194304                     0                     0
         3             8192           4194304                     0                     0
         4              249            132096                     4                126464
         5              249            132096                     5                126464
         6              249            132096                     6                126464
         7              249            132096                     7                126464
         8              249            132096                     8                126464
         9              249            132096                     9                126464
        10              249            132096            3735928559                126464
        11              249            132096                    11                126464
       554              249            132096            3735928559                126464
       555              249            132096            3735928559                126464
       556              249            132096            3735928559                126464
       557              249            132096            3735928559                126464
       558              249            132096            3735928559                126464
       559              249            132096            3735928559                126464
560 rows selected.Edited by: 993122 on Mar 14, 2013 6:26 AM

Similar Messages

Log buffer overflow

I have been receiving the flex log buffer overflow error for a long time. I don't believe it is causing any problem but I'm not sure.
I have Iplanet Web Server 4.1 on Solaris 2.6.
I have changed the LogFlushInterval from the default 30 seconds to 5 seconds.
I am logging a great deal of information
My questions are...
should I be concerned ?
when I get that error is the buffer being immediately dumped to the log file ?
am I losing any log information ?
can I increase the buffer size ?
should I reduce the LogFlushInterval any more ?
Thanks

The error message indicates that an access log entry exceeded the maximum of 4096 bytes and was truncated. You should check the access log file for suspicious entries.
Adjusting LogFlushInterval won't affect this problem, and unfortunately there's no way to increase flex log buffer size.

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

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

Tuning : log buffer space in 11gr2

Hi,
version : 11202 on hpux
awr Top 5 events shows :
Top 5 Timed Foreground Events :
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
log buffer space 12,401 29,885 2410 55.83 Configuration
My log_buffer size is :
SQL> show parameter log_buffer
NAME                                 TYPE        VALUE
log_buffer                           integer     104857600And the sga values are :
SQL> show parameter sga
NAME                                 TYPE        VALUE
sga_max_size                         big integer 15G
sga_target                           big integer 15GI wanted to know if there are guide lines for tuning log_buffer space .
Can just double it from 100m to 200m ?
Thanks

Yoav wrote:
Top 5 Timed Foreground Events :
Event                    Waits    Time(s)       Avg wait (ms) % DB time    Wait Class
log buffer space      12,401 29,885            2410              55.83     Configuration My log_buffer size is :
SQL> show parameter log_buffer
NAME                                 TYPE        VALUE
log_buffer                           integer     104857600I wanted to know if there are guide lines for tuning log_buffer space .
Can just double it from 100m to 200m ?
You're the second person this week to come up with this issue.
The ONLY sensible guideline for the log buffer is to let it default until you have good reason to change it. Reasons for change (even to the point of modifying a hidden parameter) are really application dependent.
The last couple of times something like this has come up the issue has revolved around mixing very large uncommitted changes with large numbers of small transactions - resulting in many small transactions waiting for the log writer to complete a large write on behalf of the large transaction. Does this pattern describe your application environment ?
For reference - how many public and how many private redo strands do you have, and how many have been active. (See http://jonathanlewis.wordpress.com/2012/09/17/private-redo-2/ for a query that shows the difference).
Regards
Jonathan Lewis

Pros and cons between the large log buffer and small log buffer?

pros and cons between the large log buffer and small log buffer?
Many people suggest that small log buffer (1-3MB) is better because we can avoid the waiting events from users. But I think that we can also have advantage with the bigger on...it's because we can reduce the redo log file I/O...
What is the optimal size of the log buffer? should I consider OLTP vs DSS as well?

Hi,
It's interesting to note that some very large shops find that a > 10m log buffer provides better throughput. Also, check-out this new world-record benchmark, with a 60m log_buffer. The TPC notes that they chose it based on the cpu_count:
log_buffer = 67108864 # 1048576x cpuhttp://www.dba-oracle.com/t_tpc_ibm_oracle_benchmark_terabyte.htm

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

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>

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

I/O Error when writing access Log buffer to file. error number: 28

Hi,
Oracle OracleAS Web Cache 10.1.2.3.0, Build 10.1.2.3.0 080201 is writing events like this:
[alert 13215] I/O Error when writing access Log buffer to file. error number: 28
I've looked for this alert and i've found this description:
WXE-13215 I/O Error when writing access Log buffer to file. error number: %d
Severity: alert
Cause: I/O error happened when OracleAS Web Cache tried to write to the access log file.
Action: Check the status of access log file. For example, see if the disk is full
Anybody knows what "error number: 28" stands for? The logs are sended to other server and it seems that the disk size is ok.
thanks!

I tested again...it seems LabVIEW doesn't like the way I wrote the measurement files. I attached a set of VIs (ZIP-file) to give you a clue how it was done. When I try to save and read a file containing just plain DBLs from a 1D-Array (see attached file generating VI) it works perfectly well for large file sizes.
So there might get something messed up by the way LabVIEW saved the measured data. You'll notice, that I (accidentally) left the "prepend array string size" input of "write to binary file" function unwired which means that the size information will be written as a type of header. Maybe this is the reason that it doesn't work as expected...
Attachments:
VibrationMeasurement.zip ‏76 KB
generate_test_bin_data.vi ‏12 KB

Log Buffer to disk?

Hi,
When the information in the Log Buffer is saved to disk?
Thanks,
Felipe

Hi Felipe,
Let’s conduct a brief summary about the redo process. When Oracle blocks are changed, including undo blocks, oracle records the changes in a form of vector changes which are referred to as redo entries or redo records. The changes are written by the server process to the redo log buffer in the SGA. The redo log buffer is then flushed into the online redo logs in near real time fashion by the log writer LGWR.
The redo logs are written by the LGWR when:
•     When a user issue a commit.
•     When the Log Buffer is 1/3 full.
•     When the amount of redo entries is 1MB.
•     Every three seconds
•     When a database checkpoint takes place. The redo entries are written before the checkpoint to ensure recoverability.
Remember that redo logs heavily influence database performance because a commit cannot complete until the transaction information has been written to the logs. You must place your redo log files on your fastest disks served by your fastest controllers. If possible, do not place any other database files on the same disks as your redo log files. Because only one group is written to at a given time, there is no harm in having members from several groups on the same disk.
To avoid losing information that could be required to recover the database at some point, Oracle has an archive (ARCn) background process that archives redo log files when they become filled. However, it’s important to note not all Oracle Databases will have the archive process enabled. An instance with archiving enabled, is said to operate in ARCHIVELOG mode and an instance with archiving disabled is said to operate in NO ARCHIVELOG mode.
You can determine with mode or if archiving is been used in your instance either by checking the value for the LOG_ARCHIVE_START parameter in your instance startup parameter file (pfile or spfile – This parameter is deprecated on version 10g), by issuing an SQL query to the v$database (“ARCHIVELOG” indicates archiving is enabled, and “NOARCHIVELOG” indicates that archiving is not enabled) or by issuing the SQL ARCHIVE LOG LIST command.
SQL> Select log_mode from v$database;
LOG_MODE
ARCHIVELOG
SQL> archive log list
Database log mode                    Archive Mode
Automatic archival                    Enabled
Archive destination                   USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence       8
Next log sequence to archive   10
Current log sequence               10The purpose of redo generation is to ensure recoverability. This is the reason why, Oracle does not give the DBA a lot of control over redo generation. If the instance crashes, then all the changes within SGA will be lost. Oracle will then use the redo entries in the online redo files to bring the database to a consistent state. The cost of maintaining the redolog records is an expensive operation involving latch management operations (CPU) and frequent write access to the redolog files (I/O).
Regards,
Francisco Munoz Alvarez
www.oraclenz.com

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)

Log Buffer

Similar Messages

Maybe you are looking for