Reducing Patching Downtimes for Apps

Reducing Patching Downtimes for Apps

How to reduce patching downtime in oracle apps??
One of the most commonly-cited reasons for not patching E-Business Suite environments is that it takes too much downtime.  If you’re relatively new to Apps system administration, here’s a primer on the key techniques compiled by our Applications Release Engineering group for reducing patching downtimes.  Although some of the linked documents are …written specifically for Release 11i, these techniques may be used for both Apps 11i and 12.

1. Use a staged applications system.  This major time-saver hinges on a key principle:  all of your applications filesystem patches are applied to aclone of your production Apps environment.  This can be done while your production system is still running.  Your production system is down only for the time needed to apply database patches.  For details, see:
2. • Using a Staged Applications System to Reduce Patching Downtime [Release 11i] (Note 242480.1)
   • Using a Staged Applications System to Reduce Patching Downtime in Oracle E-Business Suite Release 12 (Note 734025.1)
3. Use a shared application-tier file system.  If you have a pool of application-tier servers set up for load-balancing, make sure that all of the individual servers share a single application filesystem.  Patches applied to this central shared filesystem are instantly available to all application-tier servers.  I’ve previously given an overview of this technique in this article.
4. Distribute worker processes across multiple servers.  When applying a patch that includes a large number of processes, you can reduce the downtime even further by distributing the worker processes across multiple servers on multiple nodes. Using the Distributed AD feature of AutoPatch and AD Controller, you can assign workers to run on the primary node and on other nodes that share the filesystem. See:  Distributed AD (Metalink Note 236469.1)
5. Merge multiple patches using AD Merge Patch.  Merging patches saves time because the AutoPatch overhead of starting a new session is eliminated for those patches that are consolidated.  Duplicate linking, generating or database actions are run once only.  If two patches update the same file, AD Merge Patch will save time by applying only the latest one.  Patches can — and should — be merged with their listed prerequisite patches.For more details about this AD utility, see the Oracle Applications Maintenance Procedures guide for your Apps release.
6. Run AD Patch in non-interactive mode .  Applying a set of patches using AD Patch in non-interactive mode eliminates the delay between successive tasks.
7. Defer system-wide database tasks until the end.  Using adpatch options=nocompiledb,nomaintainmrc defers system-wide database tasks such as “Compile APPS schema” and “Maintain MRC” until after all patches have been applied.  As of AD.H, AutoPatch automatically compiles the APPS schema and maintains MRC when applying standard patches.
8. Avoid resource-related bottlenecks.  Patching can grind to a halt if you bump into the ceiling on your system.  Before patching, make sure that you’ve enabled automatic tablespace management, and that you have sufficient hardware and free disk and temp space.

The cumulative downtime reductions of all of these techniques can be quite significant.  I’ve touched on some of the biggest timesavers, but this short article isn’t comprehensive, by any means.  The linked Notes in this article and below discuss a number of other tips for shrinking your patching downtimes.  A small investment in learning these techniques can pay off in large reductions in patching times, and is well worth your time.