Sizing redo logs

Hello
We have a database that serves an OLTP applicaiton during the day, and at night batch processes start. When one of the batch processes runs, it generates loads of archive redo logs, sometimes more than 2 per minute which is really slowing things down. So what I was wondering is(and this is probably a really obvious thing) could we create large log files i.e. around 1gb, and during the day, set the log_checkpoint_timeout parameter to ensure that the logs switch at least every 30 mins, and then in the evening, set this value to 0 to make sure that they only switch when the log is full.
Is this a reasonable and advisable approach? We are copying the archive logs to a warm standby database so will the increased size of the logs cause a problem?
Cheers
DJT

the changes you are asking are not adviseable and could cause seriouse problem. The solution for this kind of problem which is used is the option of hints . Read the hint documrntation clearly. it is small .
By using hints in your query you can use the option of nologging during your batch process which will create no redo log record. This option used for pach Processes.
But remeber recovery of that record which was inserted by the option of nologging is not possible.
By reading notes you can understand it well.

Similar Messages

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.

Sizing the redo log files using optimal_logfile_size view.

Regards
I have a specific question regarding logfile size. I have deployed a test database and i was exploring certain aspects with regards to selecting optimal size of redo logs for performance tuning using optimal_logfile_size view from v$instance_recovery. My main goal is to reduce the redo bytes required for instance recovery. Currently i have not been able to optimize the redo log file size. Here are the steps i followed:-
In order to use the advisory from v$instance_recovery i had to set fast_start_mttr_target parameter which is by default not set so i did these steps:-
1)SQL> sho parameter fast_start_mttr_target;
NAME TYPE VALUE
fast_start_mttr_target integer 0
2) Setting the fast_start_mttr_target requires nullifying following deferred parameters :-
SQL> show parameter log_checkpoint;
NAME TYPE VALUE
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean FALSE
SQL> select ISSES_MODIFIABLE,ISSYS_MODIFIABLE,ISINSTANCE_MODIFIABLE,ISMODIFIED from v$parameter where name like'log_checkpoint_timeout';
ISSES_MODIFIABL ISSYS_MODIFIABLE ISINSTANCE_MODI ISMODIFIED
FALSE IMMEDIATE TRUE FALSE
SQL> alter system set log_checkpoint_timeout=0 scope=both;
System altered.
SQL> show parameter log_checkpoint_timeout;
NAME TYPE VALUE
log_checkpoint_timeout integer 0
3) Now setting fast_start_mttr_target
SQL> select ISSES_MODIFIABLE,ISSYS_MODIFIABLE,ISINSTANCE_MODIFIABLE,ISMODIFIED from v$parameter where name like'fast_start_mttr_target';
ISSES_MODIFIABL ISSYS_MODIFIABLE ISINSTANCE_MODI ISMODIFIED
FALSE IMMEDIATE TRUE FALSE
Setting the fast_mttr_target to 1200 = 20 minutes of checkpoint switching according to Oracle recommendation
Querying the v$instance_recovery view
4) SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
276 165888 *93* 59 361 16040
Here Target Mttr was 93 so i set the fast_mttr_target to 120
SQL> alter system set fast_start_mttr_target=120 scope=both;
System altered.
Now the logfile size suggested by v$instance_recovery is 290 Mb
SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
59 165888 93 59 290 16080
After altering the logfile size to 290 as show below by v$log view :-
SQL> select GROUP#,THREAD#,SEQUENCE#,BYTES from v$log;
GROUP# THREAD# SEQUENCE# BYTES
1 1 24 304087040
2 1 0 304087040
3 1 0 304087040
4 1 0 304087040
5 ) After altering the size i have observed the anomaly as redo log blocks to be applied for recovery has increased from *59 to 696* also now v$instance_recovery view is now suggesting the logfile size of *276 mb*. Have i misunderstood something
SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
*696* 646947 120 59 *276* 18474
Please clarify the above output i am unable to optimize the logfile size and have not been able to achieve the goal of reducing the redo log blocks to be applied for recovery, any help is appreciated in this regard.

