Re: most expeditious way to update a large number of rows

hpuxrac wrote:
> Umm no 700 divided by 10 is 70 not 13 so if your number is correct on
> amount of redo that's 70 log switches. If your system drives the
> filling of logs so quickly that the archiver cannot keep up ( ie you
> run out of free logs where archiving has been successfully completed )
> during those internals that's potentially a bunch of times where
> activity in your system might freeze until the next redo log is
> available.

This is precisely the situation I'm trying to avoid...redo logs filling so quickly that the archiver can't keep up.

>
> Log switches force system checkpoints where data blocks in the buffer
> cache that are protected by redo are flushed out to disk.
>
> That's necessary overhead and the way oracle recovery is based but it
> is additional impact to your system. Is it noticeable for your system
> and your application? That's your call.
>
> Tom Kyte has a bunch of good online information in the form of
> questions and answers over at http://asktom.oracle.com ... there's an
> item that talks about the relationship between log switches and
> checkpoints that you may want to look at.

I'll have a look at Tom's articles. It seems a combination of larger redo log groups (perhaps 100 MB) and a sensible value for ARCHIVE_LAG_TARGET will suit me best.

Thanks,
Myles Received on Tue Oct 17 2006 - 07:21:57 CDT