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

myl..._at_gmail.com wrote:
> 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.

You are hopefully aware that messages related to the archiving activity ( and problems being experienced if any ) do get written to the alert log.

There are situations I believe where depending on how you have the standby database receiving information not only the archiving but transmissions of logs to the standby can also interact.

( We use EMC and SRDF at my site ... my experience with standby database's is not so recent anymore ).

 >
> 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.

Perhaps so but you want to approach changing things carefully and find some ways to test and demonstrate what you are doing and why. Don't believe anybody ... prove it yourself on a system that's modeled or based on your real world working environment. Received on Tue Oct 17 2006 - 07:32:22 CDT