Re: archivelog leads to crashes...?

Thanks for the great tips and explanation of what I was missing. I'll add those keywords to my googling this afternoon.

_Am

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<40561367$0$31902$afc38c87_at_news.optusnet.com.au>...
>
> Understand what "putting a database into archivelog mode" actually means. It
> means setting a bit in the control file which says "you are no longer
> permitted to over-write the contents of the online redo logs unless they
> have been archived".
>
> And that's it.
>
> It says nothing about actually *taking* the archives in the first place.
>
> Therefore, you've just successfully instructed your database to fill up all
> the online logs and then come to a grinding halt, because no further online
> logs are available, and the ones you've got can't be over-written.
>
> What you've now got to do is the second step, which I see others have
> mentioned already: arrange for the archives of your online logs to actually
> be generated, automatically if possible. That is best done by switching on
> ARCH, and that in turn is done by setting LOG_ARCHIVE_DEST or
> LOG_ARCHIVE_DEST_n (n is a number between 1 and 5 in 8i) in your init.ora.
> Use the former if you've only got the standard edition or if you are using
> the Enterprise Edition but are happy with just two archive destinations. Use
> the latter if you are using the Enterprise Edition, want more than two
> archive destinations and/or would like to archive to a remote database.
>
> Since you obviously check things out online before posting here, you might
> add LOG_ARCHIVE_DUPLEX_DEST, LOG_ARCHIVE_MIN_SUCCEED_DEST and
> LOG_ARCHIVE_FORMAT to the list of parameters to be researched in this
> regard.
>
> Regards
> HJR
Received on Tue Mar 16 2004 - 11:22:50 CST