Field-Tested Advice for Smooth EBS Upgrades

Premier Support for Oracle E-Business Suite Release 11.5.9 ended in June, 2008.  If you are currently running 11.5.9 or earlier and your immediate plans do not involve an upgrade to Release 12, then it's a good idea to move up to the terminal release of Apps 11i: This will ensure you remain supported and can make the most of any technology stack and functional upgrades. 

A lot of what you do as part of an upgrade to will also ease your transition to Release 12, so this upgrade can be considered as a Release 12 prerequisite exercise, too. Critical patch updates, roll-up patchsets (RUPs) and new technology stack certifications are still being released for Apps, and the more up-to-date your system is, the easier it will be to apply these when they come along.  This article takes you through some of the best tips from Oracle Support to ensure a successful upgrade to EBS

Screenshot patch 3480000.png
Tip #1: Give Yourself Enough Time

The first and most important piece of advice is to give yourself enough time. If you have not done an upgrade like this, then don't create a project plan with fixed dates and times until you have a good feel for what the upgrade will involve and how long it will actually take. Your current E-Business Suite release and database version will dictate how much work you have to do. Not surprisingly, if you are running Apps 11.5.2 on the Database, you will have your work cut out for you.  If you are on 11.5.9 and, then your job will be much easier.

We talk to a few customers who have decided how long they have to complete the entire project before even contemplating what work is required. Don't fall into this trap. Nobody likes working with a gun to their head, least of all, one that they're holding themselves.

Remember this is not just a technical upgrade. The Maintenance Pack has functional and technical implications.  Even if the upgrade is not motivated by functional requirements, it will certainly require User Acceptance Testing.

Tip #2: Read the Documentation Beforehand

Engineers in Oracle Support would be the first to admit that navigating through a combination of Oracle manuals, Notes from My Oracle Support and adpatch readme files and then corralling all that information into a coherent upgrade strategy can be an intimidating task. The temptation to use documentation that is not specifically written for the E-Business Suite or to devise an upgrade strategy of your own can sometimes look very appealing.

It's not difficult to find a document that appears to apply to your circumstances but then have Oracle Support tell you that you need to be following a different document.  Documentation that is specific to Oracle Applications exists for upgrading just about every component of the technology stack. If, for example, you can't find the Note that talks about upgrading or patching Developer 6i (Note 125767.1) then raise a Service Request (SR) with Oracle Support.

Tip #3: Don't Take Any Undocumented Shortcuts

We're sometimes asked, "What if I ignore Step X of my upgrade? Will it still work?" This is an almost-impossible question to answer.  In Oracle Support, we're not insensitive to questions such as this, but the reality is that we will probably not be able to give you a clear and unambiguous answer.

Our published documentation is designed to achieve a successful upgrade. It is not tested by trying to perform the upgrade steps in a different order or by deliberately omitting steps to see how the upgrade will turn out.  You should perform all steps in the upgrade documentation unless you have a clear reason not to, or clear guidance from Oracle Support that a step can be omitted.

Given the above, it's also no surprise that a common question we get from customers is "Here is my upgrade plan. Can you go through it and tell me if it's OK?"  This is a perfectly understandable question to ask but sometimes a tough one to answer, especially if the upgrade includes platform migrations, technology stack updates, and Oracle Applications upgrades. 

We'll try to do out best, but it's difficult for us to give an unconditional endorsement of an upgrade plan that greatly varies from our documentation. Circumstances may sometimes force you to perform upgrade steps in a non-standard order. We're always happy to discuss variations, but it is unlikely we will be able to give you a carte blanche endorsement of an entirely bespoke upgrade, since we are unlikely to have ever attempted an upgrade in the way you might describe.

Tip #4: Get the Latest Patches and Maintenance Tools

Start by reading Note 316365.1: the Maintenance Pack documentation. This has all the major steps you may or may not need.  The Upgrade Manual Script for the Maintenance Pack (TUMS-MP) will also create a report listing the steps which are required -- specific to your system -- therefore telling you what steps can be omitted.

Apply the latest AD patchset as early as possible in the upgrade.

Whenever you see a patch specified in documentation do not assume this is the latest incarnation of this patch. Check on My Oracle Support to see if it has been superseded. If it has, apply the latest version whenever possible.

Implement AutoConfig if you have not done so already.  If AutoConfig is only implemented on the application tier, then implement it on the database tier without delay.

