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.
First  |  Prev  | 
Pages: 1 2
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?