Re: Simple archivelog question

"Charlie Edwards" <charlie3101_at_hotmail.com> wrote in message news:217ac5a8.0210030106.26ba2f95_at_posting.google.com... [Snip]
>
> Thanks for your help on this.
>
> I am a bit curious as to the performance issue, however.
>
> Tom Kyte (http://asktom.oracle.com/pls/ask/f?p=4950:8:1382355) says:
> <quote>
> Archive logging, in a properly configured system, adds 0% performance
> degradation. It is all about IO. If you have the right number of
> devices and
> IO channels -- no worries, no "degradation".
> </quote>
>

I don't usually disagree with Thomas (I just borrowed that line from Jonathan!), but that's a mighty big "if" he's thrown into the middle of that last sentence!!

He's correct, of course, that properly configured, the costs are negligible. But you have to watch out for things like: running out of archiving space (hangs the database), reading from one redo log to archive it whilst LGWR is writing to another group that's on the same disk (I/O contention), ARCH not keeping up, leading to a backlog of ACTIVE logs, and a potential database hang when you loop back to group 1, and so on.

Now if you can spread your logs out on multiple disks, ensure you never run out of archiving disk space, and have lots of disk controllers, then yes -a lot of these problems go away.

Trouble is, if you're slightly wrong in your configuration, the costs can mount horribly: anything that gets in the way of LGWR doings its usual job impacts on the entire database. It's (potentially) the Achilles' heel of the entire system. And if ARCH isn't tuned properly, then you *do* start impacting on LGWR, and hence the entire show goes off the rails.

> I guess the key is having a sufficient hardware configuration so that
> the IO issues will be minimised.
>

Exactly. As I say, Tom's "if" is the key issue.

Regards
HJR
> But I suppose, as you say, "you can compromise performance by
> archiving" if your hardware isn't up to it (which is possibly the case
> here).
>
> Thanks,
>
> CE
Received on Thu Oct 03 2002 - 04:28:39 CDT