Ora-19906 when restoring user managed backup - stumped!
in [Oracle]
|
Prev: Surprising Performance Changes with Oracle 11.2.0.1 (Long Post)
Next: How do I create a new emkey for Enterprise Manager Database Control?
From: joel garry on 10 Sep 2009 12:48 On Sep 9, 9:33 am, gs <g...(a)gs.com> wrote: > joel garry wrote: > > On Sep 8, 7:06 pm, GS <g...(a)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 > > -- > > @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 -- @home.com is bogus. If at first you don't succeed, use your superpowers. http://latimesblogs.latimes.com/.a/6a00d8341c630a53ef0120a5582765970b-pi
From: gs on 10 Sep 2009 13:23 joel garry wrote: > On Sep 9, 9:33 am, gs <g...(a)gs.com> wrote: >> joel garry wrote: >>> On Sep 8, 7:06 pm, GS <g...(a)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 >>> -- >>> @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 > -- > @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)
From: Hemant K Chitale on 10 Sep 2009 22:07 Likely you had, inadvertently, done one recover and resetlogs already and attempted another recover without re-restoring ?
From: GS on 11 Sep 2009 11:04
Hemant K Chitale wrote: > Likely you had, inadvertently, done one recover and resetlogs already > and attempted another recover without re-restoring ? nope - just to be sure that wasn't the case I re-ran the backup on the prod database & switched logfiles, deleted all the data files from the test database etc., basically started from scratch again - same result. |