In Support we field a lot of questions about the migration of Oracle Applications to different platforms. This article describes the techniques available for migrating an
Oracle Applications environment to a new platform and discusses some of
the common questions that arise during migration. This subject has been frequently discussed in previous blog articles but there still seems to be a gap regarding the type of questions we are frequently asked in Service Requests.
Some of the questions we see are quite abstract. Customers simply want to get a grip on understanding how they approach a migration. Others want to know if a particular architecture is viable. Other customers ask about mixing different platforms within a single Oracle Applications environment.
Just to clarify, throughout this article, the term 'platform' refers specifically to operating systems and not to the underlying hardware. For a clear definition of 'platform' in the context of Oracle Applications Support then Terri's very timely article:
The migration process is very similar for both 11i and R12 so this article only mentions specific differences where relevant.1. Why Have a Migration Process at All?
have asked why there is a migration process at all. Surely they say it
would be easier just to perform a fresh install of the E-Business Suite
on the target environment and then perform an export/import of the
The above process is reliant on the fresh install
you perform exactly matching the patching levels and technology stack
levels of the environment you are migrating from. The database contains
tables with information regarding files in your APPL_TOP. If you mix a
fresh application tier install with an already established database,
there will be a mismatch between these tables and the objects they
describe. This will cause problems during later patching. The same
issue applies regarding Java objects in the database and the files
contained in the JAVA_TOP. For these reasons, you should never consider
mixing an application tier with an unmatched database tier.
the migration process may appear quite time consuming and linear, much
of it can be done in advance. With careful planning, your production
environment downtime can be limited to little more than the time it
takes to export and import the database and the time taken to apply
several key patches. The majority of the application tier migration can
be done in advance whilst your production environment is still up and
available for updating by users.2. Migrating the Database Tier to a New Platform
you plan to migrate both the application and database tier to a new
platform, the flow of the documentation will follow more logically if
you migrate the database tier before the application tier however
there's no particular reason why you should not migrate the application
Tip: If migrating the database
tier first, make sure the source application tier is updated to connect
to the migrated database tier before migrating the application tier.
This is because the application tier migration process is only updating
the application tier configuration, and assumes the database connection
values are the same as source.
There are several
different ways to migrate the database tier. Using the basic
export/import tool was the only way up until the release of 10g. With
10gR1 came the introduction of the datapump utility which looks similar
to export/import but with useful enhancements and improved performance.
With 10gR2 came the introduction of cross-platform
transportable tablespaces and transportable databases. At time of
writing, transportable database functionality is certified for use with
Oracle Applications for Release 11i
and for Release 12
. Cross-platform transportable tablespace
(XTTS) is still currently part of an Early Adopter Program (EAP).
Version 11g of the database supports both datapump and transportable
Using transportable database as a means
to migrate your database is dependent on both platforms having the same
"endian" format. The following SQL query run on your source database
will tell you if your target platform is compatible.
SQL> select platform_name from v$db_transportable_platform;
database uses the Recovery Manager (RMAN) Convert Database
functionality to migrate the database to the new platform. It's not
supported to use RMAN outside documentation written specifically for
Oracle Applications to perform your database migration.
rule that applies to all the above migration methods is that only
complete database migrations are supported. It is not supported to
perform partial database migrations or complete migrations by using a
"schema by schema" approach.
If using export/import, there are
some parameters that are not used in the default parameter file
supplied such as named pipes and direct=y. This generally means they
are untested in the Oracle Applications environment and, although they
may work, you should generally be wary of using parameters that are not
specifically documented as being Oracle Applications friendly.
migrating from a 32-bit platform/database to-64 bit, then assuming you
install a 64 bit Oracle home on your target environment, the conversion
to a 64 bit database is done automatically. No additional conversion is
required to enable 64 bit functionality. Similarly, if you are
migrating a 64 bit database to a 32 bit platform the downward
conversion is performed implicitly.
You should also remember
that it is generally only possible to migrate Oracle Applications
databases of the same versions. There are only very limited
circumstances where you can upgrade the database as part of the
migration. Version compatibilities are discussed at the start of each
database migration Note.
It's inevitable with Applications
databases that export files are going to be large. Datapump supports
the ESTIMATE_ONLY parameter that can be used at the command line to
estimate the size of the datapump export files that will be generated.3. Migrating the Application Tier to a New Platform
The main notes to follow are:
These notes explain how to migrate the Apps application tier to a new platform. The 11i note can be used to migrate to all
supported Unix and Linux platforms, not just Linux. However, these
Notes cannot be used to migrate the application tier to a Windows
The first section of the Notes covers the prerequisite
requirements of the migration. This migration method requires
AutoConfig and Rapid Clone.
The final step in Section 1
requires you to run Maintain Snapshot in adadmin. This must be run, and
it must run successfully. Snapshot information is stored in the
migration requires you to create a manifest of your application tier
file system based on the Snapshot taken in the preceding step. This
manifest is then uploaded to My Oracle Support and is used to generate
a custom migration patch. The custom migration patch created is
specific to your upgrade only and contains all the files contained in
the APPL_TOP that are binary specific to your new target platform. This
patch is therefore applied in your new environment.
performing the application tier migration, you are required to install
a new application tier technology stack. These are the Developer and
Application Server Oracle homes. This is a good opportunity to install
the latest version. For example, if you are migrating an 11.5.9
environment, you can still install an 22.214.171.124 application tier
The same rule applies with the R12.0 and the
R12.1 technology stack. There is no requirement to upgrade to 12.1 if
you wish to use a 12.0 technology stack. Remember, even if you are
maintaining your existing technology stack versions you will still need
to download and build a new installation staging area for your new
Remember to check all the patches you have
applied to the source technology stack previously as it is conceivable
you have applied patches on your old technology stack that have not
been applied to the newly built technology stack. 4. Partial Migration to a New Platform
no particular reason not to migrate the database or application tier in
isolation to a new platform. It may be, for example, that you are
currently running the E Business Suite on a single node and you're
encountering resource or performance problems. You therefore decide to
migrate Forms and web application tier processing to a new node which
is running on a different platform to your current environment. This is
generally described as a split configuration. You should be able to
just follow the same Notes to perform this migration.
if you only migrate Forms and Web services to the new platform, in your
new environment you will now have to download and apply each E-Business
Suite patch twice (once for each platform) as you will still have
concurrent processing being handled on the database tier.
the above reason, if you're planning to run a split configuration, I
would always tend to advise running all application tier services
(including admin and concurrent processing) on one platform and using
the other platform exclusively as a database tier. This means
E-Business Suite patches only need to be applied once at the new
application tier level.
In the early days of 11i there
was a perceived performance advantage to having the database and
concurrent processing on the same node. This is no longer an
architectural requirement, given the vast improvements in network
bandwidth. You are free to locate your batch processing services on a
different physical server than your database tier.
There is an
additional maintenance overhead of running multiple application tiers
on different platforms, so you should take that incremental cost into
consideration when planning your architecture. In all cases, you should
always locate all nodes in the same data centre and ensure the fastest
available network connection between nodes. This configuration should
also be more scalable allowing easier introduction of additional nodes
at both application and database tier levels.
The above conditions regarding concurrent processing and the database tier apply equally to Apps 11i and 12.5. Sharing the Application Tier
you're contemplating a migration and are using multiple application
tiers then this is often a good opportunity to implement a shared application tier architecture
A shared application tier means storing a single application tier
filesystem on a shared disk accessible to all application tier nodes.
Each application tier node continues to run all or a subset of
application tier services however all application tiers access the same
single disk subsystem. This reduces maintenance as application tier
patches only need to be applied once and therefore may reduce future
upgrade or patching downtime.
If you are running multiple
application tiers in your source environment (on the same platform) and
plan to use a shared application tier on your target environment then
you should merge your application tiers on the source environment
before migrating. This means only having to migrate a single
application tier. The merge process is described in Note 233428.1 for
In R12 all applications tiers have a full application tier
file system installed, even if the application tier is only configured
to run a subset of application tier services. This means there is no
need to merge application tiers in the same way as was required with
A shared application tier can be configured in conjunction with third party software and hardware load balancers
.Top Five Migration Tips
So to conclude, here's a top five list of things to consider when migration Oracle Applications to a new platform:
- Perform as much of the migration as possible outside of the production system downtime
- Consider a shared application tier configuration if you plan to use multiple application tiers
- Place all nodes in your E-Business Suite environment in the same data centre regardless of the location of your users
- If using a split configuration, do not feel compelled to retain concurrent processing on the database tier
transportable database functionality to migrate the database tier if
your source and target platforms have the same endian format