Re: standby reinstate failed: other options

From: Marcin Przepiorowski <pioro1_at_gmail.com>
Date: Thu, 25 Aug 2011 20:38:23 +0100
Message-ID: <CAGdek=w1ahFQWzspgD=jLD53RjyDddoyHhmHyboBjNvyAXhAVA_at_mail.gmail.com>

On Thu, Aug 25, 2011 at 2:30 PM, <Laimutis.Nedzinskas_at_seb.lt> wrote:
>
>
> In short, reinstate flashbacked the former primary (wanna be standby) and
> started managed recovery.
> The managed recovery requested a redo sequence which was in the online redo
> logs and was never archived. The funny part was that as part of becomming a
> new standby the database cleared the online redo logs...
> The managed recovery has stuck like that waiting for gap:
>
> ORA-19906: recovery target incarnation changed during recovery
> ...
> Media Recovery Waiting for thread 1 sequence 9652 branch(resetlogs_id)
> 742441725
> Fetching gap sequence in thread 1 branch(resetlogs_id) 742441725, gap seq
> 9652-9652

HI,

There is a bug related to this behaviour. Try to copy all logs from current primary - especially this 9652
and all with highr scn and create a new fresh standby control file on primary. Copy it to standby and mount it. Try manual recover using

recover standby database;

If it help you are done.

> The question now is:
>
> is it possible to reinstate the former primary using incremental backups?
>
> Now if I do an incremental backup of new primary - what's use it will have
> on a flashbacked former primary ?
>
> - the former primary was flashbacked to the scn when standby_became_primary
> as it should. In other words - the former primary got a new incarnation.

If you need to do incremental backup it should work as well - I did it and it was working.
It is worth to check if all datafiles has header scn later than standby_became_primary SCN
If not take a lowest SCN from datafile header.

Hope it help,

-- 
Marcin Przepiorowski
http://oracleprof.blogspot.com
--
http://www.freelists.org/webpage/oracle-l

Received on Thu Aug 25 2011 - 14:38:23 CDT