When the big switch doesn't switch

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


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 ( rather than 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.


Post a Comment