sunny_123 wrote:
Sir oracle says that fast_start_mttr target can be set to 3600 = 1hour. As suggested by following oracle document
http://docs.oracle.com/cd/B10500_01/server.920/a96533/instreco.htm
I set mine value to 1200 = 20 minutes. Later i adjusted it to 120=2 minutes as Target_mttr suggested it to be around 100 (if fast_mttr_target value is too high or too low effective value is contained in target_mttr of v$instance_recovery)Just to add, you are reading the documentation of 9.2 and a lot has changed since then. For example, in 9.2 the parameter FSMTTR was introduced and explicitly required to be set and monitored by the DBA for teh additional checkpoint writes which might get caused by it. Since 10g onwards this parameter has been made automatically maintained by Oracle. Also it's been long that 9i has been desupported followed by 10g so it's better that you start reading the latest documentation of 11g and if not that, at least of 10.2.
Aman....

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

Urgent: Huge diff in total redo log size and archive log size

Dear DBAs
I have a concern regarding size of redo log and archive log generated.
Is the equation below is correct?
total size of redo generated by all sessions = total size of archive log files generated
I am experiencing a situation where when I look at the total size of redo generated by all the sessions and the size of archive logs generated, there is huge difference.
My total all session redo log size is 780MB where my archive log directory size has consumed 23GB.
Before i start measuring i cleared up archive directory and started to monitor from a specific time.
Environment: Oracle 9i Release 2
How I tracked the sizing information is below
logon as SYS user and run the following statements
DROP TABLE REDOSTAT CASCADE CONSTRAINTS;
CREATE TABLE REDOSTAT
AUDSID NUMBER,
SID NUMBER,
SERIAL# NUMBER,
SESSION_ID CHAR(27 BYTE),
STATUS VARCHAR2(8 BYTE),
DB_USERNAME VARCHAR2(30 BYTE),
SCHEMANAME VARCHAR2(30 BYTE),
OSUSER VARCHAR2(30 BYTE),
PROCESS VARCHAR2(12 BYTE),
MACHINE VARCHAR2(64 BYTE),
TERMINAL VARCHAR2(16 BYTE),
PROGRAM VARCHAR2(64 BYTE),
DBCONN_TYPE VARCHAR2(10 BYTE),
LOGON_TIME DATE,
LOGOUT_TIME DATE,
REDO_SIZE NUMBER
TABLESPACE SYSTEM
NOLOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;
GRANT SELECT ON REDOSTAT TO PUBLIC;
CREATE OR REPLACE TRIGGER TR_SESS_LOGOFF
BEFORE LOGOFF
ON DATABASE
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO SYS.REDOSTAT
(AUDSID, SID, SERIAL#, SESSION_ID, STATUS, DB_USERNAME, SCHEMANAME, OSUSER, PROCESS, MACHINE, TERMINAL, PROGRAM, DBCONN_TYPE, LOGON_TIME, LOGOUT_TIME, REDO_SIZE)
SELECT A.AUDSID, A.SID, A.SERIAL#, SYS_CONTEXT ('USERENV', 'SESSIONID'), A.STATUS, USERNAME DB_USERNAME, SCHEMANAME, OSUSER, PROCESS, MACHINE, TERMINAL, PROGRAM, TYPE DBCONN_TYPE,
LOGON_TIME, SYSDATE LOGOUT_TIME, B.VALUE REDO_SIZE
FROM V$SESSION A, V$MYSTAT B, V$STATNAME C
WHERE
A.SID = B.SID
AND
B.STATISTIC# = C.STATISTIC#
AND
C.NAME = 'redo size'
AND
A.AUDSID = sys_context ('USERENV', 'SESSIONID');
COMMIT;
END TR_SESS_LOGOFF;
Now, total sum of REDO_SIZE (B.VALUE) this is far less than archive log size. This at time when no other user is logged in except myself.
Is there anything wrong with query for collecting redo information or there are some hidden process which doesnt provide redo information on session basis.
I have seen the similar implementation as above at many sites.
Kindly provide a mechanism where I can trace which user is generated how much redo (or archive log) on a session basis. I want to track which all user/process are causing high redo to generate.
If I didnt find a solution I would raise a SR with Oracle.
Thanks
[V]

You can query v$sess_io, column block_changes to find out which session generating how much redo.
The following query gives you the session redo statistics:
select a.sid,b.name,sum(a.value) from v$sesstat a,v$statname b
where a.statistic# = b.statistic#
and b.name like '%redo%'
and a.value > 0
group by a.sid,b.name
If you want, you can only look for redo size for all the current sessions.
Jaffar

Redo log files in case of NOARCHIVELOG Mode.

Question is related with the oracle architure..
database requires a minimum of two redo log files to guarantee that one is always available for writing while the other is being archived, this sounds perfect when DB is running in ARCHIVELOG mode but at the same time it also forces database to have 2 redo log files even when the DB is running in NOARCHIVELOG mode?
Any particular reason..
I would look for reasons not answers on what redo log is and what information it holds etc..

pgoel wrote:
If you had only one file all further changes would have to stop until all changed data blocks had been written to disc. By insisting on a minimum of two log files Oracle can allow the log writer to fill the second log file as the database writer writes out the dirty blocks covered by changes desrcibed in the first log file.What about having a big size redo log file instead of two? Checkppoint being initiated when the redo log file is half filled
I mean, understand the logic, two is better, even best.. but still not getting convinced. I am just trying to think, can not Oracle work with 1 group with 1 big file..specailly when Noarch mode ? Having
Edited by: pgoel on Mar 12, 2011 7:27 PMNo, you still didn't understand and I am not sure how else we can say it. Okay, think about log groups as two buckets which are used to fill the redo content. The LGWR is filling one bucket at a time till it can't accept any more content. Once filled, rather than spilling the content out, it jumps over to the second bucket. Now, taking your statement of big sized redo, Pgoel, it doesn't matter how big sized bucket you bring in, eventually it will fill in. Its not possible that you wont be able to fill it , it just would take more longer than the normal timings. Thats all. So in any case , you need the second bucket. And I am not sure that why you are struck on the archivelog mode. I hope you do understand that its an optional mode. This means, this may or may not be there. If there, its a good thing that before doing the flush of the redo content, Oracle would be able to save the contents in the archived (think about the name, it's very meaning is to preserve, to archive) log file. If not, the redo content wuold be lost and there won't be any record of transactions leaving you to reenter the lost transactions. Its a meaningless point on which you are struck i.e. the archive or no-archivelog mode. Be it whatever, Oracle would still need minimum of the two log groups.
HTH
Aman....

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

