A Primer on Migrating Oracle Applications to a New Platform

maapaper.png
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?

Some customers 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 database.

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.

Although 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

If 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 tier first.
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 12Cross-platform transportable tablespace (XTTS) is still currently part of an Early Adopter Program (EAP). Version 11g of the database supports both datapump and transportable database migrations.

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;
Transportable 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.

One 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.

If 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 platform.

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 following tables:
  • AD_SNAPSHOTS
  • AD_SNAPSHOT_FILES
  • AD_SNAPSHOT_BUGFIXES
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.

When 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 11.5.10.2 application tier technology stack.

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 target platform.

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

There's 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.
Tip:  Remember, 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.
For 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

If 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 11i.

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 11i.   

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
  • Use transportable database functionality to migrate the database tier if your source and target platforms have the same endian format
References

Related Articles


Comments:

Pray for me. I'm in the middle of a Solaris->Linux migration for the DB Tier on R12.1. Datapump is the buggiest tool in the world, especially on 11.1.0.7. I long for the days of using a method with exp/imp, but Support says "Not Supported".

Posted by Jeff Hunter on March 12, 2010 at 04:12 AM PST #

Hi Jeff

Prayers have been offered.

You comment led me to you reading your blog where I see you're migrating from 10gR2 to 11.1. Do you think combining the upgrade and migration is contributing to the problems you're seeing?

It sounds like your issues are with the datapump tool itself and not with the Applications migration process. I'd be interested to see the outcome of any Service Requests you raise - we may be able to use what is learned to improve the Applications side of the documentation.

Regards

Nick

Posted by Nick Quarmby on March 14, 2010 at 06:46 PM PDT #

Hi Nick,

We have recently migrated our apps tier to AIX from HP-UX : our previous configuration was a homogenous DB and Apps tier all on HP-UX. Our main goal is to split configure our E-Bus Suite 11.5.10.2 with DB on the mainframe to run zlinux on Z/OS and AIX for the apps tier.

We've divided our approach into two phases -- migrating the apps tier first and then migrate the DB tier after that. We've successfully migrated to AIX, however we discovered block corruption in one of the system datafiles. We did a DB Verify to investigate this finding. Fortunately the object with the corruption is an index and can be dropped and recreated. We hope to clear this block corruption when we migrate to the mainframe in phase 2. In the meantime, is there a way for that block corruption to be cleared other than dbms_repair?

My guess is that the application of the TXK Autoconfig Rollup Patch T caused the occurrence of the block corruption because that and the latest Rapid Clone patch were the only changes we performed as part of the tasks to be done for the migration.

Thanks for bearing with this long comment.

cheers,
Vernnie

Posted by Vernnie Creencia on March 29, 2010 at 04:54 PM PDT #

Hi Vernnie

Please accept my apologies for the delay in responding, I was away last week.

Block corruption requiring dbms_repair does not sound like the kind of thing that typically happens when applying an Apps patch. I worry there is something more serious going on if you're seeing this sort of problem. Does the TXK patch apply successfully with no errors? Is there definitely no block corruption prior to applying the patch? Can you consistently see this block corruption following application of the patch?

If you see this error occurring every time you apply the patch then I think there is probably something wrong before the patch is applied and the problem is not actually within the patch itself.

Regards

Nick

Posted by Nick Quarmby on April 06, 2010 at 04:31 PM PDT #

Hi,

We are currently on AIX for our Database and Application tiers and we are planning an upgrade from 11.5.10.2 to R12 as well as a platform migration for the Application tiers to move to Linux. Does this require us to first upgrade to R12 on AIX and then migrate to Linux or can the upgrade/migration be done directly to Linux skipping the additional step of the R12 upgrade on AIX?

Thanks,
Laura

Posted by Laura on May 21, 2010 at 05:07 AM PDT #

Hi Laura

I assume you're on 10gR2 or 11g of the database. If so, I'd suggest you migrate your 11.5.10.2 database to Linux by following Note 362205.1 (or similar). You will then have your 11.5.10.2 environment split between AIX and Linux. You can then perform your R12 pre upgrade steps on the split environment before laying down the R12 code using Rapidwiz on the Linux environment. You then complete the R12 upgrade on the Linux platform.

Regards

Nick

Posted by Nick Quarmby on May 23, 2010 at 04:07 PM PDT #

Hi Nick,

Thank you for your response. We are currently on 10.2.0.4 for the database but will be moving to 11gR2 before the R12 upgrade. We are only moving the Application tiers to Linux and will keep the database on AIX. Is it possible to run the R12 pre upgrade steps on the AIX environment, lay down the R12 code on the new Linux Application tier servers with Rapidwiz, and then complete the R12 upgrade on the split environment?

Thanks,
Laura

Posted by Laura on May 23, 2010 at 09:55 PM PDT #

Hi Laura

Sorry, I misread your earlier comment. Yes, your upgrade strategy looks sound. Upgrade your 11.5.10.2 to use 11gR2 (check 11.5.10.2/11gR2 is certified on your version of AIX) using Note 881505.1. Then run the R12 pre-upgrade steps on AIX. Lay down te R12 code on your new Linux server(s) and complete the upgrade on the split environment. You might find Note 761570.1 helpful as well.

Regards

Nick

Posted by Nick Quarmby on May 23, 2010 at 11:12 PM PDT #

Hi everyone,

I'm evaluating how do we migration to 12.1.2. from 11.5.5. Now, we have a 8.1.7.4 database and RedHat 2.1 and our objective is 11gR2 and Red Hat 2.5 incluyed new machines...

So, I'm thinking if we should do a upgrade or re-implementation. We have very customizations and the functional change is very big from our release.

So, please, I would like to Know what criteria should I take for deciding wht option I must take.

Can you help me???

Best Regards,
Ricardo Martinez (Madrid - Spain)

Posted by Ricardo on May 31, 2010 at 11:11 PM PDT #

Hello Steven

"If using a split configuration, do not feel compelled to retain concurrent processing on the database tier"

What are the advantages and disadvantages of putting your conc mgrs on the mid-tier (application tier).

As far as I am aware the advantage is that you wouldn't have any apps software on the db tier to patch, so keeps patching to a minimum.

What happens to a running conc job if the network connection times out or is cut between mid-tier and db server, would the job continue regardless ?

All the work is carried out on the db tier anyway isn't it ? So, other than the 1 advantage (ie. patching), are there any others you can think of ?

thanks for any advice.

Regards

Dave

Posted by David Browne on May 31, 2010 at 11:36 PM PDT #

Hi Ricardo

You have a lot of steps to complete in this upgrade.

