Re: Redo logs - need a guru

From: Steve Dodsworth <Steven_Dodsworth_at_qsp.co.uk>
Date: 1996/07/22
Message-ID: <4t0826$n5k_at_mailhost.qsp.co.uk>#1/1


In <4svvma$a6h_at_atlas.aethos.co.uk>, steve_at_aethos.demon.co.uk (Steve Holdoway) writes:
>Dear All,
>
>Can anyone out there spread some light on how or if we can improve the
>performance of our system. We are still benchmarking Oracle 7.2.3 on
>HP-UX 10.10, using a 5 processor T520, and 14Gb of Mirrored disc ( 14
>X 2 Gb discs over 4 controllers ). Nice toys, huh!
>
>The bottleneck to the whole system seems to be the Redo logs. We have
>tried up to eight redo logs of up to 1Mb in size, scattered out of the
>way of the database. When benchmarking, the system sprints along until
>it has filled up all of these, and then waits for the first one ( or
>is it all ) to drain out before starting up. Or, in effect, the whole
>system stops for about 30 seconds whilst it untwists its knickers.
>
>We would prefer to have a degredation in absolute performance and a
>constant throughput than this situation. Is there any way that we can
>get the redo logs draining down and doing their bit whilst the main
>application performs most of its work on the parts of the table that
>are resident in the SGA?
>
>If so, how do we do it? We found that bigger redo logs stopped the
>system less often but for longer. Should we try using hundreds of
>small redo logs? Or just run the Log Writer as a realtime process?
>
>Any ideas will be gratefully received, the more off the wall they are,
>the more fun we'll have in testing them!
>
>The weirdest thing is that we're getting approximately the performance
>that we expected out of this system, it just doesn't seem to be trying
>at all!
>
>TIA
>
>Steve.
>
>
>

Steve - this is a non-guru answer,

  1. increase your log size, we have 15mb ones
  2. include the checkpoint_process=true in the init.ora (this will stop the lgwr from becoming overused
  3. Make sure you have logs on their own disks NOT STRIPED
  4. duplexed copies (within oracle) should not be on the same disk (need to add this as i've seen it happen)
  5. If you are archiving logs, then each individual log should be on separate disk, or as best as you can manage.

If you haven't got point (2) set, that may be the fix for you.

Bye,
Steve


| any similarity 'tween my opinions and that |
|  of my employers are purely hypothetical   |
|     and should give no cause for alarm     |
 --------------------------------------------
Received on Mon Jul 22 1996 - 00:00:00 CEST

Original text of this message