Re: Ora-19906 when restoring user managed backup - stumped!
From: gs <gs_at_gs.com>
Date: Thu, 10 Sep 2009 17:23:10 GMT
Message-ID: <2Caqm.43438$Db2.15108_at_edtnps83>
joel garry wrote:
> On Sep 9, 9:33 am, gs <g..._at_gs.com> wrote:
>
> OK, I just took a gander at my controlfile trace, and I notice both
> methods have commented out incarnation registry lines. Could this be
> something you need? From the docs:
>
> "When a log file is from an unknown incarnation, the REGISTER LOGFILE
> clause causes an incarnation record to be added to the V
> $DATABASE_INCARNATION view. If the newly registered log file belongs
> to an incarnation having a higher RESETLOGS_TIME than the current
> RECOVERY_TARGET_INCARNATION#, the REGISTER LOGFILE clause also causes
> RECOVERY_TARGET_INCARNATION# to be changed to correspond to the newly
> added incarnation record."
>
> So, what's in that incarnation view before you muck with incarnation
> settings?
>
> jg
> --
> _at_home.com is bogus.
> If at first you don't succeed, use your superpowers.
> http://latimesblogs.latimes.com/.a/6a00d8341c630a53ef0120a5582765970b-pi
>
>
On the test/recovered database the view showed two incarnations 1 and 2, so using RMAN I changed it (database) to 2, still got the error, then changed it to 1, and was able to apply redo and open with resetlogs.
Date: Thu, 10 Sep 2009 17:23:10 GMT
Message-ID: <2Caqm.43438$Db2.15108_at_edtnps83>
joel garry wrote:
> On Sep 9, 9:33 am, gs <g..._at_gs.com> wrote:
>> joel garry wrote: >>> On Sep 8, 7:06 pm, GS <g..._at_gs.com> wrote: >>>> ps. database is 10.2.0.4 on windows 64 bit server. >>> Wild guess after looking at metalink Note: 824213.1is that you did a >>> flashback of your prod database at some point, perhaps between when >>> you took the controlfile backup and the online backup? Any clues in >>> the prod alert log? >>> Seehttp://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/flashp... >>> maybe if you specify an until time you can overcome an SCN ambiguity. >>> jg >>> -- >>> _at_home.com is bogus. >>> Cash of the Titans: Amazon, Microsoft and Yahoo versus Google: >>> http://www3.signonsandiego.com/stories/2009/sep/09/sparring-rises-ove... >> Nope, no flashback done, and controlfile script is standard script I use >> using backup controlfile to trace. After digging through the prod alert >> log I am seeing a few of these: >>
>
> OK, I just took a gander at my controlfile trace, and I notice both
> methods have commented out incarnation registry lines. Could this be
> something you need? From the docs:
>
> "When a log file is from an unknown incarnation, the REGISTER LOGFILE
> clause causes an incarnation record to be added to the V
> $DATABASE_INCARNATION view. If the newly registered log file belongs
> to an incarnation having a higher RESETLOGS_TIME than the current
> RECOVERY_TARGET_INCARNATION#, the REGISTER LOGFILE clause also causes
> RECOVERY_TARGET_INCARNATION# to be changed to correspond to the newly
> added incarnation record."
>
> So, what's in that incarnation view before you muck with incarnation
> settings?
>
> jg
> --
> _at_home.com is bogus.
> If at first you don't succeed, use your superpowers.
> http://latimesblogs.latimes.com/.a/6a00d8341c630a53ef0120a5582765970b-pi
>
>
On the test/recovered database the view showed two incarnations 1 and 2, so using RMAN I changed it (database) to 2, still got the error, then changed it to 1, and was able to apply redo and open with resetlogs.
Still puzzled as to why this happened this time, I update this test db every month or so with no issues till now. Have an SR open so I'll see what they say, will post back with answer (if I get one) Received on Thu Sep 10 2009 - 12:23:10 CDT