Home » RDBMS Server » Server Administration » About Oracle ReDo log groups (Oracle 10g)
About Oracle ReDo log groups [message #585007] Tue, 21 May 2013 06:30 Go to next message
Manoj.Gupta.91
Messages: 239
Registered: March 2008
Location: Delhi
Senior Member
Hi All,

I've a situation where I've very less redo logs generated. Let us say 10MB. Which solution will be better ?

1. Create one redo log group about 12 MB in size.
2. Create two redo log groups about 5 MB each in size as recomended by Oracle.

Which one will be a good idea in terms of performance and why ? Eventhough solution 1 is also appropriate for me because I've less redo generated than the redo log group size. My whole redo will fit in this and I can raise checkpoint forcefully after certain period of time let us say every 3 seconds.

In one of our DB I found scenario one is implemented. So I want to know pros and cons of both of these practices.


Thanks & Regards
Manoj
Re: About Oracle ReDo log groups [message #585008 is a reply to message #585007] Tue, 21 May 2013 06:36 Go to previous messageGo to next message
John Watson
Messages: 8922
Registered: January 2010
Location: Global Village
Senior Member
Is your 10M of redo being generated per second or per century?
Re: About Oracle ReDo log groups [message #585010 is a reply to message #585008] Tue, 21 May 2013 06:40 Go to previous messageGo to next message
Manoj.Gupta.91
Messages: 239
Registered: March 2008
Location: Delhi
Senior Member
Hi,

Per day and DB is shut down every evening and started in the morning.

Thanks & Regards
Manoj
Re: About Oracle ReDo log groups [message #585011 is a reply to message #585010] Tue, 21 May 2013 06:54 Go to previous messageGo to next message
John Watson
Messages: 8922
Registered: January 2010
Location: Global Village
Senior Member
I would use three 50M groups, each with two members, and set archive_lag_target=1200
As for performance, do not force checkpoints and do not shutdown the database. Ever.

Other people may have other ideas, of course, but you won't get fired if you do it like this.
Re: About Oracle ReDo log groups [message #585013 is a reply to message #585011] Tue, 21 May 2013 07:05 Go to previous messageGo to next message
Manoj.Gupta.91
Messages: 239
Registered: March 2008
Location: Delhi
Senior Member
Hi,

50M group will take atleast 5 days to fill it completely. Don't you think it's too big?
I don't have much idea about redo size organization. Please elaborate little more


Thanks & Regards
Manoj
Re: About Oracle ReDo log groups [message #585014 is a reply to message #585013] Tue, 21 May 2013 07:12 Go to previous messageGo to next message
John Watson
Messages: 8922
Registered: January 2010
Location: Global Village
Senior Member
You haven't bothered to look up the archive_lag_target parameter, have you? I am not going to reply again until you prove that you have read chapter 12 of the 11.2 Administrator's Guide.

Enjoy! An opportunity to study is always good.
Re: About Oracle ReDo log groups [message #585016 is a reply to message #585014] Tue, 21 May 2013 07:23 Go to previous messageGo to next message
Manoj.Gupta.91
Messages: 239
Registered: March 2008
Location: Delhi
Senior Member
http://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams009.htm

archive_lag_target=1200 will force a log switch after 20 min.

But why you have asked to create 50M log group although we know that with these setting anyhow log switching will occur in 20 minutes and only a part of log group will be filled till that time. We will never be filling more than 10M in a day. Is there any performance benefit of taking big size log group ?

Thanks & Regards
Manoj
Re: About Oracle ReDo log groups [message #585195 is a reply to message #585007] Wed, 22 May 2013 22:01 Go to previous message
deeplydrink
Messages: 14
Registered: May 2013
Location: Beijing
Junior Member
why not use the default setting of db

three groups and one member for each which the size is about 50M
Previous Topic: Restarting AWR snapshots after errors.
Next Topic: about sga
Goto Forum:
  


Current Time: Thu Mar 28 15:58:23 CDT 2024