Firstly you need to upgrade to a later version of 11i as you cannot upgrade directly to R12 from 11.5.5. I'd suggest you upgrade to 11.5.10.12 and 11gR2.

Once you're running 11.5.10.2 you can upgrade this to 12.1.1 and then apply the 12.1.2 upgrade.

Red Hat 2.1 is not certified for R12 or 11gr2 so you will need to look at upgrading the operating system in situ or finding a way of migrating / cloning your 11i/ environment to your new hardware whilst making sure you remain certified.

I'm not familiar with Red Hat 2.5 which you mention.

You will need to take a lot of things into account. The 11.5.5 maintenance pack was released in 2001 and therefore was certified on platforms that are no longer available. This makes finding a migration path to today's platforms more difficult and you sometimes have to perform an upgrade/migration to an intermediate platform.

Regards

Nick

Posted by Nick Quarmby on June 01, 2010 at 12:34 AM PDT #

Hi Dave

Yes, I'd say the main advantage is that you only have a single APPL_TOP to maintain and therefore Apps patches (patches applied using adpatch) only need to be applied once. Other advantages are that both application tier and database tier are, in this configuration, more easily scalable. It also allows you to run your database tier on a different hardware platform to your application tier.

It's difficult to tell exactly what would happen if the connection is lost between the the application and database tier if the concurrent manager is running on the application tier. I would guess you'll start getting ORA or TNS messages once the database can no longer communicate with the FNDLIBR process. I'd guess the same problem would arise if the concurrent manager and database were running on the same node as they are running in different Oracle homes. I don't think the possibility of network failure should be an over-influencing factor in you deciding where you locate concurrent processing (unless you happen to have an extremely fragile network which is another story).

Regards

Nick

Posted by Nick Quarmby on June 01, 2010 at 08:11 PM PDT #

Hi, we'd like to upgrade from 11.5.9 on hpux 11.11 (database and application) to 12 on redhat linux 64bit (running both database and application tiers).
From a high level, does this sound reasonable:

1. Patch hpux 11.11 if required, then upgrade from 11.5.9 to 11.5.10.2 (has 10gR2 dbase)

2. One of these? (ie. which would be better?):
a. Rapid wiz/install of 11.5.10.2 on 64-bit redhat 5; then replace dbase with export/iimport procedure (assuming rman will not work due to architecture difference) from hpux.

b. a "split config" - ie. migrate just the database to linux first, run R12 pre upgrade steps? on the HPUX 11.5.10.2 side.

3. Run an upgrade from 11.5.10.2 to 12 on linux (if using 2a.), or use Rapidwiz to do a fresh version 12 install (if using 2b)

...please send links to appropriate notes and which of above might be close to best approach

thanks, Doug

Posted by Doug on June 29, 2010 at 06:51 AM PDT #

Hi Doug

Assuming you're on 11.5.9 CU2, you should start with Option D of Note 369693.1. This will lead you to Note 362205.1. This explains how to migrate your database to the new platform. You will then be running the application tier on HP-UX and the database on RH5.

You can then refer to Note 761570.1 and choose Path B or Path D to upgrade to R12.1 which requires running the pre upgrade steps on the split configuration then performing the fresh R12 install and R12 upgrade on the new platform.

The above resembles your Option 2b.

You should not attempt your choice 2a which is explicitly not supported which therefore also eliminates Option 3.

The above suggested method allows you to upgrade to 12.1 from 11.5.9 however if you encounter any issues requiring help from Oracle Development we (Oracle Support) will probably advise you to upgrade to 11.5.10.2 as a prerequisite to starting the upgrade due to 11.5.9 desupport. You may therefore consider upgrading to 11.5.10.2 / 11gR2 on HP-UX before starting the whole upgrade/migration process. Upgrading to 11.5.10.2 / 11gR2 will then dictate a different path through Note 761570.1. You would upgrade to 11.5.10.2/11gR2 before migrating the database to RH5.

As you can see there are several alternatives you might wish to investigate. If your first test upgrade does not work out there are other paths for you to try.

Regards

Nick

Posted by Nick Quarmby on June 29, 2010 at 05:07 PM PDT #

Linux migration , it never says about the shared_appl top if the source is in shared appl_top as per note 238276.1 , what would be the steps if we need to migrate shared appl top source to shared appl top target with same number of nodes

Posted by Sumanta on July 19, 2010 at 05:28 AM PDT #

Hi Sumanta

If you already have a shared APPL_TOP/application tier then you would just migrate this as if it was a single standalone APPL_TOP/application tier. When migrated to the new platform you then configure it to be shared again and enable the required services on each new target application tier node.

Regards

Nick

Posted by Nick Quarmby on July 19, 2010 at 04:55 PM PDT #

Hi Nick

Thanks for your previous reply.

Can PCP be run 2 application tiers ? Database is on it's own node. Can jobs failover (TAF?) at this level or is failover only used for RAC envs ?

Thanks
Dave

Posted by Dave on August 25, 2010 at 07:42 PM PDT #

Hi Dave

Yes you can implement Parallel Concurrent Processing (PCP) at the application tier level.

TAF itself does not work with E-Business suite due to Forms/TAF limitations - this is discussed in a little more detail in Note 220970.1.

Regards

Nick

Posted by Nick Quarmby on August 26, 2010 at 06:22 PM PDT #

Hello Nick,

We are planning to migrate from 9.2.0.8 Solaris to 11gR2 on Linux 5.4. Only option available for us to do export/import as our source is 9i. Can we export form 9i and import in 11gR2 directly? In our case we cannot install 9i on Linux 5.4 as it is not certified there. What options do we have and what is the best approach for this requirement?

Thanks a lot for your help.

Regards,
Ravi.M

Posted by Ravi on November 03, 2010 at 01:53 AM PDT #

Hi Ravi

No, I do not believe you can export from 9i and import into 11gr2. You did not mention your version of Solaris or Apps (11.5.x) so it's difficult to give a clear migration path but I'd suggest you upgrade to 11.5.10.2/11gR2 on Solaris (subject to certification) and then perform the migration to Linux from there. This would require a migration of the application tier and an export/import of the 11gR2 database.

Regards

Nick

Posted by Nick Quarmby on November 03, 2010 at 07:29 PM PDT #

Nick,

We're current in a split environment (db @10.2.0.4 on AIX 5.2; apps on rh 4 (32bit) @ 11.5.10.2). We are working towards an R12 upgrade (11gR2, 12.1.3 final release). However, we'll also be replacing all of our servers. We plan to leave db on AIX, but it'll move to a new server (aix6). Apps servers may move to AIX6 also (off of redhat). What would be the reasonable plan for me to follow, (I'd like to leave our current environment in place for failover?) or do I really need to break it up into small phases? And migrate and/or upgrade one or more of the tiers first?

