Log Buffer and SGA_target

Hello,
What should be the best sizing for an Oracle db 10g, windows server 2003, 4gb ram + 2 processors, process over 5 mills records a day, using sqlldr, many pls, etc.
Now it has 100m log_buffer and sga_target 612m, but it´s very low and per each second generates log files, till 2 -3 log files per second, the size of each file is 5m.
Please help, I would like it to generate log files per each hour. Please let me know the combination of parameters that I would have to change.
Thanks in advance,
Juan Angel

Mark,
I installed the DB, in fact, I am not a DBA, I am in charge of the revenue assurance department for a Telco company, I do not know that much about setting up a DB, I used to be an oracle analyst only.
How do I resize them?, the manual says about improving the checkpointing, there are two parameters of checkpointing: log_checkpoint_interval=0 seconds, and log_checkpoint_timeout=1800 seconds, 30 minutes, down some parameters of the spfile:
__db_cache_size = 343932928
__java_pool_size = 8388608
__large_pool_size = 20971520
__shared_pool_size = 134217728
background_dump_dest = D:\ORACLE\PRODUCT\10.1.0\ADMIN\RA\BDUMP
compatible = 10.1.0.2.0
control_files = ('D:\ORACLE\PRODUCT\10.1.0\RA\U02\ORADATA\RA\CONTROLFILE\O1_MF_1K9O0R7F_.CTL', 'D:\ORACLE\PRODUCT\10.1.0\RA\U03\ORADATA\RA\CONTROLFILE\O1_MF_1K9O0R9V_.CTL')
core_dump_dest = D:\ORACLE\PRODUCT\10.1.0\ADMIN\RA\CDUMP
db_block_size = 8192
db_create_file_dest = D:\oracle\product\10.1.0\ra\u01\oradata
db_create_online_log_dest_1 = D:\oracle\product\10.1.0\ra\u02\oradata
db_create_online_log_dest_2 = D:\oracle\product\10.1.0\ra\u03\oradata
db_domain = 'megatel.hn'
db_file_multiblock_read_count = 8
db_name = ra
db_recovery_file_dest = D:\oracle\product\10.1.0\ra\flash_recovery_area
db_recovery_file_dest_size = 30536091648
dispatchers = '(protocol=TCP)'
job_queue_processes = 10
log_archive_dest_1 = 'LOCATION=D:\oracle\product\10.1.0\ra\flash_recovery_area'
log_archive_format = 'ARC%S_%R.%T'
log_buffer = 100000256
open_cursors = 300
pga_aggregate_target = 203423744
processes = 150
remote_login_passwordfile = EXCLUSIVE
sga_target = 612368384
sort_area_size = 65536
undo_management = AUTO
undo_tablespace = UNDOTBS1
user_dump_dest = D:\ORACLE\PRODUCT\10.1.0\ADMIN\RA\UDUMP
I appreciate your helping me.
Juan Angel

Similar Messages

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

About Log Buffer writhing..

Hi,
Wondering how Log Buffer behaves...
1. If timesten is configured as single node(no replication and cache option), When does log buffer data write to log file?
By running some test, it seems like only at checkpoint action it is being write.
Is there any other way to write log buffer data beside with checkpoint action?
2. Which process is doing writing action from log buffer to log file?
Is it the same process that uses with replication and cache option?
3. In TimesTen Manual ...
asynchronous replication "TimesTen Data Manager writes the transaction update records to the transaction log buffer."
Return Twosafe "The master replication agent writes the transaction records to the log and inserts a special precommit log record before the commit record."
Then ... does it mean that log buffer write process is different according to replication type?
4. I am assuming Log_Buffer_Wait from 'monitor;' output is the waiting time of Log Buffer writing time to logfile...
If it is correct, is the possibility of Log_Buffer_Wait occurance increases when log buffer size is large with no replication option?
w
I am willing to hear for above.
Thank you,

