The Latest Oracle E-Business Suite Technology News direct from
Oracle E-Business Suite Development & Product Management

  • August 27, 2008

Reducing Patching Downtimes with Staged Applications Systems

Steven Chan
Senior Director

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 adphmigr.pl 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
. 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

Join the discussion

Comments ( 17 )
  • Leonid Tuesday, September 2, 2008

    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,


  • Steven Chan Tuesday, September 2, 2008

    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.



  • Sharad Kowarkar Saturday, September 20, 2008

    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



  • SR Tella Friday, September 26, 2008

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

  • Steven Chan Tuesday, September 30, 2008

    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.



  • Dev Rangarajan Monday, November 24, 2008

    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

  • Steven Chan Monday, November 24, 2008

    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.



  • Dev Rangarajan Tuesday, December 2, 2008

    HI Steven:

    Any update on my questions above relating to Doc 734025.1 ?

    Please let me know.


    - Dev Rangarajan

  • Steven Chan Tuesday, December 2, 2008


    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.



  • John Wednesday, April 7, 2010


    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?



  • Steven Chan Wednesday, April 7, 2010


    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.



  • syed ahmed Monday, May 10, 2010

    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,

  • Steven Chan Tuesday, May 11, 2010

    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.



  • guest Tuesday, January 15, 2013

    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.



  • Steven Chan Friday, January 25, 2013

    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.



  • Faisal Thursday, September 26, 2013

    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,


  • Steven Chan Friday, September 27, 2013

    Hi, Faisal,

    Yes, see this article for details:

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




Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.