Ora-19906 when restoring user managed backup - stumped!
gs
backup (not rman), the procedure is simple:
shut test database down
copy files from last online backup on prod to test db locations, along
with any archived logs since backup
startup mount the test db, rebuild the controlfile renaming database and
new file locations etc.
recover database until cancel using backup controlfile, then apply redo
etc. cancel and open database with resetlogs, create a tempfile and I'm
good to go
Usually goes without a hitch, but for some reason after I hit enter to
have it apply the archived log it is looking for, I am getting:
===================================================================
ORA-00283: recovery session canceled due to errors
ORA-19906: recovery target incarnation changed during recovery
ORA-01112: media recovery not started
===================================================================
Looking up the 19906 error says its an rman incantation setting, but I
am not using rman at all for this, and I'm stumped why this is happening
now.
I even re-ran the online backup and recopied the files over, with no
success.
Any ideas what I'm missing here?
thanks
GS
joel garry
> 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?
See http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/flashptr005.htm#sthref646
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-over-googles-book-deal/?uniontrib
gs
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:
Wed Sep 09 10:07:31 2009
Thread 1 cannot allocate new log, sequence 3255
Private strand flush not complete
Current log# 5 seq# 3254 mem# 0: E:\ORACLE\ORADATA\MYDB\MYDB\REDO5.LOG
Current log# 5 seq# 3254 mem# 1: D:\ORACLE\ORADATA\MYDB\REDO5A.LOG
Wed Sep 09 10:07:32 2009
Thread 1 advanced to log sequence 3255 (LGWR switch)
Current log# 6 seq# 3255 mem# 0: E:\ORACLE\ORADATA\MYDB\MYDB\REDO6.LOG
Current log# 6 seq# 3255 mem# 1: D:\ORACLE\ORADATA\MYDB\REDO6A.LOG
so I am wondering if this is somehow related.. looking at ways now to
cure this particular error, it happens when I do a manual logfile switch
as well.
gs
update, according to metalink note:372557.1 this is normal expected
behavior so..
Hemant K Chitale
Check if you rebuilt the controlfile properly and that the newly
created controlfile IS in use for the Recovery, not an older
controlfile.
Hemant K Chitale
http://hemantoracledba.blogspot.com
gs
checked all that, all was ok, done this process many times, just this
time I was getting error. Finally was able to apply redo and open
database with resetlogs, but only after I set the database incarnation
to 1 with and RMAN command. Not sure why this was necessary this
particular time though. Opened an SR and uploaded alert logs etc.. from
prod and test db's, will see if they come up with any useful info..
joel garry
> joel garry wrote:
> > On Sep 8, 7:06 pm, GS <g...@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?
>
> > 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:
>
> 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
gs
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)
Hemant K Chitale
and attempted another recover without re-restoring ?
GS
> Likely you had, inadvertently, done one recover and resetlogs already
> and attempted another recover without re-restoring ?
prod database & switched logfiles, deleted all the data files from the
test database etc., basically started from scratch again - same result.
gs
Oracles answer was when I try and recreate the controlfile with
resetlogs (or open database with resetlogs) a new incarnation is
created, and ends up being an orphan incarnation. Read more about it in
doc id 577820.1
Setting db incarnation to 1 fixed the problem for me, but the note says
to recreate the controlfile to get around this error, which I did and
that alone did not work. In any case I am up and running now, still
puzzled as to why this never happened before though...
Ravi
>
> - Show quoted text -
Did you happen to upgrade this database to 10g recently? Or has this
been at 10g for quite some time? I am just wondering if this is a 10g
behavior.
gs
This was a database created as 10G, then data was imported from 9i, I
never use the upgrade process, only exp/imp. Seems to be a 10G
behaviour, I have never had this issue with 9i databases.