Some time ago i wrote a few blog posts about how to very simply switch databases in (and out) of ASM. This worked like a dream when i tried it in 12c
http://dbaharrison.blogspot.de/2014/03/switching-into-asm.html
http://dbaharrison.blogspot.de/2014/10/switching-bigish-to-asm.html
http://dbaharrison.blogspot.de/2014/03/faster-switching-into-asm.html
This week we've been switching a load of 11.2 databases into ASM and have hit 2 snags.
I'll start with the easier of the two....
In one of my posts i previously demonstrated how it was possible to apply an incremental backup to an existing on disk backup in ASM. This could then roll forward that copy and make for a shorter downtime to actually migrate.
This doesn't work in 11g - well at least not without a minor syntax change to the base copy backup.
in 12c this works
backup as copy database format '+DATA' tag 'demo';
in 11g you have to make a subtle adjustment to this
backup as copy incremental level 0 database format '+DATA' tag 'demo';
So it seems that in 11g the database is a full backup and not an incremental level 0 backup, though they are essentially the same, there is a difference. in 12c either the default has been changed or the two really have become exactly synonymous.
So that had me scratching my head for a while.
However not as long as this next one did
In this case we did a full backup to asm went to switch as normal and then got this
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of switch to copy command at 12/23/2015 10:53:41
RMAN-06571: datafile 1 does not have recoverable copy
Initially we thought we'd made a mistake somewhere and retried a few times but to no avail - something was wrong here and it wasn't at all obvious what.
The only difference we could find to other environments was that compatible was set too low (11.2.0.3 rather than 11.2.0.4) so we changed that and tried again but that didn't help either.
At this point we were reduced to guesswork.....
I had noticed that there were 2 incarnations for this database in the controlfile (one of them orphaned) - this shouldn't have mattered i didn't think but it was different to the other databases that had worked.
I therefore decided to backup controlfile to trace and recreate nice clean fresh controlfiles.
And guess what - it fixed it. Next run through ran as expected!
Not sure if this is a bug or controlfile corruption or what but anyway i thought i'd share as it may be useful for someone else.
Comments
Post a Comment