Re: Need help re: VB app copying redo log archives

From: Sean M <smckeown_at_adelphia.net>
Date: Tue, 07 Jan 2003 22:25:59 GMT
Message-ID: <3E1B543C.6050003@adelphia.net>

Karsten Farrell wrote:

> Joe Tseng wrote:
> 

>> I've been asked to write a VB6 app to have any redo archive files
>> copied to an alternative location where they'll be saved to tape. I
>> was told this app should be smart enough to leave any open archive
>> file that is being appended to by the database alone until the next
>> time the app is run.
>>
>> Is there any programmatic way to determine if a file is open by
>> another process? I didn't see any method or property in FSO that did
>> this. I thought I could perhaps suck in the results of "net file",
>> but I'm not entirely sure that would work as I do not know how Oracle
>> copies its redo logs to the .ARC files.
>>
>> Any useful suggestions will be greatly appreciated.
>>
>> Joe

> 
> An Oracle background process, ARCH, copies the online redo log files to 
> an archived redo log file once it fills up. Depending on your operating 
> system, you might not be able to open the archive file currently being 
> written. But since ARCH writes to only one at a time, in serial fashion, 
> you might be better off if your VB6 app simply ignores the most recent 
> .arc file whenever it's called (I assume your app runs periodically and 
> not manually).
> 

Careful - any given ARCH process is only writing to one archive at a time, but you *can* have multiple ARCH processes writing to multiple archives simultaneously. This can happen if you're generating redo faster than you can archive it - a new online redo fills up before a previous log has finished being archived.

If you're not going to use RMAN to manage your backups, you'll want your script to be a bit paranoid (after all, these are your backups we're talking about). For example, our archive manage script 1) checks the file with 'fuser' to see if there are any open processes on it; 2) queries the database to make sure the database says it's done with it (not a trivial query when standby databases are involved); 3) copies (not moves) the file to the remote destination; 4) does a checksum on the source file and dest file and compares results; and 5) if the checksum comes back identical, it deletes the source file.

Given these complexities, I can't say I'd recommend this method if you don't have much experience with Oracle backup and recovery. Probably worth looking into RMAN.

Regards,
Sean Received on Tue Jan 07 2003 - 16:25:59 CST