When changing redo-logs on Primary, do I need to change my standby also?

Hi, I need to resize my redo logs on a primary db which has a physical standby attached. Do I need to modify this standby or will the change propagate. It seems unlikely to me.
thanx

Only clue that I have found is at
http://download-east.oracle.com/docs/cd/B12037_01/server.101/b10726/configbp.htm
Section "Use Multiplexed Standby Redo Logs and Configure Size Appropriately"
>>
The remote file server (RFS) process for the standby database writes only to an SRL whose size is identical to the size of an online redo log for the production database. If it cannot find an appropriately sized SRL, then RFS creates an archived redo log file directly instead and logs the following message in the alert log:
No standby redo log files of size <#> blocks available.
>>

Private strand flush not complete how to find optimal size of redo log file

hi,
i am using oracle 10.2.0 on unix system and getting Private strand flush not complete in the alert log file. i know this is due to check point is not completed.
I need to increase the size of redo log files or add new group to the database. i have log file switch (checkpoint incomplete) in the top 5 wait event.
i can't change any parameter of database. i have three redo log group and log files are of 250MB size. i want to know the suitable size to avoid problem.
select * from v$instance_recovery;
RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_REDO_BLKS LOG_FILE_SIZE_REDO_BLKS LOG_CHKPT_TIMEOUT_REDO_BLKS LOG_CHKPT_INTERVAL_REDO_BLKS FAST_START_IO_TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR CKPT_BLOCK_WRITES OPTIMAL_LOGFILE_SIZE ESTD_CLUSTER_AVAILABLE_TIME WRITES_MTTR WRITES_LOGFILE_SIZE WRITES_LOG_CHECKPOINT_SETTINGS WRITES_OTHER_SETTINGS WRITES_AUTOTUNE WRITES_FULL_THREAD_CKPT
625 9286 9999 921600 9999 0 9 112166207 0 0 219270206 0 3331591 5707793please suggest me or tell me the way how to find out suitable size to avoid problem.
thanks
umesh