TimesTen generates log records for the purposes of redo and undo. Log records are generated for pretty much any change to persistent recoverable data within TimesTen. Log records are first written into the in memory log buffer and then are written to disk by a dedicated flusher thread that runs within the sub-daemon process that is assigned to the datastore. The log flusher thread runs continuously when there is data to be flushed and when there is any significant write workload on the system log data will reach disk very shortly after it has been placed in the buffer. Under very light write workload it may talke a little longer for the data to reach disk.
There is a single logical log buffer (size determined by LogBufMB) which in TimesTen 11g, is divided into multiple physical buffers (strands) for increased concurrency of logging operations ( number of strands determined by LogBufParallelism).
Several of your observations are not correct; I would like to understand hwat tests you performed to arrive at these conclusions:
1. Yes, the log buffer is flushed during a checkpoint operation but in fact it is also being flushed continuously at all times by the log flusher thread.
2. You can force the buffer to be flushed at any time simply by executing a durable commit within the datastore. A durable commit flushes all log starnds synchronously to disk and does not return until the writes have completed successfully and been acknowledged by the storage hardware.
3. The text that you quote from the replication guide is ambiguous and could be better phrased. When it talks about 'writing to the log' it means placing records in the in-memory log buffer. The presence or absence of replication does not fundamentally change the way logging works though the replication agent, when active, typically perfoms a durable commit every 100 ms. Also, in some replication modes, additional durable commits may be executed by the replication agent before sending a block of replicated transactions.
4. The LOG_BUFFER_WAITS field in SYS.MONITOR counts the number of times that application transactions have been blocked due to there being no free space in the log buffer to receive their log records. This is due to some form of logging bottleneck. By far the most common reason is that the log buffer is undersized. the default size if only 64 MB and this is far too small for any kind of write intensive workload. For write intensive workloads a significantly larger log buffer size is needed (max size allowed is 1 GB).
5. The field LOG_FS_WRITES in SYS.MONITOR counts the number of physical writes that the log flusher thread has performed to the logs on disk. The flusher will typically write a lot of data in a single write (when under heavy load). Flusher writes are filesystem block aligned.
Hope that helps clarify things.
Chris

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

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.

Issue creating a database: SGA_MAX_SIZE and SGA_TARGET

Hello:
While creating a custom database, I am running into issues with the values I specify for SGA_MAX_SIZE and SGA_TARGET.
The install manual for the product I am creating the database for says that SGA_MAX_SIZE should be >= SGA_TARGET_SIZE. It also wants a minimum of 1Gig for SGA_Target
The Database Configuration Assistant defaulted to 0.64GB for SGA_TARGET and 0.168 for SGA_MAX_SIZE (This is clearly against the instruction in the installation manual).
Who is right? Me or the vendor?
I read some threads that indicate that the vendor may be wrong.
venki

Follow the vendor's instructions.
DBCA has never in its existence made a correct decision yet. It puts all control files and redo logs into one directory.
It doesn't create multiple members for the log file groups.
And its memory management is based on a simple algorithm that has nothing to do with any specific reality.
DBCA is intended for creating a generic database for generic purposes ... and that it does very very well.

SGA_MAX_SIZE and SGA_TARGET how to set minimum for pools

Hello, we are on 10.2.0.4, Solaris 5.10. We are using ASMM, so SGA_TARGET and SGA_TARGET size are set. Hence, buffer cache, shared pool, large pool and java pool are automatically sized. However, we do not have any minimum values for those. How do I determine what this minimum value should be?
thank you!

HI,
Yes you need size the minimum value for shared pool, buffer cahce tec... else it will start consuming wholeThe documentaion
states:
You need not set the size of any of these components explicitly. By default the parameters for these components will appear to have values of zero. Whenever a component needs memory, it can request that it be transferred from another component by way of the internal automatic tuning mechanism. This transfer of memory occurs transparently, without user intervention.Can you please explain how would it start consuming the entire SGA?

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

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 --

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

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

Log Buffer and SGA_target

Similar Messages

Maybe you are looking for