Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: 8.1.7.4 standby database - missing some log files???

Re: 8.1.7.4 standby database - missing some log files???

From: BD <bobby_dread_at_hotmail.com>
Date: 27 Apr 2006 13:22:48 -0700
Message-ID: <1146169368.587037.3580@u72g2000cwu.googlegroups.com>


>It sounds like you have set log_archive_dest_2 to the standy service?

Yes.

>By the 'first' logfile, do you mean the one generated by the foreground switch?

I've just scrutinized my process more closely, and I think there may be an issue with the standby actually getting a complete set of redo each time I do the recover. When I trigger the recovery and it chews through the log files, it always fails at the last one: I see it successfully apply #100 - #104, and then I see the following:

ORA-00308: cannot open archived log
'/home/oracle/admin/REP2/archive/arch/arch1_REP2_105.arc' ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory Additional information: 3

I kind of assumed that this happened because the recovery will keep looking for files until it can't find any more - but the fact that it's looking for #105 must mean it _needs_ it! I may be confused as to what mechanism is driving the recovery - looking for subsequent log files, or actively looking for a current change number (in which case, the recovery is not really 'completing' each time).

Anyway. After that recovery, I flip back into read only mode, and continue normal operation. I run my 'recovery' script again, and it once again fails to find file #105. I go to the file system, copy that file from the archive_dest_1 to archive_dest_2, do the recover again, and it continues. successfully.

Since the required change number is reported as each log file is processed, I gather that it's getting all it needs. I think the key here may be the fact that on each recovery it fails when it tries to find the last file - it's this same file which does not end up being automatically copied to the second archive_dest.

>I can't remember if 8.1.7 had a FAL (Fetch Archive Log) process. If
>not, you will probably have to read the v$archived_log view on the
>priamry and copy any ones you are missing, prior to issuing the
>"recover standby database" command.

Yeah - not my first choice; I'd at least want to understand what is causing this gap. ;) Received on Thu Apr 27 2006 - 15:22:48 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US