Reducing Patching Downtimes with Staged Applications Systems


It's axiomatic that everyone wants to minimize maintenance downtimes for their E-Business Suite environments. This is particularly crucial for environments with users in multiple timezones. I've previously summarized some of the most-effective ways of reducing patching downtimes for E-Business Suite environments. As noted in that article, one of the best ways of minimizing your maintenance downtimes is to use a staged Applications system.

The staged approach allows you to perform as many changes as possible in an offline Apps environment, and defers taking down your production environment only for the final database patches tasks. Using this approach, you apply your new patches to an exact clone of your production E-Business Suite environment. This can be done while your production system is still running. The staged Applications environment is then used to run database updates and APPL_TOP changes into your production environment.

Making It Painless

There are a few important things to remember when using a staged Applications system:

  1. The staged Applications system must be an exact duplicate of your production environment. For example, each physical APPL_TOP of your production system must exist in your staged system.
  2. Before copying the production Applications system, run the Maintain Current Snapshot task in AD Administration for each APPL_TOP. Having the snapshot of your Production Applications system current will ensure proper patch prerequisite checking when patches are applied.
  3. Take steps to avoid accidental changes to your production environment, such as ensuring that your staged environment's database has a different ORACLE_SID. You can also change passwords, ports, and other process or service-related parameters to insulate yourself further against a potentially embarrassing errors.

There are a number of other important steps for updating your production database and production APPL_TOP, as well as using the utility to synchronize your patch history between your staged and production environments. For full details, see the Metalink Note for your E-Business Suite release:

Commonly confused: "Staged" versus "Shared"

A final reminder about terminology might be helpful. Experienced Apps sysadmins know that we support staged application systems as well as shared application systems. Both of these maintenance strategies have the same goal: they help reduce your patching downtimes. However, it's important to remember that they're not the same thing:

  • Staged application systems allow you to do the bulk of your patching in an offline copy of your production environment.
  • Shared application systems allow you to patch a single application filesystem that's used by multiple application-tier servers.

Related Articles


Hi Steven,

Could you please clarify if there are any limitations on what patches could be staged together?

I'm following your advice to merge patches and save time:
Running staged upgrade from 11.5.9 to HR_PF.K

But I have found following Metalink note:
Subject: After Merging (3480000) and HR-PF.K (3500000) HR_UTILITY is Invalid
Doc ID: Note:338548.1

Here is the quote from that note:
Or a more correct solution: Perform the upgrade, THEN apply any family packs.
Yes, this takes a bit longer, but avoids many problems like this one.

Do you have any comments on that note?

And - thank you very much for frequent and very useful posts in your blog!

Best regards,

Posted by Leonid on September 01, 2008 at 07:35 PM PDT #

Hi, Leonid,

Hmm... this is a bit surprising. As far as I'm aware, ADMERGE should be able to handle merging scenarios like this.

I would recommend logging a formal Service Request for this against the AD Utilities, referencing Note 338548.1. If you email or post your SR number here, I'll ensure that this gets passed on to our AD Utilities team for their review.


Posted by Steven Chan on September 02, 2008 at 05:15 AM PDT #

Hi Steven,

I am a APPS DBA project lead from client side.

We recently began a project to upgrade from 11.5.9 to

We just completed creating a instance for SIT. It took us considerable amount of time.

Now we will begin 2nd iteration of upgrade from 23-Sept.

What is the time benchmark for upgrade from 11.5.9 to
Apps - 11.5.9 ->
DB - ->

For production cut-over we can only afford to keep system down for 4 days. That means DBAs need to complete their work 48-60 hrs.

I am considering stage application system to reduce total downtime. Will it reduce up-to 30-40?

I personally like to create my own bechmarks by doing it myself. But now I am in slightly different situation, where I need to convince vendor team to evaluate staged_application_system


Posted by Sharad Kowarkar on September 20, 2008 at 11:22 AM PDT #

"we can only afford to keep system down for 4 days"...Hmmm...thats not enough time to apply patches directly?

Posted by SR Tella on September 26, 2008 at 06:32 AM PDT #

Hi, Sharad,

It's a little hard to predict the total amount of time a staged filesystem approach will save you. I think the only way of accurately assessing the overall time savings will be to do a benchmark test against a clone of your production database.

