Sometimes companies switch infrastructure hardware, which can create challenges for IT teams. There can be solid reasons for moving from one brand of hardware to another, including cost, architecture and the cost of hardware-based software licensing; however, if the processor brand is changing, then you may have just strayed into a platform migration. This article discusses the challenges of performing a platform migration with Oracle E-Business Suite (EBS).

Scope of Oracle EBS Platform Migrations

Performing all of the E-Business Suite maintenance tasks, such as patching, running AutoConfig, Rapid Clone, etc., is beyond the scope of this article; we’re just discussing the high-level infrastructure issues.

What Is a Platform Migration in Oracle EBS?

First, let’s discuss endianness. Endianness refers to the order in which bytes are arranged in memory. Some platforms, such as those running AIX, HP-UX and Solaris, are big-endian, while x86/x86_64 systems are little-endian. The two endian formats are incompatible. A platform migration is the work involved in migrating your database and applications from one endian format to the other.

Oracle Database Migration Considerations

Can I clone the Oracle Database software to a new platform and run it?

Unfortunately, no. Different processors (CPUs) have different instruction sets. You cannot transfer an executable binary from one platform to another and expect it to work. You’ll need to install the Oracle Database software on the new platform from scratch, then patch it to at least the same levels as the source system.

Can’t I just copy my datafiles to the new platform, or restore from a backup?

No. Moving an Oracle Database between platforms with a different endianness cannot be accomplished by simply copying the datafiles, due to the endian format difference. Likewise, you cannot use other Oracle Database data migration methods such as Transportable Tablespaces, as those rely on the underlying datafiles. You also cannot use Oracle Data Guard (DG), since the redo logs that DG relies on are also in an incompatible endian format. What does that leave?

I’ll get to that, but before any data movement can be done, it is necessary to create a new, empty database on the target platform. This is not the only prerequisite with an EBS database, however; an EBS database has many datatypes that are not present in an out-of-the-box Oracle Database. Did you know that when you do an installation of Oracle EBS from scratch, the installation process will instantiate a clone of Oracle’s generic “lab” EBS database? To prepare a new, “vanilla” Oracle Database to host EBS data, there is a series of scripts that must be run to make the data dictionary look like an EBS database; the scripts are provided in an Oracle EBS patch.

Now that the new database has been prepared, it’s time to start migrating the data.

Oracle EBS Data Migration Methods

There are a few options for moving the data between platforms. First, you could use traditional export/import (Data Pump). A full discussion of Data Pump is out of scope here, but the key point is that this is a process that will export the data blocks from the source database in a platform-neutral file that can be transferred over to the target platform. Ater that, you can import the data into the new database, with the data stored in the new endian format. This is a tried-and-true method, but, for large databases, it is very slow, as you first have to export the entire source database, transfer the dump (export) files across the network, then import the data; this all happens in a serialized fashion. Experienced Oracle DBAs may point to the NETWORK_LINK feature of Data Pump, that can transfer data directly between two databases; unfortunately, EBS contains data types that are not supported by the NETWORK_LINK feature, so that optimization is not available.

Cross-Platform Transportable Tablespaces (XTTS)

I mentioned earlier that Transportable Tablespaces is not an option due to the differences in endianness, and that’s true. However, Oracle introduced Cross Platform Transportable Tablespaces (XTTS) to address that. The high-level steps for XTTS look like this:

1. 1. Ensure that all of the tablespaces to be moved are self-contained.
      When you use XTTS, you define a group of tablespaces that are going to be moved. This group is generally all of your tablespaces that contain data (i.e. no UNDO or TEMP), excluding SYSTEM and SYSAUX; those tablespaces never get migrated. For XTTS to be successful, there cannot be any references to objects outside of the group of tablespaces that you are moving. This can be problematic if custom objects have been stored in the SYSTEM or SYSAUX tablespaces; you’ll need to re-factor before proceeding.
      
   2. Put the tablespaces in the source database into READ ONLY mode.
      At this point, no updates can be made to the source system, meaning that this is likely the beginning of an outage.
   3. Copy all the underlying datafiles to the target system.
   4. Convert the datafiles to the new endian format.
   5. Create an export of the metadata from the source database using Data Pump.
   6. Import the metadata into the target database using Data Pump.
   7. Switch the tablespaces in the target database to READ WRITE.

For large databases, this can be a much faster migration method over export/import, but there can still be a significant amount of downtime, based on the size of your database.