Thanks,
Jennifer

Posted by Jennifer on November 05, 2010 at 06:27 AM PDT #

Hi Jennifer

Both 10gR2 and 11gR2 are certified on AIX 6.1 on the database tier with 11.5.10.2. You can therefore clone your current 10gR2 database to 6.1 and then upgrade to 11gR2 which will give you an 11.5.10.2/11gR2 environment on Red Hat4 and AIX 6.1.

If you then wished to upgrade this environment to R12 you would perform the pre-upgrade steps on the 11.5.10.2/11gR2 environment. When you come to installing R12 you would do a fresh install (choosing the upgrade option) and install the new R12.1.1 filesystem on your new AIX application tier nodes and complete the upgrade to R12 that way.

Using the above method there is no requirement to migrate the application tier nodes to a new platform as part of the upgrade.

Regards

Nick

Posted by Nick Quarmby on November 07, 2010 at 05:33 PM PST #

Hi,

We are currently on 11.5.10.2 using a 10.2.0.3 db on HPUX. We want to migrate to 12.1.3 with 11.2.0.2 on Solaris. I am searching the net for other people having done this but I cannot find anything. I was thinking to do it along the following lines:

- Install 10g on target
- Transport db to target
- Install R12 tech stack using rapidwiz on target
- Upgrade db on target to 11g using rapidwiz
- Further upgrade db to 11.2

During this whole process the source system should remain unmodified so that we can easily come back should we have any issues.
Do you think that this is feasible and if yes do you have any pointers to blogs or docs that can help me achieve this?

Thanks,
Torsten

Posted by Torsten Fassian on January 07, 2011 at 06:25 AM PST #

Hi Torsten

You say that you are "...using a 10.2.0.3 db on HPUX" but I'll assume that you mean your whole Apps environment is currently on HP-UX.

First you need to clone the whole system on HP-UX to create a test environment. I would then suggest you upgrade this to 10.2.0.5 (note 362203.1) to ensure you comply with the Extended Support baseline patch requirements. You could then migrate the 10.2.0.5 database to Solaris. You can use either export/import or Transportable database. This will then give you a system with the 11.5.10.2 application tier on HP-UX and the 10.2.0.5 database on Solaris. You then follow the upgrade manual and perform the pre-upgrade steps on this split environment and install your new R12 environment on Solaris and then complete the upgrade as per the manual which will also include a database upgrade to 11.2.

Subject to certification,you might also consider upgrading the database to 11.2 before migrating it to Solaris. You might also be able to upgrade the database to 11.2 as part of the export/import process (Note 557738.1).

If you want to perform as little as possible on HP-UX (and keep it as original as possible as per your comment) then you can migrate the whole environment to HP-UX using Note 238276.1 and migrating the database using export/import or transportable database. You then perform the whole R12 and db upgrade on Solaris.

Assuming you have a reasonably recent version of HP-UX you have a lot of flexibilty in how you perform this migration. Ultimately you need to find which option works best for you.

Regards

Nick

Posted by Nick Quarmby on January 09, 2011 at 05:02 PM PST #

Hi Nick,

Can you please clarify a reply you made to Laura on May 24, 2010 04:55 in which you said 'run the R12 pre-upgrade steps on AIX. Lay down the R12 code on your new Linux server(s) and complete the upgrade on the split environment'.

I'm preparing to migrate EBS 11.5.10.2 apps only from Solaris to Linux and upgrade to R12 and would like to clarify if I can use the method you suggest, my plan would be.

1. Run R12 pre-upgrade steps on existing 11.5.10.2 environment on Solaris - i presume this is up to but not including running rapid install - I'm using maintenance wizard for my upgrade.
2. install R12 tech-stack on linux
3. migrate to Linux

Note i've already upgraded the DB to 11g and migrated to linux so i'm currently running in a split configuration.

I'm interested in your answer because I asked Oracle how best to migrate and upgrade in SR 3-2026833331 some time ago and the support analyst said I had to upgrade to R12 first before migrating. If I can use the method you suggest then I will save lots of time.

Thanks
Jeremy Cope

Posted by Jeremy Cope on January 16, 2011 at 06:42 PM PST #

Hi,

I have to do the Platform migration for Oracle apps 11.5.10.2, 10gr2 from hp-ux to ibm-aix.
Also i have to configure the MAA at the target node.
Below i am providing my source and target configurations.
Source :
Oracle Apps 11.5.10.2 on HP-Tru64
Database 10gr2 on HP-PA Risc

To be migrated on

Target :

Application on IBM AIX with Shared Appl Top (2 nodes)
database on IBM AIX Power series with RAC (2 nodes)

Please let me know what approach needs to be followed. Also please provide some Doc id's.

Regards,
Ankit

Posted by ankit on January 17, 2011 at 08:01 PM PST #

Hi Jeremy

If I understand you correctly, you started with 11.5.10.2 on Solaris. You wish to migrate this whole environment to Linux. You have upgraded the database to 11g and have migrated it to Linux and so you are now running 11.5.10.2 with 11g with the application tier on Solaris and the database tier on Linux. You wish to now upgrade to R12 and complete the migration to Solaris. I'll respond based on this assumption.

You plan looks ok - you perform all the pre-upgrade functional pre-requisites on the split configuration. Install the new application tier on Linux when instructed to do so by Maintenance Wizard. The main upgrade driver would then be run wholly on the Linux environment. I do not see a need to upgrade to R12 on Solaris first.

Your step 3 says "migrate to Linux". The above process is not really a migration. You have already migrated the database tier. The application tier is not migrated in an upgrade to R12 - it is freshly installed using the R12 installation media. You might have a requirement to migrate some custom code but in a standard upgrade the application tier and technology stack for R12 are newly installed.

Regards

Nick

Posted by Nick Quarmby on January 17, 2011 at 08:04 PM PST #

Hi Nick,

Thanks for answer, yes you understand me perfectly except you stated 'You wish to now upgrade to R12 and complete the migration to Solaris' - the migration is to Linux but I assume this is just your typo.

That's good news for us as it obviously saves us from installing R12 on solaris, but is this approach supported by Oracle? and where is it documented? I've read all the oracle notes I can find but can't find any mention of this migrate and upgrade approach.

Thanks
Jeremy

Posted by Jeremy Cope on January 18, 2011 at 09:37 AM PST #

Hi Nick,

can you please help me in my question.

Regards,
Ankit