Good luck with your upgrade.


Posted by Steven Chan on September 30, 2008 at 07:24 AM PDT #

Hi Steven:
We are in the process of creating our first R12 test instance upgrading from 11 5 9.
We noticed the Metalink Note 734025.1 (Using a Staged Applications System to Reduce Patching Downtime in Oracle Applications Release 12)... Has anyone tried this approach for R12 upgrade going from 11 5 9 ?
Is this the approach to follow to reduce the patching downtime ?

Appreciate your thoughts and comments.

- Dev

Posted by Dev Rangarajan on November 24, 2008 at 06:28 AM PST #

Hi, Dev,

I haven't heard of any customers using this technique for their 11i-to-R12 upgrades, but that doesn't mean much. I've passed your question on to the team that owns Note 734025.1. They'll either respond here, or I'll post their reply as soon as I hear from them.


Posted by Steven Chan on November 24, 2008 at 07:34 AM PST #

HI Steven:

Any update on my questions above relating to Doc 734025.1 ?
Please let me know.

- Dev Rangarajan

Posted by Dev Rangarajan on December 01, 2008 at 11:26 PM PST #


We haven't heard of anyone using this approach to streamline a R12 upgrade. Unless you really are the adventurous type and are willing to break new ground unassisted by Oracle, we would recommend against using this as part of an undocumented R12 upgrade technique.


Posted by Steven Chan on December 02, 2008 at 02:51 AM PST #


Based on your last reply to Dev, I understand that using Staged Applications System for an upgrade from 11i to R12 is not recommended by Oracle. Is that correct? Or did anything change in the past 15 months?


Posted by John on April 07, 2010 at 05:35 AM PDT #


My answer to Dev still applies today. We strongly recommend upgrading using the steps and strategy that we've documented in our official upgrade documentation.

If you improvise your own upgrade method and report issues that can't be reproduced in "plain-vanilla" Support environments, you will be advised to rebuild your environment from scratch using our certified and supported upgrade methods.

If I were a DBA considering the downsides of an unsupported and uncertified upgrade method, that would be the deal-killer for me. Whatever time you might have saved in taking a shortcut here or there would surely be lost several times over by the risk of having to rebuild your environment from scratch.


Posted by Steven Chan on April 07, 2010 at 09:12 AM PDT #

hi steve,

i need to upgrade my current application is R12 version 12.0.6 i want to switch to 12.1 so the stage method is preferable for this specific versions?pleas update me .
the Downtime is very important for me as we have 24/7 working Environment.

thnak you,

Posted by syed ahmed on May 10, 2010 at 04:56 PM PDT #

Hi, Syed,

Yes, you can use a staged APPL_TOP to upgrade from 12.0.6 to 12.1.1. You can use the generic R12 staged APPL_TOP documentation for that.


Posted by Steven Chan on May 11, 2010 at 02:41 AM PDT #

Hi Steve,

I have quick question on creating the staged appl_top.
Doc Id 734025.1 says, ◦Production and Staged systems should have the same APPL_TOP names -- May i know how it is possible?

And my second question is what is the exact meaning of below line.

each physical APPL_TOP of your production system must exist in your staged system.

Is that mean like prod and stage system shd remain in the same server.

Kindly clarify ny questions.


Posted by guest on January 15, 2013 at 05:37 AM PST #

Hi, Rajesh,

Your stage and prod environments can be on different physical servers.

The statement means that your staged system must have the same setup as your production system. You should not share filesystems between your stage and production systems.


Posted by Steven Chan on January 25, 2013 at 12:38 PM PST #

Hi Steve,
We are looking to implement this approach for patching our 12.1.3 production environment. Our production database is of 1.7TB size, my question is that can we archive large tables in the staged environment to keep the storage cost down. Have the staged database to a minimum ERP data level?

Thank you,

Posted by Faisal on September 26, 2013 at 08:47 AM PDT #

Hi, Faisal,

Yes, see this article for details:

New Whitepaper: Options for Reducing E-Business Suite Database Sizes (Oracle E-Business Suite Technology)


Posted by Steven Chan on September 27, 2013 at 11:21 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed


« July 2016