Install and run the Technology Stack Validation Utility. If this reports any errors then, instead of trying to address each issue individually, I'd encourage you to just go to Note 146468.1 and build new 8.0.6 and iAS ORACLE_HOMEs using the install media. This will save you time.

Tip #5: Switch to the Oracle Applications Tablespace Model (OATM)

OATM is the latest Oracle Applications tablespace model. Instead of having separate tablespaces for each product, it converts your system to use a greatly reduced number of tablespaces. This is installed by default in fresh installations from 11.5.10 onwards. It will almost certainly reduce the overall footprint of the database, will simplify administration, may improve performance, and is mandatory for Release 12.

It will take some time to migrate all your database objects to the new tablespaces, but the benefits are worthwhile. The opportunity to optimise a database that may have been running for several years should not be underestimated.

Tip #6: Configure database for new products and new tablespace requirements

With each Maintenance Pack release there tend to be some new products introduced.  These products have to be "spliced" into your existing database and APPL_TOP.  Pay particular attention to the patch readme and complete all steps.  You cannot avoid adding these new products simply because you do not anticipate licensing or using these products.  This is a mandatory step. 

Tip #7: Upgrade the database (conditional) 

Releases 10gR2 and 11gR1 are currently supported for the E-Business Suite.  If you're running an earlier database release, you need to upgrade to at least 10gR2, and preferably 11gR1.  You can currently upgrade to E-Business Suite Release 12 only if you are already running Database Version 10gR2 or 11gR1.

There are specific Notes for Oracle Applications users when upgrading the database:
The default method is to use the Database Upgrade Assistant (DBUA) to upgrade Oracle Applications databases.  The upgrade will invalidate a large number of objects in the database.  You need to decide whether you want DBUA to compile these automatically or whether you want to compile them manually later.  You can configure DBUA accordingly before starting the upgrade.  If you're currently on 10gR1 or an early release of 10gR2 then take the opportunity to upgrade to or 11gR1.

Install the Data Mining and OLAP options as instructed. This is a mandatory step, even if you're not using products that require those options.

Tip #9:  Monitor the Upgrade Driver

The main part of the upgrade to EBS is performed by the upgrade driver supplied in patch 3480000. This should complete without error -- no jobs should be skipped or ignored. If you find yourself having to skip jobs without a very good reason, this suggests something that should have been performed earlier has been omitted or has failed.  Skipping a job may have consequences for subsequent jobs as data or objects may be accessed by several workers during the upgrade driver.

Accept the default number of workers unless you have a good reason not to. Substantially increasing or decreasing the number of workers you use may affect the performance of the upgrade driver.  While it may be a worthwhile exercise to experiment with the number of workers you use, you should always use the default number as your benchmark for performance.

Tip #10: Rehearse Your Upgrade Process Thoroughly

As Support engineers, we generally advise performing a minimum of three test upgrades prior to performing a production upgrade. This means three complete upgrades from start to a successful conclusion. This iterative process allows you to find possible pitfalls during the production upgrade and have workarounds ready.  If you encounter issues during your production upgrade that were not encountered in testing then -- and I apologise for being blunt here -- you probably have not done enough testing. The production upgrade should mostly be a formality, not the most stressful phase of the whole project. 

We often talk to customers who encounter a series of errors during one of their test upgrades. For each error, a workaround is found and the test upgrade proceeds. The workaround may involve applying a patch that should have been applied earlier in the upgrade, perhaps resizing a tablespace during a patch, or changing a value in an initialisation file or something similar. These errors should be noted and then another test upgrade performed with these workarounds in place so the error no longer appears. There can come a point during a test upgrade where an error is encountered and several things are tried before the successful workaround is found.  If you find yourself in this position at several times within the same test upgrade, it is often advisable to start a new test upgrade and not continue with this test upgrade. This is because this particular test upgrade (usually very early in the project) is no longer representative of what you would actually do in your production upgrade, therefore invalidating your initial testing conditions.  As Oracle Support engineers, we don't advise this lightly. Sometimes the best advice is to give up and start again.

Because of the above, it's advisable that during each test upgrade, you backup the system at each major step in the upgrade.  If you then encounter a problem during an upgrade that results in your abandoning that particular step, you only need to revert back to the latest backup rather than rewinding to the start of the upgrade.

Rehearsing your upgrade also allows you to fine tune the process. Testing should give you the chance to record the whole upgrade with each step documented and timed. With this upgrade documentation you may see stages where, for example, you can merge patches into a single step. You can use adpatch command line parameters to avoid generating forms or reports in the middle of an upgrade that are perhaps going to be updated and compiled again further along in the same upgrade by another patch. Refinements like this will reduce the time of the overall upgrade. This refinement process is how you manage to turn your first test upgrade that might take two weeks into a production upgrade that you have to complete in 36 hours for example.   

