12c RMAN: convert between endian formats

There is a great new feature related to the 12c database. The feature that will resolve a lot of problems with migrating databases between endian formats. And thanks to our new partner – Omnitec, who agreed to share with their SPARC resources – I will be able to demonstrate you this powerful solution.

Oracle has prepared a perl scripts presented in metalink note 1389592.1 to perform a migration from big endian to little endian (for example from Solaris SPARC to Exadata).

To reduce the amount of downtime required for XTTS, Oracle has enhanced RMAN’s ability to roll forward datafile copies using incremental backups, to work in a cross­platform scenario. By using a series of incremental backups, each smaller than the last, the data at the destination system can be brought almost current with the source system, before any downtime is required. The downtime required for datafile transfer and convert when combining XTTS with Cross Platform Incremental Backup is now proportional to the rate of data block changes in the source system.

In this article I will show you how to combine the full transportable option with incremental backup convertion to perform a nice and quite quick migration from database 11.2.0.4 (Solaris SPARC) to 12.1.0.2 (Solaris x86_64)

I have prepared my own bash scripts to help with this process.
You can download them from here:
http://www.ora-600.pl/oinstall/migrate.tar.bz2

At first, I will set appropriate parameters in my properties file on the source (11.2.0.4 SPARC):

Now, let’s create level 0 backup of all non system tablespaces (11.2.0.4 SPARC):

My script has created two files:

• initial_backup.rman
• initial_restore.rman

First one is used to create actual level 0 backupsets for the datafiles.
The second one will be used to restore all datafiles and convert them between endians.

So now let’s copy backupsets and scripts to the target platform (12.1.0.2 x86_64)

Now I can perform an initial restore, using provided scripts:

Meanwhile I will do some changes in the source database (11.2.0.4 SPARC):

And now I will create some incremental backups on the source database (11.2.0.4 SPARC)

Please notice that the above script has created files, which will be executed in the proper order by do_recover.sh

Now I will copy the incremental backups and appropriate scripts. After that I will perform a recovery with endian convertion on the target platform (12.1.0.2 x86_64)

We are almost done 🙂 Now we have to make tablespaces in READ ONLY mode on the source database (11.2.0.4 SPARC) and create final incremental backups, transfer them to destination platform (12.1.0.2 x86_64) and perform recover.

MAINTENANCE WINDOW STARTS

SOURCE (11.2.0.4 SPARC):

TARGET (12.1.0.2 x86_64)

The error messages are caused by the recovery of the data files, using backups which are already applied to those data files. You can safely ignore this error message.

Now I will use the full transportable export/import to finalize the migration. The whole feature is described here:
http://www.oracle.com/technetwork/database/enterprise-edition/full-transportable-wp-12c-1973971.pdf

So nothing left to do, but importing our metadata on the target system (12.1.0.2 x86_64)

You will see a lot of errors while importing but most of them are: "Dependent object type %s skipped, base object type %s already exists" – they can be safely ignored.

Other errors may concern for example an old apex schema like "APEX_030200″. This user can be dropped after the import.

The import messages, that will need your attention and some manual steps, looks like this:

The above error can cause dependent problems:

Those errors have to be resolved manually.

After the import you will see some compilation problems in the SYSMAN schema. Since this user is no longer present in standard 12c installation, you can safely remove it.

MAINTENANCE WINDOW ENDS