Posted by ankit on January 18, 2011 at 01:26 PM PST #

Hi Jeremy

Yes, sorry, that's my mistake - I meant to say Linux.

This approach is supported by Oracle. I take your point that it's not documented - and I'll look into this - but it's an approach we've been advising via Support for many years. Both the split configuration you're currently running and the homogeneous environment you will create are certified environments which is why it's supported. Once you've completed the pre-upgrade steps in the split configuration your source application tier is effectively dead as you then move to the new environment from which to run the rest of the upgrade. Assuming the new environment is certified then the process of completing the upgrade on there would be supported.

Regards

Nick

Posted by Nick Quarmby on January 18, 2011 at 05:07 PM PST #

Hi Ankit

You could initially migrate the database tier from HP-UX PA-RISC to AIX - see Section 2 of the blog article to choose the method most appropriate to your particular circumstances. You would then have your application tier running on HP Tru64 and the database tier on AIX. The References section at the end of the blog article contains links to Notes you might use once you have decided on the most appropriate method to migrate your database. I'd suggest you aim to upgrade to the latest version of the database currently certified (11.2.0.2).

Once the database migration and upgrade is complete, you then perform the R12 pre-upgrade steps on the split configuration before installing the new R12 application tier on AIX allowing you to run the rest of the upgrade on the AIX environment. Note - HP Tru64 is not a certified platform for R12.

The installation of a shared application tier is discussed in the R12 installation manual. Once you have the R12 environment running it would be a separate exercise to convert it to RAC as per Note 823587.1.

You should discuss the MAA configuration most appropriate for your requirements with your platform vendors. We do not document the configuration of third party technologies such as this.

Regards

Nick

Posted by Nick Quarmby on January 18, 2011 at 05:47 PM PST #

Hello, Nick,

We are migrationg EBS 12.1.2 (DB: 11.1) from Sun to Linux.
We have other applications: MDM, Disco 10g, OTM/SOA,OBIEE Apps and GRC/tomcat installed, since we don't have the originally build documents,but we need to migrate the system as soon as possible, at this time, we are not sure how MDM was installed at a short period of time.

Could you please let me know how to find out in details if MDM is part of the regular app or its own MT that connects to the DB?

Thanks
Jenny

Posted by Jenny on January 19, 2011 at 02:15 PM PST #

Hi Jenny

I'm guessing you mean Oracle Master Data Management Suite (MDM). I'm not familiar with the architecture of this particular product. I'd encourage you to raise a Service Request with the relevant Oracle Support group who should be able to help you understand how this is integrated into your particular E-Business Suite environment. It may be that you need to reimplement the MDM technology stack following the initial migration of the E-Business Suite environment to your new platform

Regards

Nick

Posted by Nick Quarmby on January 19, 2011 at 06:09 PM PST #

Hello, Nick,
We are installing a 3 nodes EBS 11.2.1, one node for DB with DB user, 2 nodes for APPS tier (shared COMMON_TOP, APPS_TOP, but not shared Web, and Forms servers) with applmgr user, but the 11.2.1 installation guild (Part No. E12842-02
) is clear to me.
1) should I install (rapid install) DB and apps with root user?
2) should I install db first, then install on the primary apps tier, then add node to the second node?
Thanks for your help! Peter

Posted by Peter on January 20, 2011 at 12:00 PM PST #

Hi Peter

You should not need to install as root. You start by running rapidwiz on the database node as the oracle:dba (or your defined user:group) user. You define all nodes in your environment during this initial rapidwiz session. You define each additional node, the file locations, the user credentials, and the services each node runs during the rapidwiz session on the database node. When this completes you then run rapidwiz on the other node(s) and retrieve the configuration details stored in the database to configure and install the additional nodes.

I see you plan to use a combination of shared and local files on the applications nodes. Documentation has encouraged using a shared file system for all application node files for some time now and I'd encourage you to go with this option. See page 1-5 of the installation manual here - http://download.oracle.com/docs/cd/B53825_07/current/acrobat/121oaig.pdf - which discusses the benefits of a fully shared application tier filesystem.

Regards

Nick

Posted by Nick Quarmby on January 20, 2011 at 05:12 PM PST #

Hi Nick,
I downloaded Oracle12.1 from Oracle edelivery for Linux. There are lots of zip file, when I unzip these files, it keeps asking me if I want to overwrite some of the files. The choices are "Y", "N", "A".
I am not sure how to answer and I can not find Oracle doc about this.

I choosed "Y" and "A" to overwite all the files. However, when I run Rapid install on primary node after DB is up and running, I stuck on this window:

Enter the location for the disk labeled" Oracle Applications Rapid install -- ToolS Disk1"

Should I choose not to overwirte the files when I unzip the downloaded zip files?

Thanks

Posted by Lisa on January 21, 2011 at 12:41 PM PST #

Hello Nick,
We are migrating EBS12.1.1 from Sun to Linux. On target servers: the application servers are installed 32 bits Red Hat 5.6, while the DB servers is installed with 64 bits Red Hat 5.6. I download the correct softwares from edelivery, however, after installed, we are not able to open any of the FORMS, we got: FRM-92050:Failed to connect to the Server:/forms/lservlet:-1
We know it is compatible to use different platform for the db and the apps servers. And I tried all notes from metalin, but still not working. Please advice.
Appreciated! Chris

Posted by Chris on January 22, 2011 at 10:25 PM PST #

Hello Steven/Nick
We are migrating EBS to 12.1.2 to Linux, we have 5 tiers, 1 for DB, 1 for MDM (Prod Data Hub), 1 for discoverer, 2 for EBS (COMMON_TOP/APPL_TOP,TECH_STACK)
I KNOW oracle suggest we share all the file systems (COMMON_TOP/APPL_TOP,TECH_STACK) except INST_TOP. However, the decision has been made as the follow layout: Shared file system for COMMON_TOP and APPL_TOP:
lOCAL File system for Tech Stack and INST_TOP:
Question:
1) We have installed EBS on DB Tier and primary node, but could not any Oracle doc. for how to add the second node (COMMON_TOP,APPL_TOP,TECH_STACK, INST_TOP)? Could you please let me know how to do this? In 11.5.10, we create the second node by:
a). perl adclonectx.pl sharedappltop contextfile=primary_note_context_file.xml
b). run auto adconfig.sh on the new node
Can we use the same steps to add the second node?
2) how the MDM is implemented? Should we install the 12.1 software on it's own tier as install on the other tier?
i could not find any Oracle doc. for this.
Very appreciated it!!
Jeff

Posted by Jeff on January 23, 2011 at 10:52 AM PST #

