Too many redo log file (merged) [message #265432] |
Thu, 06 September 2007 05:36 ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
vikeshcool@hotmail.com
Messages: 27 Registered: August 2007
|
Junior Member |
|
|
hi,
I am stuck in this very task .
In our project we have a single database
having 10 schemas . each one is facing a huge
transactions in it . bcoz of this many redo log
file's got generated and slow down the database
and also take a huge space.
what we have think so far is to make two database
and make a db link between them
and make a archive log mod on in one and
off in other
our system is a window based system
and database is 10 G
please tell me the solution for this , if u have a
better Idea
|
|
|
too many redo log file [message #266195 is a reply to message #265432] |
Mon, 10 September 2007 03:05 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
vikeshcool@hotmail.com
Messages: 27 Registered: August 2007
|
Junior Member |
|
|
hi,
I am stuck in this very task .
In our project we have a single database
having 10 schemas . each one is facing a huge
transactions in it . bcoz of this many redo log
file's got generated and slow down the database
and also take a huge space.
what we have think so far is to make two database
and make a db link between them
and make a archive log mod on in one and
off in other
our system is a window based system
and database is 10 G
please tell me the solution for this , if u have a
better Idea
|
|
|
|
|
|
|
|
Re: Too many redo log file (merged) [message #266440 is a reply to message #265432] |
Mon, 10 September 2007 22:43 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
vikeshcool@hotmail.com
Messages: 27 Registered: August 2007
|
Junior Member |
|
|
what's the difference between
setting the
nologging at database level
nologging at tablespace level
nologging at table level
I want to exclude some of the schema's
and I know there tablespace as well
If I put nologging at tablespace level
then the entries related to indexes and others
goes into the redo's or not????????
how can I achieve it
|
|
|
|
Re: Too many redo log file (merged) [message #266446 is a reply to message #266440] |
Mon, 10 September 2007 23:09 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
![](http://www.orafaq.com/forum/images/custom_avatars/102589.gif) |
Michel Cadot
Messages: 68678 Registered: March 2007 Location: Nanterre, France, http://...
|
Senior Member Account Moderator |
|
|
Do you know the implication of putting something in NOLOGGING? Do you how to restore your database in this case?
Do you know that NOLOGGING only applies for some special operations and not all?
Do you know that after a NOLOGGING operation you MUST take a backup?
Logging is not optional, it is a key component of database. It is mandatory for consistency and recovery.
You have many logs then you surely need it. Oracle does not do something just for its pleasure.
Regards
Michel
[Updated on: Mon, 10 September 2007 23:11] Report message to a moderator
|
|
|
Re: Too many redo log file (merged) [message #266447 is a reply to message #265432] |
Mon, 10 September 2007 23:15 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) |
![](http://www.orafaq.com/forum/images/custom_avatars/136107.jpg) |
BlackSwan
Messages: 26766 Registered: January 2009 Location: SoCal
|
Senior Member |
|
|
Ready, Fire, Aim!
From my perspective, you've made two observations.
1) You've reported "many redo logs", but have NOT quantified at what value "many" becomes a problem.
2) You've reported the database slows down; again without quantification.
Without any evidence, I doubt that "many redo logs" are the root cause of the database slowing down.
When ANY change is made to a database, 1 of 3 possibilities will occur:
1) No change in performance will occur.
2) Performance will get worse.
3) Performance will get better.
So if you are randomly making guesses & changes, the odds are against you for making performance better.
Never confuse movement with progress.
Going around in circles is movement, but most folks don't consider it to be progress.
I wish you the best of luck at catching your wild goose.
Rhetorical question - How many calendar days & how many incorrect/failed "fixes" do you get before your boss decides somebody other than you is needed to solve this problem?
|
|
|