Re: performance problems after increasing redolog size

Summary: 3 redolog files of 1M, no archiving => 4 redologs of 10M, archiving started. All on Raid 5. (raid 3,5,S and other types are not suited for heavy writing - but are happy when reading)

Correct so far?

If thats the case, if possible, get the redologs off the raid 5 and onto plain disks.

Your problem is, while importing you generate tons of redo, so every time you switch the redologfile, say from log2 to log3, the archiver sets in and starts reading from log2, while the logwriter tries to write to log3. If they are both on the same device or raid, you create io contention. To make things worse, version 817 on windoze, starts more archive processes if current archiver lacks behind (your case?). Even if log_achive_max_processes is set to 1. And you can get a situation where several archive processes try to archive the same redolog (one succedes - the other fails) But more processes battle for the same i/o bandwith.

The simple solution is to interleave the logs in a schema like

log1 log4 log7 on device a (multiplex to device d if possible)
log2 log5 log8 on device b (multiplex to device e if possible)
log3 log6 log9 on device c (multiplex to device f if possible)

this way the archiver has amble time reading before the logwriter hits the same device with writes.

Set the logbuffer at ~3½ Meg, the logwriter starts anyway if the buffer is 1/3 full or unwritten data amounts to 1M.

Rgds

/Svend Jensen

Bud Socks wrote:
> Hi there,
>
> due to high frequent logfile switching i have added a new redolog and
> increased the size of the redologs
> from 1 MB to 10 MB. We now have 4 redologs.
>
> Since then we are facing heavy performance losses. For example : a weekly
> performed import needed
> approx. 2h runtime. Now, after the redolog modification this job needs more
> than 24 hours to complete.
>
> How can this be ?
>
> Are there any corresponding parameters which need to be added to the
> ini<sid>.ora as well ?
>
>
>
> Thanks for help
> Bud
>
>
>
>
>
>
>
>
Received on Wed Mar 05 2003 - 15:33:16 CST