Hi Lisa

It should be OK to use "Y" and "A" when unzipping the downloaded zip files. Make absolutely sure the unzip completes successfully for each file downloaded - it's sometimes easy to miss errors when a long unzipping process is racing past on the screen.

You can also check the integrity of your staging area using Note 802195.1. If you continue to have problems after this then can I suggest you raise a Service Request with Oracle Support so they can take a closer look.

Regards

Nick

Posted by Nick Quarmby on January 23, 2011 at 04:51 PM PST #

Hi Chris

Did you follow Note 438086.1 to perform the application tier migration? If so, you should have only needed to perform a "rapidwiz -techstack" installation when installing the application tier technology stack.

Did you migrate the database tier first? If so, were you able to log in successfully to the split configuration with the application tier still on Sun and the migrated database tier on Linux?

Is it possible there are any port restrictions in place between the application and database tiers?

Have you tried just a simple fresh installation of R12.1 on the new hardware to see if this works in your environment "out of the box"?

If having reviewed the above suggestions you are still having problems on your migrated environment can I suggest you raise a Service Request with Oracle Support as they will be able to review your migration more thoroughly.

Regards

Nick

Posted by Nick Quarmby on January 23, 2011 at 05:46 PM PST #

Hi Jeff

There is a section in Note 406982.1 called "Option 3: Adding a New Node to an Existing System" which explains how to create additional application tier nodes which should do the job.

I'm really not qualified to speak about MDM and how it's integrated with the E-Business Suite. I'd encourage you to raise a Service Request to get up to date information from Oracle Support on how you implement this.

Regards

Nick

Posted by Nick Quarmby on January 23, 2011 at 08:01 PM PST #

Nick,

Thanks for a superb article.

We are currently running 11.5.10.2 on 9.2.0.7 on a single tier Solaris 9 OS.

We need to get to R12 and 11g on a single tier 64bit RHEL 5 box.

If I'm asking too much then please tell me so - but in a nutshell, what would be your default preferred approach?

Regards,

- Matt Symes

Posted by Matt Symes on January 31, 2011 at 10:31 PM PST #

Hi Matt

Sorry for the tardy response. We had a technical issue with the Comments interface here.

I'll assume your Solaris platform is 64 bit. In this case you are certified to use 11.5.10.2/11gR1 on Solaris so you should upgrade the 11.5.10.2 database to 11gR1 first (Note 452783.1). 11g is only available as 64 bit software and you cannot migrate your current environment to Linux as neither the application tier (11.5.10.2) nor database tier (9.2.0.7) are certified on 64 bit RHEL 5 which is why I'm suggesting this step first.

You can then migrate the db tier to Linux giving you a Solaris/Linux 11.5.10.2/11gR1 split configuration. Solaris and Linux have a different Endian format so you must use export/import to perform the migration (Note 557738.1).

You then run the R12 upgrade performing the pre-upgrade steps on Solaris/Linux before laying down the new R12 environment on Linux and completing the upgrade to R12 wholly on the Linux environment.

You can the upgrade the database to 11gR2.

There will be a different path if your Solaris platform is 32 bit - please let me know if this is the case.

Regards

Nick

Posted by Nick Quarmby on February 07, 2011 at 07:15 PM PST #

Hello Nick, We have many of EBS env with EBS12.1.3 (db: 11.1.0.7) in Red Hat 5.6 that clone from the same source. somehow only the source CPU over 99.95% and all "top" (command) processes are FNDLIBR (about 20 of them). We just reboot the server last week and run autoconfig, cmclean, re-compilc invalid objects , re-load jar file, re-compile forms etc. We found the note "FNDLIBR Consuming Memory Causing CPU Utilization to Increase Daily [ID 264752.1]" but it is for 11.5.10, while we are already in 12.1.3. Can you please let us know what are the root causes? Thanks! Peter

Posted by guest on June 12, 2011 at 01:37 AM PDT #

Hi Peter This sounds a little too complicated to troubleshoot through the blog Comments interface. I'd suggest you raise a Service Request with Oracle Support who may well involve the ATG Performance Team to help. You should include a detailed explanation of your o/s platform, hardware specification and architecture (numbers of nodes etc.) which should help the investigation. Regards Nick

Posted by Nick Quarmby on June 12, 2011 at 06:24 PM PDT #

Hi Nick
We are migrating EBS(11.5.10.2) db(9.2.0.7) from Sun Solaris 8 to OEL 4.8
Our environment running on 2 nodes.
First we intend to do split migration on Apps Tier then Migrate DB Tier.
Apps Tier --- Form, Web
DB Tier --- Database, CM, Report, Admin
Current Database is 32bit on 64bit OS Solaris.
Please let us know what are the steps necessary and how to merge all the apps node into single APPS Tier, since no apps tier support 64bit.

Thanks
Sheeraz Khan

Posted by guest on June 19, 2011 at 05:39 AM PDT #

Hi Sheeraz

Your description is not quite clear enough to fully understand you objectives.

If your target platform is Oracle Enterprise Linux 4.8 x86_64 then you are correct, it is not certified for the 11i application tier. You can migrate your 9.2.0.7 database tier to this platform but the 11i application tier environment must remain on Solaris in a split configuration.

You can use this split configuration as a base in order to upgrade to R12 on Linux x86_64 which is certified for both application and database tiers.

There are no plans to certify the 11i application tier on 64 bit Linux.

Regards

Nick

Posted by Nick Quarmby on June 20, 2011 at 08:47 PM PDT #

Nick,
You understood me correctly. We will use Linux x86_64 for only Database Tier, and Linux x86_32 for Application Tier. However, you have not answered my question. What are the steps to migrate the split configuration?
Should I First merge all of my Applications into one Application Tiers in solaris and then migrate it into Linux or Can I do it directly? such as migrate all the Apps tier from DB Node and Apps Node into one Linux Application Tier.

Thanks
Sheeraz

Posted by guest on June 21, 2011 at 05:19 AM PDT #

Hi Sheeraz

Merge your application tiers on Solaris first - follow the procedure for Merging existing APPL_TOPs in Note 233428.1 on My Oracle Support.

You can then migrate your single Solaris application tier to your Linux 32 bit platform using Note 238276.1.

Migrate the database tier to Linux first.

Regards

Nick

Posted by guest on June 21, 2011 at 07:20 PM PDT #

Nick,
Please let me know the steps for Data migration, since you have recommended to go for Database first. We are using around 500G of Data.
With 9i no RAC, so I guess only option is to export and then import the whole database. Please help me on this.

Thanks
Sheeraz

Posted by Sheeraz Khan on June 27, 2011 at 07:14 AM PDT #