Cross-Platform Migration with Incremental Backups

This method essentially combines the XTTS method with RMAN incremental backups. This is a more complex process, but it offers the virtue of leaving your source database available (i.e. READ WRITE) for the bulk of the process. In other words, you can start migrating your data ahead of your actual migration. The high level steps for this method look like this:

Preparation

1. Transfer the datafiles to the target system
2. Convert the datafiles to the new endian format

Maintenance

3. Create incremental backup on the source system
4. Transfer incremental backup to the target system
5. Convert the incremental backup to the new endian format

This phase should be performed as many times as necessary until it’s time to cut-over to the new platform.

Finalization

6. Put the tablespaces in the source database into READ ONLY mode
7. Repeat the Maintenance steps 1 final time, to capture any remaining changes to the source database
8. Create an export of the metadata from the source database using Data Pump.
9. Import the metadata into the target database using Data Pump.
10. Switch the tablespaces in the target database to READ WRITE.

As you can see, the database doesn’t become unavailable until the Finalization phase.

Key Takeaways for Oracle Database Migrations

There are several methods for migrating your EBS data to a new platform. What I hope I’ve conveyed is an understanding that you can’t just copy your datafiles between platforms.

Oracle EBS Application Tier Migration Steps

Copying the application directory trees to the new platform will work, right?

Again, no. As already discussed, you’ll need to install executable binaries appropriate to the new platform. If you’ve created any custom Oracle Forms or Oracle Reports, those files can be transferred as-is, but you’ll need to do a fresh installation of the EBS application tier on the new platform.

Over the years, we’ve applied plenty of patches to our EBS system. How do we make sure those won’t be lost?

Oracle provides a robust method for EBS platform migrations. Here’s what a migration looks like at a high level:

Preparation

• Apply prerequisite patches (if any)
• Run AutoConfig on the source system
• Run adpreclone on the source system
• Run adadmin on the source system and run “Maintain Snapshot Information”
• Identify any patches that have been applied to the technology stack

Migration

• Generate a manifest file of all EBS patches applied to your system
• Upload the manifest to Oracle’s Platform Migration portal
• Oracle’s portal will generate a customer-specific patch file containing the functional equivalent of all patches that have been applied to your source system; this will generally take 1-2 hours.
• Copy the APPL_TOP and specific COMMON_TOP directories to the new platform
• Clone the apps-tier Context File on the new platform
• Using the EBS installation media for the new platform, install the Application Tier Technology Stack
• Run AutoConfig on the new platform
• Download and apply the customer-specific patch from Oracle’s portal.
• Apply any technology stack patches that you identified in the Preparation section
• Run adadmin to regenerate messages, forms, reports and jar files
• Run AutoConfig on the new platform

Application Tier Summary

Migrating the apps-tier to a new platform has a straight-forward procedure, but you can expect to run into hurdles along the way. It’s important to develop a migration plan in one of your non-production environments first, because, in my experience, you are going to run into issues that require you to open Service Requests that lead to the application of additional patches.

Oracle Support Requirements for Platform Migrations

Do we have to have active Oracle Support to do a platform migration?

The simplest answer is “yes”. Here are some of the things that I’ve covered in this article:

• Oracle EBS installation media for the new platform
• EBS prerequisite patches
• Customer-specific EBS patch (generated by Oracle’s Platform Migration Portal)
• EBS technology stack patches
• Oracle Service Requests (and any remedial patches)

These items generally all require Oracle Support. It is inadvisable to run Oracle EBS without any support at all. Third-party support vendors usually do a good job of instructing customers to do a thorough job of downloading patches from Oracle Support before their entitlement to those patches ends, but, unless the customer was already anticipating a future platform migration, customers would only download patches for their current platform. Also, Oracle Support entitlement is required for the customer-specific patch that is required to bring the new platform up to the required levels.

Trying to perform an EBS platform migration without Oracle Support is not recommended.

Final Thoughts on Migrating Oracle E-Business Suite

Hopefully now you understand the challenges involved with moving Oracle E-Business Suite to a new platform; it isn’t as simple as replicating files. The size of the database, which EBS modules you are using, as well as the availability of Production outage windows all contribute to determining the complexity of the migration. This type of migration deserves all of the consideration of a major project (don’t forget acceptance testing!), and should be given a timeline that includes multiple iterations in order to fine-tune your procedures.

House of Brick has performed several of these migrations. Reach out to us and let us help.