All test upgrades should be performed on a very recent clone of your production environment.

Tip #11: Be Aware of Database Tuning Opportunities

We're sometimes asked whether fine tuning of database parameters or other components of the technology stack can enhance the performance of the upgrade. There are some pointers within the documentation suggesting when you can do this. I personally find that careful refinement and optimising of all the steps that you perform during the upgrade as a whole will reveal more opportunities to reduce the time the upgrade takes than specific database tuning. That said, it never hurts to look out for opportunities to optimise database performance.

Wrapping Up:  Upgrade Myths

So finally, here are the top 5 myths (from an Oracle Support perspective) about upgrading to E-Business Suite
Myth #1:  Shortcuts are safe

There are no safe shortcuts.  This upgrade can't be done by performing a fresh install of, linking this installation to your 11.5.x database and then applying the database portion of the Maintenance Pack. It's a nice idea, but it is a flawed strategy

Myth #2:  You can safely ignore adpatch worker failures

No, this is very dangerous.  It is not acceptable to skip worker failures in adpatch because the errors are in products you do not intend to use.

Myth #3:  You can export from an old database version to a higher one

It is (generally) not supported to upgrade an Applications database by exporting from one database version (8i for example) and importing into a fresh empty database of a later version.

Myth #4:  You can ignore unused products

It is not acceptable to ignore the installation of new products just because you do not intend to use those products. 

Myth #5: You can live without AutoConfig

AutoConfig must be implemented on the database tier -- this is mandatory and will improve your quality of life
Good luck with your upgrade!

Related Articles


Why is myth #1 a "flawed strategy"? It uses the same premise that is used in the below tip:

Install and run the Technology Stack Validation Utility. If this reports any errors then, instead of trying to address each issue individually, I'd encourage you to just go to Note 146468.1 and build new 8.0.6 and iAS ORACLE_HOMEs using the install media. This will save you time.

I understand the patch sync issues but is there another reason for the "flaws"?

Thanks! Look forward to seeing you at OOW.


Posted by John Stouffer on September 27, 2009 at 10:17 PM PDT #

Hi John

There are tables in the database which store information about files in the APPL_TOP (version information etc.) These tables are used during adpatch sessions to decide patch actions. If you build a fresh install, then attach an unrelated database, the tables and the APPL_TOP no longer match. It's unlikely you would be able to apply exactly the correct sequence of patches to bring the files in your APPL_TOP and the database tables into synch. again.

When you're replacing the 8.0.6 and iAS Oracle homes you do not have to worry about this synchronisation as the 8.0.6 and iAS Oracle homes are not maintained by adpatch.



Posted by Nick Quarmby on September 27, 2009 at 10:57 PM PDT #


Can we change the database characterset when upgrading


Posted by Farook on October 29, 2009 at 01:15 AM PDT #

Hi, Farook,

Yes, it's possible to do so. If you have any questions about the upgrade documentation that covers internationalization-related topics, your best bet would be to log a formal Service Request via My Oracle Support (formerly Metalink) to get one of our specialists engaged.

Please feel free to forward your Service Request number to me if it gets stuck in the support process for some reason.


Posted by Steven Chan on October 29, 2009 at 03:13 AM PDT #


I am Oracle Database DBA since long period and new to EBS. one of my client is having Oracle EBS 11.5.7 with DB on Redhat Linux 2.1.

I am in planing phase of EBS upgrade to i have gone through tme metalink # 316365.1. in this i am little bit confused in Section 4: Product-Specific Tasks

where it asked for product specific task. as per current setup only Finance and P-to-P is configured and running fine on production. please let me know do i need to complete activities for ofther products also or only for this 2 modules.



Posted by Hemendra Dhakaita on December 28, 2010 at 05:21 PM PST #

Hi Hemendra

Sorry for the delay in responding - I was away for an extended Xmas break.

In Section 4 of Note 316365.1 you only need to perform the product specific tasks for the products you have implemented/licenced on your system. NB - all products are installed but only the products you choose are implemented/licenced.

As an aside, I hope you're planning to upgrade your operating system. Note only the 32 bit version of Red Hat Linux is certified with 11i but you can upgrade to version 3, 4 or 5.



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

Post a Comment:
  • HTML Syntax: NOT allowed


« July 2016