Re: trigger script after archive log switch

Philip Brown wrote:
>
> We do not want to implement a standby database at this time.
> We are looking to have a remote machine store reasonably up-to-date
> archive logs, for disaster recovery purposes. We already have a
> clustered database. So this other site is mainly for storing data, for
> by-hand recovery at a later time.
> We may have multiple databases dumping their archive logs to this one
> machine. We dont want to be running 10 standby instances of oracle for this
> purpose.
>
> Immediate startup of another database is not neccessarily a priority.
> However, having the most current set of data, *is*.

OK, now we're getting somewhere. All good reasons why a tns service entry won't work for you. So why not a remote NFS mount coupled with an optional log_archive_dest_n parameter?

> Yes, we have looked at the reopen option. That does not address the problem
> of "the connection to the remote machine has been down through multiple
> archive log writes". Or at least it didnt in our tests so far.
> It merely wrote the latest log, leaving a gap in the log sequence.
>
> The script to be triggered, will intelligently evaluate whether it needs to
> copy over just the latest archive log, or multiple ones that did not make
> it previously.

OK, so you seem to be unable to tolerate the possibility that an optional log_archive_dest_n parameter to an NFS mount might fail and cause a gap in the logs that are copied by Oracle, requiring manual intervention. So why not set your log_archive_dest_n parameter to mandatory? In other words, how serious are you that you must have the latest archive copied remotely? Yes, remote archiving might fail, NFS might fail, etc., all of which *could* lead to a halted production database. But what happens when your homegrown script fails? Your production database may not halt, but you'll still get a gap. How important is this remote destination *really*? If it's important, set it mandatory and monitor your alert.log and v$archive_dest for archiving errors so that you can fix problems before the instance halts. If it's not that important, set it to optional and monitor your alert.log/v$archive_dest for errors to determine when manual intervention is necessary.

Regards,
Sean M Received on Wed Jun 26 2002 - 18:45:26 CDT