How often should a database archive its logs
Re: Redo log size increase and performance
Please read the above thread and great replies by HJR sir. I think if you wish to get concept knowledge, you should add in your notes.
"If the FAST_START_MTTR_TARGET parameter is set to limit the instance recovery time, Oracle automatically tries to checkpoint as frequently as necessary. Under this condition, the size of the log files should be large enough to avoid additional checkpointing due to under sized log files. The optimal size can be obtained by querying the OPTIMAL_LOGFILE_SIZE column from the V$INSTANCE_RECOVERY view. You can also obtain sizing advice on the Redo Log Groups page of Oracle Enterprise Manager Database Control."
Source:http://download-west.oracle.com/docs/cd/B13789_01/server.101/b10752/build_db.htm#19559
Pl also see ML Doc 274264.1 (REDO LOGS SIZING ADVISORY) on tips to calculate the optimal size for redo logs in 10g databases
Source:Re: Redo Log Size in R12
HTH
Girish Sharma

Redo Logs

I have two instances set up with the same schema. The data in the two different instances is identicle initally. One of the instances is used and the other is not (hot spare). Is there a way to take the redo log from one instance and apply it to the other to synchronize the data?

Hi!
I don't think the problem is necessarily the size of the redo logs. Stale logs have to do more with checkpoints and log switchs and there timing. Log size has more to do with length of instance recovery. I would check your alert.log. All log switches and checkpoints are recorded there. You may have to add some checkpoint timing parameters to init.ora. You mentioned that you have a highly transactional database, you made need more log groups not bigger ones, very high transactional databases may have as many as 10 (or even 20) log groups! So I'd take a look at your logs to find out why it is going stale. You may have a lot of incomplete checkpoints causing your log to be stale. Obviously when the database can't read a log group it crashes. Also check your achive logs if your running archivelog mode, arch0 may interfering with lgwr. Also I would rebuild the log groups. It may be continually corrupting itself. I think this is a better procedure than just increasing the size, that's the last thing I'd look at. In any case,
Best of Luck
Steve
We have a highly transactional database with three sets of Redo Logs Defined at about 1MB for each. We are consistently getting a "stale" status for one set of the logs, which causes the database to go down. We are thinking about increasing the sizee of the logs to help the problem.
Any thoughts on if this is the right approach or on what would be an adequate size?

REDO LOG GROUP QUESTION

I was reading an article and it said
the distance(in bytes) between the checkpoint position in a redolog group and the end of the current redolog group can never be more then 90 % of the size of the smallest redo log group
Can someone elaborate this

