Re: trigger script after archive log switch

On Tue, 25 Jun 2002 21:58:26 GMT, phil+s3_at_bolthole.no-bots.com (Philip Brown) wrote:

>On Tue, 25 Jun 2002 15:32:59 -0600, smckeownNO_at_BACKSIESearthlink.net wrote:
>>Hi Philip-
>>
>>You seem to have 2 criteria that are at odds with each other: 1) you
>>want to guarantee that an archive is copied to an alternate location the
>>instant it is created but 2) you don't want to let Oracle do this for
>>you (using multiple archive_log_dest params). You can't have both. If
>>you want Oracle to guarantee that an archive is copied to an alternate
>>location the instant it is created, you need to let Oracle do this
>>through it's own built-in mechanisms.
>
>I dont want to have Oracle guarantee that an archive is copied. I just want
>Oracle to tell me when the archive is created. I can take care of the
>guarantees on copy myself :-)
>

Yes, you DO try to be 'smart' and know better. This will result in inevitable failure, as most likely you don't. You're going to design something that belongs where it came from: in a bike-shed company. You just confirmed my initial suspicions. Most often, people think they are 'smart' just aren't. The 'smart' 'solutions' I had to address always were very unreliable.

>
>> If you don't want to use Oracle's
>>built-in mechanisms which guarantee this copy,
>
>It was my understanding that in no way does oracle guarantee the remote copy.
>It TRIES to make the copy, and if it doesnt make the copy, it marks the
>archive destination as failed, and no longer tries to write to it for
>future archive logs. (until you manually go in and bump it)
>Unless you mark it as mandatory, in which case, oracle wont run if the
>remote location is unavailable at that point.

Of course the remote location should be a sqlnet service destination, not NFS. NFS is one of the most unreliable network mechanisms ever invented. If you're going to rely on NFS, you will get hurt, even when using your own 'smart' 'solution'

Have you ever used the REOPEN attribute and followed what happened. You just don't have to 'bump it'

>
>Neither choice is acceptible to me, therefore, i want to be able to handle
>the copy/updates myself.
>
>
>> you will have to poll
>>(either the database itself via v$archived_log or the OS via ls, etc.)
>>on some interval.
>
>Is it kosher to put a trigger on v$archived_log for this purpose, then?
>

You can't have triggers on v$ views (neither on the underlying tables) and that is GOOD.
>
>> If you're suggesting that your interval would be on
>>the order of 1 second, you're implying that you need a *guaranteed* copy
>>the instant the archive is created.
>
>No, not that stringent. I want my script to be called reasonably quickly
>after the redo log has been archived.
>After kicking off the script, oracle will continue running reguardless of
>what the script has to do, and the copy will take place at the system level,
>in the background.
>

Most likely you script can't keep up with Oracle and is going to miss files
>>It might help matters if you could explain your multiple reasons for not
>>wanting to use multiple archive destinations w/in Oracle (I assume this
>>has something to do with security concerns),
>
>Actually, more disaster recovers reasons. But security is also an issue.

Implement a *proper* standby database. NOT your own. I have seen that in operation. It just DOESN'T WORK!
>
>> I'd also suggest you be very careful about checking to be sure
>>Oracle is done with the file before initiating your copy.
>
>absolutely :-)
>But it would be nice if oracle would tell me "I'm done now", rather than
>a few redundant cycles of
> >> Check that oracle is not done; nope, loop and check again

Regards

Sybrand Bakker, Senior Oracle DBA

To reply remove -verwijderdit from my e-mail address Received on Tue Jun 25 2002 - 18:25:50 CDT