Re: standby reinstate failed: other options

From: <Laimutis.Nedzinskas_at_seb.lt>
Date: Fri, 26 Aug 2011 10:10:30 +0300
Message-ID: <OFF548D1AD.CBAC3F98-ONC22578F8.0026D1AB-C22578F8.00276A12_at_seb.lt>



Thanks.

>Try to copy all logs from current primary...

I have already done ... but only for the rest data guard databases to reinstate.
The moment reinstate starts it clears all relevent redo logs. The old rule still holds - make a copy of redo before starting to exercise with a database. Wondering how that is doable in ASM ?

Brgds, Laimis N


Please consider the environment before printing this e-mail

                                                                                                                                                   
  From:       Marcin Przepiorowski <pioro1_at_gmail.com>                                                                                              
                                                                                                                                                   
  To:         Laimutis.Nedzinskas_at_seb.lt                                                                                                           
                                                                                                                                                   
  Cc:         oracle-l_at_freelists.org                                                                                                               
                                                                                                                                                   
  Date:       2011.08.25 22:38                                                                                                                     
                                                                                                                                                   
  Subject:    Re: standby reinstate failed: other options                                                                                          
                                                                                                                                                   





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 Fri Aug 26 2011 - 02:10:30 CDT

Original text of this message