Re: RAC and Dataguard

From: Andrew Kerber <andrew.kerber_at_gmail.com>
Date: Wed, 27 Mar 2013 15:13:05 -0500
Message-ID: <CAJvnOJYUf9As4aVPwHMtTQsZUfKUPcAHneNMChJeiqoM=7FVTg_at_mail.gmail.com>

If the redo logs are present on shared storage then the standby should be able to access them. It should not matter that one node of the RAC is down, the other instance should know everything necessary about the files and should be able to access them as long as they are present. On Wed, Mar 27, 2013 at 3:07 PM, Viljo Hakala <hakala.viljo_at_gmail.com>wrote:

> Hi,
> We had a situation where data guard is used in a maximum performance mode
> and one (primary node) of the two RAC nodes failed after forceful reboot
> and primary hadn't switched logs yet, but
> the redo logs were of course available in ASM for the other instance. (
> Actually, the motherboard fried, and we had to wait a few days for a new
> part. )
>
>
> This means that the standby site would be missing some of the redo
> information present in the redo logs of the primary RAC node.
>
> How to remedy this situation to avoid standby not missing information from
> the redo logs?
>
> Would you mount the standby in recover standby mode and register these
> unapplied redo logs manually for example:
>
> ALTER DATABASE REGISTER LOGFILE '<archive destination with archive file>';
>
> Would it work ? Is it safe? Or would we have to rebuild the standby once
> primary node comes back?
>
> We haven't tested it, so we waited until we got the new motherboard and
> until we got the server backup and started switching and delivering logs
> again.
>
> What happens when the primary node comes back and switches its redo logs?
> Will these archive logs be skipped on the standby?
>
>
> None of my colleagues were certain about this. so that's why I'm reaching
> out on this issue?
>
> TIA,
>
> Viljo
>
>
>
>
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'


--
http://www.freelists.org/webpage/oracle-l

Received on Wed Mar 27 2013 - 21:13:05 CET