Re: standby reinstate failed: other options
- From: Laimutis.Nedzinskas@xxxxxx
- To: Marcin Przepiorowski <pioro1@xxxxxxxxx>
- Date: Fri, 26 Aug 2011 10:10:30 +0300
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@xxxxxxxxx>
To: Laimutis.Nedzinskas@xxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Date: 2011.08.25 22:38
Subject: Re: standby reinstate failed: other options
On Thu, Aug 25, 2011 at 2:30 PM, <Laimutis.Nedzinskas@xxxxxx> 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