I'm not sure what you want to elaborate on, but yes, it's true. If your redo logs are 100MB in size, and nothing else causes a checkpoint to take place, you'll have a checkpoint issued when you hit the 90MB mark. The idea is simply that you don't want to sit there doing nothing at all and then bang! the logs switch and you have to go hell-for-leather performing a massive checkpoint, all the while praying more log switches don't mean that you're threatening to catch up with yourself (at which point you'd have the 'thread unable to advance to log...' problem). By implementing the 90% rule, the idea is that your log switch, at worst, will cause a "10%-sized" checkpoint, which should be bearable.
Of course, the situation is made more complex by the fact that other things DO kick in and cause their own checkpoints, so the interaction between -for example, FAST_START_MTTR_TARGET and the 90% rule can get, er, 'interesting'.

Redo log data

How to find the actual data redolog contains? My redo log is of 1 GB of each group. We have moved the redolog to newer disk, so i want to know the actual size of redolog, how much data it carries and how we can analyze/tune redolog to increase performance.
Thanks

Hi,
>>How to find the actual data redolog contains?
I think that you can take a look at the "actual_redo_blks" column in v$instance_recovery dynamic performance view in order to see the current number of redo blocks required to be read in case of recovery.
>>how much data it carries and how we can analyze/tune redolog to increase performance.
Oracle 10g has introduced a redo logfile sizing advisor that will recommend a size for the redo logs that limit excessive log switches, incomplete and excessive checkpoints, log archiving issues, DBWR performance and excessive disk I/O. So, you can obtain redo sizing advice on the redo log groups page of Oracle Enterprise Manager Database Control.
Cheers

Resizing redo log files.

Hello All,
I am using Oracle RAC 11.2.0.3 with ASM.
I need you help to re size my redo logs. I know how to do that with Oracle single instance, but my question concerning Oracle RAC and ASM with Oracle Managed Files.
Below are some info based on the result returned by this query:
select l.group#,l.thread#, f.member, l.archived, l.status, (bytes / 1024 / 1024) fsize
from v$log l, v$logfile f where f.group# = l.group#
order by 1, 2
1     1     +FRA/istprod/onlinelog/group_1.257.787008381     NO     CURRENT     50
1     1     +DATA/istprod/onlinelog/group_1.261.787008381     NO     CURRENT     50
2     1     +FRA/istprod/onlinelog/group_2.258.787008383     YES     INACTIVE     50
2     1     +DATA/istprod/onlinelog/group_2.262.787008381     YES     INACTIVE     50
3     2     +DATA/istprod/onlinelog/group_3.265.787008427     NO     CURRENT     50
3     2     +FRA/istprod/onlinelog/group_3.259.787008427     NO     CURRENT     50
4     2     +DATA/istprod/onlinelog/group_4.266.787008427     YES     INACTIVE     50
4     2     +FRA/istprod/onlinelog/group_4.260.787008429     YES     INACTIVE     50I have the below question since I have RAC and ASM with Oracle Managed Files.
1. Should i be connected first to Instance 1 and do the resizing for thread 1 and then connect to instance 2 and do the resizing for instance 2?
2. Because of ASM should I use the below syntax when adding a redo log?
alter database add logfile THREAD 1 group 4 ('+DATA(ONLINELOG)','+FRA(ONLINELOG)') SIZE 100M;3. When forcing a check point a check I should use the "global" syntax as below ?
ALTER SYSTEM CHECKPOINT GLOBAL;4. Any other notes to take it into consideration ? Is there any document that help resize reo logs in my case, RAC + ASM + oracle managed files?
Regards,

NB wrote:
Hello All,
I am using Oracle RAC 11.2.0.3 with ASM.
I need you help to re size my redo logs. I know how to do that with Oracle single instance, but my question concerning Oracle RAC and ASM with Oracle Managed Files.
Below are some info based on the result returned by this query:
select l.group#,l.thread#, f.member, l.archived, l.status, (bytes / 1024 / 1024) fsize
from v$log l, v$logfile f where f.group# = l.group#
order by 1, 2
1     1     +FRA/istprod/onlinelog/group_1.257.787008381     NO     CURRENT     50
1     1     +DATA/istprod/onlinelog/group_1.261.787008381     NO     CURRENT     50
2     1     +FRA/istprod/onlinelog/group_2.258.787008383     YES     INACTIVE     50
2     1     +DATA/istprod/onlinelog/group_2.262.787008381     YES     INACTIVE     50
3     2     +DATA/istprod/onlinelog/group_3.265.787008427     NO     CURRENT     50
3     2     +FRA/istprod/onlinelog/group_3.259.787008427     NO     CURRENT     50
4     2     +DATA/istprod/onlinelog/group_4.266.787008427     YES     INACTIVE     50
4     2     +FRA/istprod/onlinelog/group_4.260.787008429     YES     INACTIVE     50I have the below question since I have RAC and ASM with Oracle Managed Files.
1. Should i be connected first to Instance 1 and do the resizing for thread 1 and then connect to instance 2 and do the resizing for instance 2?Yes, that would be appropriate.
2. Because of ASM should I use the below syntax when adding a redo log?
alter database add logfile THREAD 1 group 4 ('+DATA(ONLINELOG)','+FRA(ONLINELOG)') SIZE 100M;
Yes.
3. When forcing a check point a check I should use the "global" syntax as below ?
ALTER SYSTEM CHECKPOINT GLOBAL;
Yes.
>
4. Any other notes to take it into consideration ? Is there any document that help resize reo logs in my case, RAC + ASM + oracle managed files?Not really something that comes to mind right away. But you have very small sized log files at the moment and you are adding (or planning) now too about 100M. You may want to check that the size chosen by you is adequate enough not to cause you any checkpointing issues in the later run.
HTH
Aman....

Larger redo log file members or more log groups

Oracle 11gR1 RHEL5 64 bit
Hi,
I was wondering what is better from a perfomance tuning perspective. I have log swiches occuring every 2 minutes in our production database. I know definitely that our log file members are too small (100MB). The redo log sizing tool in OEM told me to make it 40G according to the fast_start_mttr_target setting which is set to 600. Now, my question is what is better to do?
1. Increase the size of my current redo log members? Right now there are 4 groups with 2 members in each.
OR
2. Should I create additonal redo log groups (4 more) and then re-rerun the sizing tool or query the v$instance_recovery view?
Which is better? tradeoffs?
Thanks all.

If you want to reduce the number (frequency) of Log Switches, you should increase the size of the Online Redo Logs -- ie create new Log File Groups of a larger size and drop the older ones.
If the issue is "checkpoint not complete" waits, then either
a. Increasing the size of the Log Files
or
b. Increasing the number of Log Files
is doable
Note that if you increase the number but not the size, you still have a checkpoint every N Mbytes -- ie, possibly too frequently !
On the other hand if you increase your size to be very large, at every switch, the Archiver is going to kick in with a large Read + large Write operation -- reading that Redo Log of N GBytes and writing it out to the archive log target location, imposing that additional I/O spike on your system. (Writing to filesystem will go through the FileSystem Buffers so if your database SGA isn't very large and your database performance relies on hitting the FileSystem Buffer Cache to avoid Disk Reads, that performance will be impacted as a large portion of the FileSystem Buffer Cache will be taken over by the Archiver for some time).
Hemant K Chitale
http://hemantoracledba.blogspot.com

Redo log and buffer size

Hi,
i'm trying to size redolog and the buffer size in the best way.
I already adjusted the size of the redo to let them switch 1/2 times per hour.
The next step is to modify the redo buffer to avoid waits.
Actually this query gives me 896 as result.
SELECT NAME, VALUE
FROM V$SYSSTAT
WHERE NAME = 'redo buffer allocation retries';
I suppose this should be near to 0.
Log_buffer is setted to 1m.
And i read "sizing the log buffer larger than 1M does not provide any performance benefit" so what can i do to reduce that wait time?
Any ideas or suggestions?
Thanks
Acr

ACR80,
Every time you create a redo entry, you have to allocate space to copy it into the redo buffer. You've had 588 allocation retries in 46M entries. That's "close to zero"..
redo entries 46,901,591
redo buffer allocation retries 588The 1MB limit was based around the idea that a large buffer could allow a lot of log to accumulate between writes with the result that a process could execute a small transaction and commit - and have to wait a "long" time for the log writer to do a big write.
If in doubt, check the two wait events:
"log file sync"
"log buffer space".
As a guideline, you may reduce waits for "log buffer space" by increasing the size of the log buffer - but this introduces the risk of longer waits for "log file sync". Conversely, reducing the log buffer size may reduce the impact of "log file sync" waits but runs the risk of increasing "log buffer space" waits.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Sizing redo logs

Similar Messages

Maybe you are looking for