Highlighted
8 Krypton

## RISC to x86 EBS migration with near zero downtime

This discussion is very closely related to a previous discussion, but we need to punch this up a bit, and add EBS to the mix.

I have a customer (no customer names here, but definitely a household name) who is migrating their EBS instance off of SPARC / Sun onto x86 / Linux. This customer cannot withstand signicant downtime.

I see from our EMC IT story that our EBS migration involved downtime. Basically, we migrated several 10s of TBs in a weekend. Great. But not good enough for many, many customers.

Annoyingly, Oracle has created a feature of their software which explicitly allows this operation, but only if ExaData is the target. (!!!!!!)

For those with My Oracle Support access this article can be found here:

Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backups [ID 1389592.1]

Due to the nature of MOS (uses Flash technology) a URL to this article is difficult to create. But searching by the ID works. If you peruse the article, you will notice the limitation to the ExaData platform.

While it would be tempting to become aggressive towards Oracle for this maneuver, I will avoid that in the context of this discussion. What I am looking for instead is a solution which would allow the customer to do the following:

• Leave the production database up and running on the RISC platform
• Use EMC storage-based replication to make a copy of the running production database
• Use RMAN convert to move the database copy to the target platform
• Use some tool (and this is the crux of the issue) to cause the target database to catch up to the source database

After that, a brief downtime could be withstood to shutdown the old production database, apply the last few transactions, and then come up on the target database.

Approaches that have been discussed but somewhat rejected (due to the use of objects by EBS) include:

• Goldengate
• DB with SQL / logical apply

I am not completely rejecting these approaches, bear in mind. I am simply saying they have been discussed and objections have been raised.

Any other ideas would be welcome.

2 Replies
8 Krypton

## Re: 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.

8 Krypton

## Re: RISC to x86 EBS migration with near zero downtime

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:

pltfrmfr => &&3);

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.

Dell Support Resources