RISC to x86 EBS migration with near zero downtime

I have reread the article referenced above, and conclude that it appears very likely that the approach would work, regardless of the target platform, particularly if the database software version is 10g. Remember that almost everyone who is still on Solaris / SPARC legacy hardware is still running 10g. They will upgrade on the target platform (i.e. x86), not on the legacy platform.

There is no way that Oracle has inserted a patch into 10g to prevent the customer from performing an RMAN incremental backup / restore unless you are on an ExaData. That is simply not possible. Thus, the only enforcement would appear to me to be the note in the article itself, which I regard as meaningless.

My one issue is how to convert an RMAN backup across endianness. The article states in part, as follows:

1. Roll Forward phase (source data remains online - Repeat this phase as many times as necessary to catch destination datafile copies up to source database)
   1. Create incremental backup on source system
   2. Transfer incremental backup to destination system
   3. Convert incremental backup to destination system endian format and apply the backup to the destination datafile copies

Bold added by me. Obviously, there is a way to convert incremental RMAN backups from big endian to little endian and vice versa. There are a set of scripts attached to the article, and I have read these scripts, but they are very strange. Here is the relevant function within the perl script:

sub rmconvertedincr()

{

   my $backupondest  = $props{'backupondest'};

   my $asmhome       = $props{'asm_home'};

   my $asmsid        = $props{'asm_sid'};

   if (defined $props{'asm_home'})

   {

      ## Lets first delete the incremental backup if any

      ## this will happen through asmcmd

      $oh_saved = $ENV{'ORACLE_HOME'};

      $ohsid_saved = $ENV{'ORACLE_SID'};

      $ENV{'ORACLE_HOME'} = $asmhome;

      $ENV{'ORACLE_SID'} = $asmsid;

      # Remove trailing spaces

      $backupondest =~ s/\s+$//;

      $asmsid =~ s/\s+$//;

      $asmcmd_str = "asmcmd rm $backupondest/xtts_incr_backup";

      print $asmcmd_str . "  $asmhome .. $asmsid \n" ;

      $asmcmd = `asmcmd rm $backupondest/xtts_incr_backup`;

      print "ASMCMD:  $asmcmd\n";

      $ENV{'ORACLE_HOME'} = $oh_saved;

      $ENV{'ORACLE_SID'} = $ohsid_saved;

   }

   else

   {

      $rmcmd = `\\rm -f $backupondest/xtts_incr_backup`;

   }

}

Does anyone have an idea how this works? The endianess conversion of the RMAN incremental backup set is the key to the entire process. Please let me know your thoughts.

I have pushed a bit farther into the scripts, and discovered the area where the endianness conversion of RMAN backups is happening. It is in the SQL script xttrollforwarddest.sql. The relevant portion is:

  BEGIN

      sys.dbms_backup_restore.restoreCancel(TRUE);

      devtype := sys.dbms_backup_restore.deviceAllocate;

      sys.dbms_backup_restore.backupBackupPiece(

        bpname => '&&1',

        fname => '&&2/xtts_incr_backup',

        handle => handle, media => media, comment => comment,

        concur => concur, recid => recid, stamp => stamp, check_logical => FALSE,

        copyno => 1, deffmt => 0, copy_recid => 0, copy_stamp => 0,

        npieces => 1, dest => 0,

        pltfrmfr => &&3);

   EXCEPTION

      WHEN OTHERS

      THEN

        DBMS_OUTPUT.put_line ('ERROR IN CONVERSION ' || SQLERRM);

   END ;

Thus, this script is calling a PL/SQL package called sys.dbms_backup_restore. I have been trying to find the documentation on that package. It apparently has the ability to do endianness conversion of RMAN backups. Note the line in the call to this function:

Thus, a platform can be specified for this command.

Don Burleson has a bit on this package on his website. He says that the package has very little documentation. No kidding.

I suspect that this is how Oracle is transitioning folks off of legacy Sun Solaris / SPARC and onto ExaData, which is, after all, merely x86-64 / Linux.