Hi Sheeraz

You would first have to upgrade the database to 10g 64 bit on Solaris 8. I've checked and this is certified. This is because 9i is not certified on Linux x86_64 and 11gR2 is not certified on Solaris 8 meaning you must upgrade to 10gR2 on Solaris 8 first. Follow Note 362203.1 to achieve this.

You can then migrate the database to Linux x86_64 using Datapump. You also upgrade the database to 11gR2 as part of the Datapump process. Follow Note 557738.1 to achieve this.

Regards

Nick

Posted by Nick Quarmby on July 04, 2011 at 12:04 AM PDT #

Nick,

Would you have any documented procedures, steps, specific suggestions and/or recomending tools for migrating Oracle 9.2.0.8 on AIX to Oracle 10.2.0.4 on Linux.

Thank you,

MG

Posted by guest on July 15, 2011 at 02:36 PM PDT #

Hi MG

AIX uses the big endian format whereas Linux uses the little endian format. This means you will have to use datapump or transportable tablespace in order to perform this migration.

Both the above options require you to upgrade the database to 10gR2 on source first. The upgrade to 10gR2 is explained in Note 362203.1.

The datapump migration is explained in Note 362205.1 The transportable tablespace migration is described in Note 454574.1

You could also use export/import (as opposed to datapump) if you want to migrate your 9.2 database to Linux but you will still be required to upgrade the target database to 10gR2 after the migration. This is explained in Note 230627.1. You should be aware that Note 230627.1 is no longer being actively maintained and I would encourage you to follow my initial suggestions.

You should check the certification status of the database versions you plan to use against your specific operating system versions before starting any upgrade/migration as this may also influence how the migration is performed.

Regards

Nick

Posted by Nick Quarmby on July 17, 2011 at 07:11 PM PDT #

Hello Nick,
Can you please let us know if we can clone EBS 12.1.3 from 32 bits OS to 64 bits OS on Red Hat 5.6?

The reason we need to do that is, we have configurator installed, however,due to the jvm limtation on 32 bits OS (max 4GB on32 GB), we can only use Xms=2560M. while most of the CPU (4 cpu) and Memeory (32 GB) are not in use. JVM crashed when it reach 1.5GB.

if there any way, we can increase the number of JVM on the server?

Thanks
Peter.

Posted by guest on August 07, 2011 at 02:10 AM PDT #

Hi Peter

Migrating 12.1.3 from 32-bit Linux to 64-bit Linux is performed in two stages.

The database tier must be migrated (not cloned) as cloning will simply produce a 32 bit database tier on your 64 bit platform which does not really achieve anything. Note 762669.1 explains how to migrate the database tier and include the 64 bit upgrade at the same time.

The application tier can just be cloned using the method described in Note 406982.1.

I advise you to raise a separate Service Request if you require information about JVM optimisation so you can speak to an expert in that area.

Regards

Nick

Posted by Nick Quarmby on August 07, 2011 at 06:16 PM PDT #

Hi All,
Thanks. This information has been very useful.
Does anyone have a project plan for a platform migration of R12 from Redhat Linux to Oracle Linux. If so, can u please provide the detailed Project plan.
Regards,
Mahesh

Posted by Mahesh on November 27, 2011 at 08:57 PM PST #

Hi Mahesh

This sounds like a straightforward clone. The only issue is if you were going to 64 bit Linux from 32 bit Linux in which case you would follow Note 471566.1.

Before starting, you should also ensure your current technology stack combination is certified on your target Linux version.

Regards

Nick

Posted by Nick Quarmby on November 28, 2011 at 07:15 PM PST #

Hello,
I have read some blogs regarding database migration 11i on different platforms.Here is my current env.that require some guidelines

I have my DB(9207) and concurrent manager/Admin tier on HP server (11.5.9) . 32 bit
The Apache/report is on REDHAT Linux 32 bit

My Objective is to have DB/Apps tier as a single node on AIX 6.1 by doing a fresh Install of R12.1.3
and migrate the Database/Apps tier to AIX. The database is going to be 11.2.0.2
ie Apps Install R12.1.1 and upgrade to 12.1.3
upgrade rdbms 11.1.0.7 to 11.2.02 and then
start migrating the db/apps from hp to AIX

From the blog,It doesn't look like 9207 is supported as per #369693.1
Please let me know the best approach and any metalink note that can useful for the purpose.
Note: I can't not do any database upgrade to 10gR2 at this time.!!!

Posted by guest on December 13, 2011 at 01:50 PM PST #

Hi Guest

Your upgrade and migration will depend on certification. You will need to migrate the database to AIX. In order to do this you will need to upgrade to a minimum of 11.5.10.2/10gR2 first as 9i is not certified on AIX 6.1. I don't see a way of avoiding this and remaining certified. You would then have your environment distributed across three platforms which is also far from ideal.

You can then follow Note 761570.1 which should give you a path to complete the upgrade/migration. This would involve completing R12 pre-upgrade steps before installing the fresh 12.1.1 application tier on AIX and then upgrading the database to R12. You would then upgrade again to 12.1.3.

If you want a more detailed analysis of your upgrade path I suggest you raise a Service Request with Oracle Support. You should supply the Red Hat and HP-UX o/s versions as this is often significant in choosing the best upgrade and migration path.

Note 369693.1 is not applicable to you. This Note should only be used if you are planning to use a platform that is only certified for the E-Business Suite at the database tier. In your case this does not apply.

Regards

Nick

Posted by Nick Quarmby on December 19, 2011 at 10:00 PM PST #

We want to migrate/upgrade eBS 11i with 9i (9.2.0.6)RAC on HP-UX with load balancer to SPARC cluster with following steps
1)using exp/imp to move db from hp-ux to sparc 11 on 9i
2)configure grid infrastructe for RAC and upgrade to 11gR2 with RAC
3) configure APPS 11.5.10.2(on HP-UX with Load balancer)to new DB
4) keep this split configuration available to users for nearly 3 months
5) install 12.1.3 on new sun SPARC machines to upgrade to 12.1.3 with load balancer for final upgrade to 12.1.3- now whole application & DB on SPARC 64 bit
please confirm these steps ok or please provide guidance

regards aamir

Posted by Aamir on April 24, 2012 at 06:31 AM PDT #

Hi Aamir

You mention you plan to use Solaris 11 as your new target platform. Neither the application or database tier of 11i is certified on Solaris 11. I am not aware of any plans to certify this combination.

