Re: Ora-19906 when restoring user managed backup - stumped!
Date: Thu, 10 Sep 2009 09:48:17 -0700 (PDT)
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:
> 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?
-- _at_home.com is bogus. If at first you don't succeed, use your superpowers. http://latimesblogs.latimes.com/.a/6a00d8341c630a53ef0120a5582765970b-piReceived on Thu Sep 10 2009 - 11:48:17 CDT