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:
- 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.
- 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.
- 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:
- Using a Staged Applications System to Reduce Patching Downtime [in Oracle Applications Release 11i] (Metalink Note 242480.1)
- Using a Staged Applications System to Reduce Patching Downtime in Oracle Applications Release 12 (Metalink Note 734025.1)
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
Comments (9)
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 11.5.10.2+ HR_PF.K
But I have found following Metalink note:
------------------------------------
Subject: After Merging 11.5.10.2 (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,
Leonid
Posted by Leonid | September 2, 2008 2:35 AM
Posted on September 2, 2008 02:35
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.
Regards,
Steven
Posted by Steven Chan | September 2, 2008 12:15 PM
Posted on September 2, 2008 12:15
Hi Steven,
I am a APPS DBA project lead from client side.
We recently began a project to upgrade from 11.5.9 to 11.5.10.2.
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 11.5.10.2.
============================
Apps - 11.5.9 -> 11.5.10.2
DB - 9.2.0.8 -> 10.2.0.3
============================
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
Regards
Sharad
Posted by Sharad Kowarkar | September 20, 2008 6:22 PM
Posted on September 20, 2008 18:22
"we can only afford to keep system down for 4 days"...Hmmm...thats not enough time to apply patches directly?
Posted by SR Tella | September 26, 2008 1:32 PM
Posted on September 26, 2008 13:32
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.
Regards,
Steven
Posted by Steven Chan | September 30, 2008 2:24 PM
Posted on September 30, 2008 14:24
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.
Regards.
- Dev
Posted by Dev Rangarajan | November 24, 2008 2:28 PM
Posted on November 24, 2008 14:28
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.
Regards,
Steven
Posted by Steven Chan | November 24, 2008 3:34 PM
Posted on November 24, 2008 15:34
HI Steven:
Any update on my questions above relating to Doc 734025.1 ?
Please let me know.
Regards
- Dev Rangarajan
Posted by Dev Rangarajan | December 2, 2008 7:26 AM
Posted on December 2, 2008 07:26
Dev,
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.
Regards,
Steven
Posted by Steven Chan | December 2, 2008 10:51 AM
Posted on December 2, 2008 10:51