Because 9i has been out of Premium Support for some time, we advise you to start by upgrading your database on the HP-UX environment to 10gR2 or 11gR2. Please check which is the latest database version certified for your HP-UX version and upgrade to this version. You should follow either Note 362203.1(10gR2) or Note 881505.1(11gR2).

Because 11i is not certified on Solaris 11, you cannot create the split configuration you describe. You will need to combine the upgrade to R12 with the migration to Solaris.

You would start by migrating your database tier to Solaris using Note 881505.1. You then install the 12.1.1 filesystem on Solaris before completing the upgrade to 12.1.1. You then upgrade to 12.1.3. You should review Note 269.1 which provides a wealth of information about planning and executing your upgrade to Release 12.

You can then convert to RAC using Note 823587.1.

Note 761570.1 has more information regarding the upgrade process depending on the database version you are using.

Regards

Nick

Posted by Nick Quarmby on April 24, 2012 at 08:17 AM PDT #

Hi Nick- thanks for your response, now if i change Solaris 10 instead of Solaris 11 my question would be
We want to migrate/upgrade eBS 11i with 9i (9.2.0.6)RAC on HP-UX with load balancer to SPARC cluster with following steps
1)using exp/imp to move db from hp-ux to Solaris 10 on 9i
2)configure grid infrastructe for RAC and upgrade to 11gR2 with RAC
3) configure APPS 11.5.10.2(on HP-UX with Load balancer)to new DB on Solaris 10
4) keep this split configuration available to users for nearly 3 months
5) install 12.1.3 on new sun SPARC machines to upgrade to 12.1.3 with load balancer for final upgrade to 12.1.3- now whole application & DB on SPARC 64 bit
please carefully go through these steps and confirm or please provide guidance

regards aamir

Posted by aamir on May 01, 2012 at 11:37 PM PDT #

Hi Aamir

Solaris 10 makes your proposal more viable. I will assume you currently have 11.5.10.2.

Because of the support status of 9i we'd still encourage you to upgrade the database to 10gR2 or 11gR2 on source before migrating to Solaris however you can still follow Note 230627.1 if you wish. If you follow Note 230627.1 you will then have your application tier on HP-UX and database tier on Solaris.

You can then run this configuration until your planned upgrade to R12. You would perform the pre-upgrade steps on the split configuration before installing the new R12 software on the Solaris platform and then completing the upgrade to R12 on Solaris.

Regards

Nick

Posted by Nick Quarmby on May 03, 2012 at 03:09 AM PDT #

Hi Nick.
Here is our actual situation.
- one server on Suse enterprise 11, with Oracle 10.2.0.4 ans apps 12.1.1
Our target is :
- one server on Sun/Solaris, with Oracle 11.2.0.3
- a second server on Red-Hat 6, with the apps. 12.1.3 as goal, but maybe we first make a fresh install of 12.1.1. (just to be able to use the apps cloning tool. need the same release and level)

Our problem is :
non conform user name :
Our APPLSYS user is named FND and our APPS user is named APPS_FND. This give me lot of trouble and work when i had to apply patches (need to open an SR and obtain a specific patch with APPS_FND user).

Oracle didn't give tool to rename APPS and APPLSYS user (allowed before release 10.7 of apps, but non supported after).
What i would like is remove this abnormal user name via the clean install.
I plan to use the datapump process as it allow me to change the target schema (APPS_FND swith to APPS and FND switch to APPLSYS), but do you think it's a safe way ?
is there another way to do that ?

Regards,
Eric

Posted by guest on December 20, 2012 at 01:02 PM PST #

Hi Eric

The migration of the application tier from Suse to RH6 should just be a clone unless you're migrating from 32 bit Linux to 64 bit Linux in which case you will need to perform a migration/clone as per Note 471566.1. You should not need to do a fresh install of 12.1.1 on RH6.
Pay attention to Note 761566.1 which states that if you're moving to oracle Linux 6 or RHEL 6 that you "must first upgrade the Oracle Database to 11gR2 (11.2.0.3 or higher) and Oracle Application Server 10gR3 to 10.1.3.5 on the source 12.1.1 system".

Having a non-stand APPS and APPLSYS schema name should not be an issue. We have quite a few customers who have come from pre 10.7 days. E-Business Suite patches should be able to cope with this. If you encounter any patches that fail because of this, then yes, you should contact Support.

I do not suggest you attempt to rename your APPS and APPLSYS schemas using the method described. There is no documented process to achieve this and I do not know of anyone who has done this. I advise you to continue with your current schema names.

Regards

Nick

Posted by Nick Quarmby on December 21, 2012 at 01:21 AM PST #

Hi Eric

The migration of the application tier from Suse to RH6 should just be a clone unless you're migrating from 32 bit Linux to 64 bit Linux in which case you will need to perform a migration/clone as per Note 471566.1. You should not need to do a fresh install of 12.1.1 on RH6.
Pay attention to Note 761566.1 which states that if you're moving to oracle Linux 6 or RHEL 6 that you must first upgrade the Oracle Database to 11gR2 (11.2.0.3 or higher) and Oracle Application Server 10gR3 to 10.1.3.5 on the source 12.1.1 system.

Having a non-stand APPS and APPLSYS schema name should not be an issue. We have quite a few customers who have come from pre 10.7 days. E-Business Suite patches should be able to cope with this. If you encounter any patches that fail because of this, then yes, you should contact Support.

I do not suggest you attempt to rename your APPS and APPLSYS schemas using the method described. There is no documented process to achieve this and I do not know of anyone who has done this. I advise you to continue with your current schema names.

Regards

Nick

Posted by Nick Quarmby on January 02, 2013 at 01:13 AM PST #

Hi Nick,

We are migrating from AIX to Linux for EBS 11i ( 11.5.10.2.)

You mentioned that we can do a lot of the migration ahead of time. However, during the migration, I assume there are some steps like autoconfig that will update the database, so how can we do some steps ahead of time?

In theory, I would like to do the migration ahead of time as much as possible. Would you be able to discuss that?

Thanks in advance,

Phil

Posted by guest on January 07, 2013 at 01:19 PM PST #

Hi Phil

Yes, there's plenty you can do with respect to the application tier migration.

The application tier on the new platform can be built/migrated whilst the production environment is still available using the principles described in Note 242480.1 in conjunction with Note 238276.1.

You cannot easily avoid the downtime associated with the time to migrate the database or processes like AutoConfig but again, you can build the new RDBMS Oracle Home in advance of the main downtime.

Once you have done your first few test migrations you will see other opportunities to reduce downtime.

Regards

Nick

Posted by Nick Quarmby on January 08, 2013 at 01:02 AM PST #

