Friday Jul 27, 2012

Five Errors Customers Make When Migrating E-Business Suite 12 (Part 4)

This is the fourth in a series of articles about common technical myths or misunderstandings about the E-Business Suite. Other articles have covered installations, cloning, patching, upgrades, and maintenance. This article discusses migrations.

Each article is absolutely not definitive and I’d be interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.

COMMON ERROR #1: Exporting from a 9i database and importing into a fresh 10g/11g database.

ORACLE’S RECOMMENDATION: When working with 10g onwards you must use datapump. Refer to the opening section of the relevant import/export Note to establish database version compatibility for exports/imports (including datapump). When importing into a 10g or 11g database the source database must be 10g or later.

COMMON ERROR #2: Assuming that Linux x86_64 is a certified application tier platform for 11i.

ORACLE’S RECOMMENDATION: Linux x86_64 is only certified for the 11i database tier of the E-Business Suite. Linux x86_64 can be used as both an application and database tier platform with Release 12 onwards. There are no plans to certify Linux x86_64 as a platform for the 11i application tier. Linux x86_64 using any form of 32 bit emulation is also not a certified 11i application tier platform.

COMMON ERROR #3: Migrating the E-Business Suite environment to a new platform by performing a fresh install of the E-Business Suite using Rapidwiz on the new platform and then performing an export/import of the database.

ORACLE’S RECOMMENDATION: You must use the migration tools documented in the link below to migrate the application tier to the new platform. Only use Rapidwiz to create the new application tier technology stack.

COMMON ERROR #4: Migrating EBS 11i application tier servers to Exalogic servers.

ORACLE’S RECOMMENDATION: The Exadata platform is certified for use as a database tier for both 11i and R12. Both 11i and R12 require Oracle Database 11gR2. The Exalogic platform can be used as an application tier for R12 but not for 11i.

COMMON ERROR #5: Installing or upgrading your E-Business Suite technology stack components requires downloading the entire R12 installation media.

ORACLE’S RECOMMENDATION: It is possible to build a staging area that only contains the components you require. Refer to the E-Business Suite Installation Guide for instructions on how to build a partial staging area that contains only the technology stack or E-Business Suite components that you require.


Related Articles

Tuesday Feb 07, 2012

Best Practices for Combining EBS Upgrades with Platform Migrations

Odds are that you're planning an EBS upgrade soon.  EBS 11i Extended Support runs out in 2013, and EBS 12.0 Premier Support ended in January 2012. You might need to combine your EBS upgrade with a operating system upgrade or hardware migration for your servers, too.

Projects that combine EBS upgrades with migrations pose some interesting questions.  What tools do you use if you're...:

  • ... upgrading to a newer version of your current operating system?
  • ... migrating to a different platform with the same endian format?
  • ... migrating to a different platform with a different endian format?

Diagram showing small endian and big endian platforms

Evaluating the different options

I have published a new whitepaper that provides a comprehensive evaluation of the different mechanisms available in upgrading the Oracle E-Business Suite while considering platform migration. This document is meant as an overview to supplement existing detailed documentation that outlines specific processes to perform the migration:

This whitepaper discusses the use of Transportable Database, Recovery Manager (rman), Export/Import using Datapump, Transportable Tablespaces (TTS), Rapid Install, and Release Update Packs.

Application server vs. database server upgrades

Platform migrations may considered separately for the application and database tiers, or for both tiers together. In either case, it is critical to understand that the migrations are separate processes that can be thought of logically as such. This is especially crucial in light of potentially reducing downtimes by breaking them out into separate discrete events which may have different considerations for users and administrators.

Upgrade your database server before upgrading EBS

We recommend that you migrate your database to a new version and new server platform first.  This allows you to perform this in a separate earlier downtime.

For example, you might wish to migrate your EBS database tier running 11gR2 to Oracle Linux 5 on newer and faster hardware prior to an R12 upgrade. Performing this migration first would leave the your environment in a certified configuration that you can continue using until you wish to perform your EBS R12 upgrade.

Regardless of whether this migration is done in a separate earlier downtime or as part of a single downtime, the newer hardware would allow the EBS upgrade to go faster.

Best practices for combined upgrades

Here are our recommendations when performing EBS upgrades and platform migrations in a single project:

  1. Consider the database and application tier migrations separately and plan to perform the database migration first.

  2. Choose the right migration process for the database while considering the target platform, database size and process complexity.

  3. Migrate and upgrade your EBS application tier from 11i to R12 by laying down the new application tier on the target platform as part of the upgrade.

For more details, see:

Related Articles



« March 2017