Re: Redo killer

Mike Moore wrote:

>
> Some details: 9i with RAC on Tru64 Unix, disk and RAM are scaled for
> so are not a problem for now.
>
> We're switching 8-12 times per hours on redo logs that are 100 MB a
> piece when this process is running. There is a similar process that
> also hammers the logs. So when these jobs are running I'm getting a
> couple gig of redo for data that has a useful life of a few hours.
> This is just stupid! With the exception of when these couple of batch
> process run the logs switch once every couple hours.
>
> I hate to add redo for bad code. Plus, it hurts my MTTR numbers.
>
> Thoughts? Suggestions? Comments? Solutions?

Unless you are running with archive log mode on and archiving (which you don't mention), all the redo files provide is a circular, reusable buffer.

Setting crashes & recovery aside, who cares about the redo and how often they switch? <gasp>

What I mean is: the frequency of switches and the size may contribute to the problem (indeed may be the sole cause of a problem), but in general these factors are not _the_ problem.

I preceive that the term 'hammers the logs' is somewhat at the core, but that can have several interpretations. So call me crazy, but I still don't understand the problem you are trying to address. Some of the possible problems I could understand:

1. You are using archive log mode and the amount of apparently useless archive log being generated is causing a disk or performance issue;
2. The frequent log switches during the batches are slowing things down.

Since I don't understand the actual issue, generic questions:

Do you have any control over, or access to, the batch code? Are _certain_ tables being used as intermediate results tables that could be redefined as GTTs, or at least nologging? Can you _selectively_ move stuff to temporary tablespace?

/Hans Received on Wed Oct 27 2004 - 09:20:02 CDT