Re: 2nd Archive Destination Question

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:<52zB9.78002$g9.219675_at_newsfeeds.bigpond.com>...
> "Paul Drake" <drak0nian_at_yahoo.com> wrote in message
> news:1ac7c7b3.0211161253.5408dce4_at_posting.google.com...
> > Chuckster <chuckycarson_at_networkcloud.com> wrote in message
> news:<3DD2F268.1040107_at_networkcloud.com>...
> > > Under Oracle 8.1.7, if you specify two archive destinations, will the
> > > database hang if one of the destinations run out of space? (ie: It can
> > > still right to the other destination)
> > >
> >
> > Chuckster,
> >
> > not related to a standby is
> > duplexing the archived redo logs - locally.
> > if you specified a parameter/value in the init.ora for
> > log_archive_duplex_dest
> > then both destinations are statically mandatory.
> >
> > Paul
>
> That's not actually true, Paul. First of all, let's distinguish between
> LOG_ARCHIVE_DEST/LOG_ARCHIVE_DUPLEX_DEST (which are your only options in the
> Standard Edition, and anything prior to 8i) and LOG_ARCHIVE_DEST_n, where
> "n" can be anything from 1 to 5 (in 8i Enterprise Edition) or 1 to 10 (in 9i
> Enterprise Edition).
>
> If you use the _ARCHIVE_DEST/_DUPLEX_DEST combination, then you have also to
> be aware of the LOG_ARCHIVE_MIN_SUCCEED_DEST parameter. That can be set to
> either 1 or 2. It defaults to 1. Meaning that, by default, only one of the
> archiving destinations is considered mandatory, and the one that is assumed
> to be mandatory is the LOG_ARCHIVE_DEST one. If you set it explicitly to 2,
> then both are considered mandatory.
>
> Point being, merely setting the DUPLEX_DEST does *not* make both
> destinations "statically mandatory", but would only imply the _DEST
> destination was.
>
> Regards
> HJR
Howard,

thanks for setting me straight without ripping my head off. Actually, I went back to the docs just to make sure ...

http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76993/datastru.htm#8148

http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76956/archredo.htm#4304

and then turned on duplexing on an 8173 std ed db. how about that - it worked.
too bad that in sqlplus an "archive log list" command doesn't show both locations. in fact - it showed the duplex destination - not the original one.

the duplex_dest was indeed optional, as the default setting for log_archive_min_succeed_dest was = 1.
after removing permissions on the duplex folder from the user that owns the service (which is not localsystem) an error was indicated in the alert log, but in v$log, the online redo log was listed as 'archived'.
after setting log_archive_min_succeed_dest = 2, it did complain in the alert log that no available destinations were available. after setting log_archive_min_succeed_dest = 1, it did complain that it could not write to the duplex_dest in the alert log, but the log was marked as archived.

wow.
I thought that duplexed archived redo logs was not available in 8.1.7 Standard Edition. I had only used it once - at a site where their external storage cabinet had a nasty habit of becoming unavailable whenever their ops people poked around in the rack ... so I had internal and external redo group members and used the duplexing feature - and that was running enterprise edition.

I think that in the past I had confused the LOG_ARCHIVE_DEST_n features that were enterprise ed only with the duplexing feature.

thanks for the info.

Paul Received on Sat Nov 16 2002 - 23:19:05 CST