Hi Nick,
Thanks for all the answers you provided in the comments. I wish to get your thoughts on our proposed migration & upgrade. These are the details:
Source DB Tier : 10.2.0.3
Solaris 10

Target DB Tier : 11.2.0.3
Oracle Linux 6

Source Apps Tier : 12.0.3
Solaris 10

Target Apps Tier : 12.1.3
Oracle Linux 6

Before we actually start with the migration and upgrade process, we would like to build an environment on the target platform for our DBAs and Developers to familiarize themselves.

My questions are:
1. What is the right sequence of steps to follow?
2. What is the best way of migrating the apps tier? I think for the DB tier we have no option except datapump.

Thanks,

Ramesh

Posted by guest on January 18, 2013 at 01:51 PM PST #

Hi Ramesh

Source = 12.0.3/10.2.0.3 - Solaris 10

Target = 12.1.3/11.2.0.3 - Linux 6

I will assume your target Linux platform is 64 bit.

12.0.x/10.2.0.x is not certified on Linux 6 so you will have to upgrade to 12.1.x before the application tier migration.

So, the steps are as follows....

1. Upgrade application tier to 12.1.3 on Solaris using Note 752619.1. This includes links to the latest 10.1.2 and 10.1.3 upgrades which you must also apply.

2. Upgrade to 12.1.3 on Solaris following Note 1080973.1.

3. Migrate the database tier to Linux using Note 741818.1. You can export the 10gR2 database and import into the new 11gR2 database. The upgrade is performed as part of the migration.

4. Migrate the application tier to Linux following Note 438086.1.

If you perform a fresh installation on Linux 6 you will create a 12.1.1/11.1.0.7 environment first which must then be upgraded to 12.1.3/11.2.0.3. The fresh installation process is documented in Note 761566.1. Please ensure all Linux 6 pre-requisites are complied with. Although this fresh installation may be a useful exercise in familiarisation it has no real value in the migration process as it will not represent a valid test environment (for UAT for example) of a properly migrated environment.

Regards

Nick

Posted by Nick Quarmby on January 21, 2013 at 12:35 AM PST #

Hi Ramesh

Sorry, I need to correct my last comment. Step 1 should read as follows...

1. Upgrade to 12.1.1 on Solaris using Note 752619.1. This includes links to the latest 10.1.2 and 10.1.3 upgrades which you must also apply.

Regards

Nick

Posted by Nick Quarmby on January 22, 2013 at 02:26 AM PST #

Thanks Nick for your help.

Ramesh

Posted by guest on February 01, 2013 at 02:49 PM PST #

Hi Nick,
Thanks for answering my earlier questions on migrating from Solaris to Linux. We ran our first upgrade/migration iteration last month. We followed the path you specified of upgrading to 12.1.1 then to 12.1.3 on Solaris and then using datapump to migrate to 11.2.0.3 on Linux 6 and migrating the app tier to Linux 6. The whole process took much longer than we can afford given our slow and aging Solaris hardware. We are looking at options to speed up the process and had some questions that we were hoping you could help us with:

1. Do you have any recommendations on moving to Linux earlier and then doing the upgrade on Linux? We are contemplating creating a Linux 5 environment, upgrading to 12.0.4 or 12.0.6 on Solaris, migrating the app and db tier to the Linux 5 environment and running the upgrade to 12.1.3 on Linux.

2. All things being equal, should a 12..0.3 to 12.0.4/12.0.6 upgrade on the Solaris app tier take much less time than a 12.0.3 to 12.1.1 upgrade?

Thanks

Ramesh

Posted by guest on July 10, 2013 at 07:49 AM PDT #

Hi Ramesh

Linux 5 as an intial target environment would certainly simplify things a lot.

You could upgrade to 12.0.4 (the lowest Apps version certified with 11gR2) on Solaris. You then migrate/datapump the database from 10gR2 on Solaris to 11gR2 on Linux. You then migrate the application tier from Solaris to Linux then complete the 12.1.3 upgrade on Linux. This puts the burden of work on to the Linux platform.

You could also split the process into two downtime windows. The first downtime concentrates on the work that has to be done on the Solaris platform whilst remaining certified. The second downtime would cover the Apps migration and Apps upgrade on Linux.

As I'm sure you have realised, the constraint in your earlier upgrade path is the requirement for 12.1.3/11.2.0.3 on Linux 6 which does not apply with Linux 5.

There are quite a few permutations for how you might perform this upgrade/migration. It would be difficult to guess which is the quickest but the one which places the majority of work on the new hardware is likely to be the most efficient.

Regards

Nick

Posted by Nick Quarmby on July 10, 2013 at 08:12 AM PDT #

Thanks Nick. I just had one more question. Would it be possible to keep the DB Tier on Linux 6 and the App. Tier on Linux 5 during the upgrade or is it better if we keep both the tiers on Linux 5?

Thanks,
Ramesh

Posted by Ramesh on July 10, 2013 at 03:47 PM PDT #

Hi Ramesh

Having the database tier on Linux 6 and the application tier on Linux 5 to simplify the upgrade/migration is fine (and more importantly certified) although I think in the long term, the elegant solution is to have both tiers on the same platform.

Regards

Nick

Posted by Nick Quarmby on July 11, 2013 at 12:34 AM PDT #

Hi Nick,
Just wanted to let you know that we did run an iteration of the upgrade by migrating to Linux with 12.0.4 and then running the upgrade there. There was a substantial reduction in the time taken for the upgrade by running the upgrade on the newer hardware. We also used the parallel option during the datapump export and import to speed up things and that helped us cut down the export import times by half.
There is one more optimization we plan to test out during the third iteration of our upgrade. We are thinking of importing the indexes separately instead of loading them as part of the regular import. We plan to use SQLFILE to get the SQL script for the index creation and then split this file and run the separate pieces in parallel. Do you have any comments on this approach?
Thanks for all the help.

Ramesh

Posted by guest on August 23, 2013 at 11:49 AM PDT #

Hi Ramesh

I'm glad to hear you're seeing reduced downtime following our earlier discussions.

Regarding the datapump changes you suggest, I am reluctant to unconditionally endorse any process that significantly varies from the published Note simply because it is unlikely to have been tested within Oracle.

The export/import Note you are currently following documents a method that has been devised and tested by Oracle Development and then used by many customers so we're confident it works. Issues will have been raised and fixed to further refine and improve the process. We also hope it is the method that provides acceptable performance across a range of typical customer environments.

You're welcome to try your own alternate method but if you see any issues we'll probably ask you to reproduce them using the method documented in the Note first.

Regards

Nick

Posted by Nick Quarmby on August 27, 2013 at 01:26 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today