One of the most ‘untouchables’ of the ‘untouchable’ workloads are AIX and Solaris hosted. These are the traditional ‘Big Iron Unix’ go-to platforms for large enterprise workloads. Each is based on a company specific RISC Chip: Power PC in the case of IBM and Sparc for Sun. AIX and Solaris are the correlated Unix  OSes for each. A good number of high value, high activity on-premise workloads are still running on these RISC based commercial Unix platforms.  These ‘classic’ 64-bit RISC chip-based Unix operating systems are nearly identical to Linux (or rather Linux is nearly functionally identical to them as they pre-date it). But they are of a different word byte order.

More on that in a bit.

These AIX and Solaris OS based systems tend to host large legacy systems that, while long in the tooth, are usually running the  enterprise core business applications and  are mission critical. These are high data gravity  applications  with a large  accompanying group of subsidiary functions that either depend on or are feeding data  to the primary RISC based workload. As legacy systems, they are often several releases older in terms of the current RDBMS versions availabile and that can make it problematic for any kind of simple PaaS migration. But more importantly, they are often so large that they don’t fit in the normal PaaS model and are outside of the shape scope. These “blast from the past” workloads are often ideal candidates for an Azure IaaS deployment.

Power PC and Sparc are “Big-Endian” while Linux and all other x86_64 processor-based OSes are “Little-Endian”. These differences go way back into computer antiquity. (I found an article discussing the “issue” from the PDP 11 / VAX perspective!)

The basic difference is this however:

Little-endian machines read the lowest-byte first, without reading the other bytes. Big-endian systems store data in memory the same way humans think about data (left-to-right), which makes low-level debugging easier.  What this means is that Oracle binaries and data files are not compatible orinteroperable with x86_64 architecture and a conversion must be made to the data to migrate to X86_64 Linux.

How does this effect a migration to Azure? Since these big commercial Unix systems often are home to very large workloads, they’ll typically also be something of legacy too with their RDBMS versions perhaps dragging behind Oracle current releases. All of these circumstances make a lift and shift migration to Azure IaaS infrastructure the least obtrusive, most cost-effective play to get these workloads into the Azure cloud.

But the actual Oracle RDBMS migration will entail some additional steps and techniques. There are several different approaches and techniques to do this. We will briefly list and discuss some of these ways below.

Oracle DataPump:

By far the most straightforward and easiest technique to do an Endian conversion/migration is to export your AIX/Solaris based big-endian based Schemas to a DataPump export file or files. Then simply transfer them to a staging area and invoke DataPump’s impdp utility to import and seamlessly convert the data from big-endian to little-endian format on the Linux RDBMS server.  This has a couple of caveats to it. First and foremost, it will take a considerable amount of time to unload, transfer and then reload the data– so a real near-time migration/switchover isn’t feasible for this technique. But it can be used to good effect for initial POC’s and setting up Dev/Test areas prior to production migration.

Transportable Tablespaces with RMAN

This technique uses the RMAN utility in conjunction with DataPump. This is done on a tablespace-by-tablespace basis and the tablespace must be self-contained. That is, it must have no external references such as a constraint located in another tablespace. First the tablespace metadata is exported by the Oracle DataPump utility expdp:

expdp system/password DUMPFILE=expdat.dmp DIRECTORY=dpump_dir TRANSPORT_TABLESPACES = TBS1,TBS2

The TRANSPORT_TABLESPACES parameter is the key here with a listing of the tablespaces to be transported as its list of arguments. Next RMAN is invoked and each datafile is copied and converted to a scratch file location:

RMAN>convert tablespace TBS1 to platform=”Linux IA (32-bit)” FORMAT ‘/tmp/%U’;

In this example RMAN is being used to convert and copy the Tablespace TBS1 to the /tmp file location. Subsequently they will be copied to the target host, and they are imported with a combination of DataPump and RMAN.

impdp system/password DUMPFILE=expdat.dmp DIRECTORY=dpump_dir TRANSPORT_DATAFILES=’/tmp/….’,’/tmp/…

A full discussion with examples of this process is here in this My Oracle Support note.

Note that both techniques capture a point in time image of the database. In the event of a live production system, a Change Data Capture mechanism must be used to keep the database up to date and synchronized with the source until official cloud cutover. Because of the endian differences, Oracle DataGuard is inapplicable here. Oracle Golden Gate is the Oracle provided solution. This is a schema/object-based replication technique that even supports multi-master replication. However, It is  not trivial to set up. A typical endian migration would consist of an initial data load using either RMAN/DataPump or standalone DataPump coupled with Golden Gate. Here is more on Golden Gates Endian conversion capabilities.

Regardless of what technique your organization will choose, Silk’s superior I/O performance will make the import phase process extremely fast. As these legacy systems are often on very big iron, and support large user counts and heavy batch processing, Silk’s performance characteristics for latency, throughput and IOPS will shine. Expect far better performance on your Silk based cloud installations compared to native Azure alone. Silk is the premium enterprise solution for lift and shift of large mission critical database workloads that require high performance, rich data services and high availability. This is especially so with former commercial Unix workloads that are still mission critical to an organization’s core business.

To learn more about Silk you can check out our unique patented architecture here.