Re: Redo logs - need a guru

From: Tony Noble <tnoble_at_mt.gov>
Date: 1996/07/24
Message-ID: <4t63p3$67f_at_umt.umt.edu>#1/1


In article <4svvma$a6h_at_atlas.aethos.co.uk>, steve_at_aethos.demon.co.uk says...
>
>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.
>
>
>
you may want to run the optional checkpoint process, CKPT, so that the logwriter process, LGWR, doesn't have to do checkpoint switches. Quoting from 'Tuning Oracle' by Michaeal Corey, et al. "...allowing the log writer process to synchronize these data files may slow down or halt processing momentarily while the header information in the datafiles is updated."

-- 
Tony Noble
tnoble_at_mt.gov
Opinions expressed do not necessarily reflect those of my employer.
Received on Wed Jul 24 1996 - 00:00:00 CEST

Original text of this message