Staged Appl_Top to Reduce Patching Downtime in Oracle Applications Release 12

This document describes how to stage an Applications system to reduce patching downtime in Oracle Applications Release 12. You should read and understand all content described here before you begin using this feature.
The most current version of this document can be found in OracleMetaLink Note 734025.1.
There is a change log at the end of this document.

In This Document

This document contains the following sections:
• Section 1: Overview
• Section 2: Check Prerequisites
• Section 3: Applying Patches to the Staged System
• Section 4: Update the Production System
• Section 5: Synchronizing Patch Histories
• Section 6: Related Documentation
• Section 7: Terminology
Section 1: Overview
A staged Applications system represents an exact copy of your Production system, including all APPL_TOPs as well as a copy of the Production database. Patches are applied to this staged system, while your Production system remains up. When all patches have been successfully applied to the test system, the reduced downtime for the Production system can begin. The staged APPL_TOP is used both to run the database update into the Production database as well as synchronizing the production APPL_TOP.
The goal of this white paper is to document the recommended procedures on how a staged Applications system is created and utilized. Given the wide variety of hardware and architectures utilized by Oracle Applications customers, this document provides the important concepts to help implement the use of a staged Applications system in the patching of your Production Applications system.
Section 2: Check Prerequisites
1. Compare Topologies

A staged Applications system must duplicate the topology of your Production system. For example, each physical APPL_TOP of your Production system must exist in your staged system.
2. Verify Snapshot

Prior to copying the Production Applications system, ensure that the snapshot of the system is up-to-date. While the current snapshot should automatically be managed by AutoPatch, verification can be done by running the Maintain Current Snapshot task in AD Administration. This should be done for each APPL_TOP in your Applications system. Having the snapshot of your Production Applications system current will ensure proper patch prerequisite checking when patches are applied.
3. Create the Staged System

Create a clone of your Production database and of each APPL_TOP of your Production Applications system. Production and Staged should have the same APPL_TOP names, as this will ensure the patching history for your staged APPL_TOP will be correct in the Production system. Historical information is stored in the context of an APPL_TOP, and when patch history data is imported into Production it needs to have the same APPL_TOP names. The database of your staged APPL_TOP should have a different ORACLE_SID to avoid accidental connections to Production. Passwords, ports and any process or service related parameters may be changed as well to further reduce risks.

For more information on cloning Oracle Applications systems, refer to OracleMetaLink Note 406982.1.
Note: You must have different Applications system names for staged and Production. AutoPatch will correct the historical information. Your staged APPL_TOP name should be the same as your Production APPL_TOP name for the database driver to update the patch history information correctly.
Section 3: Apply Patches to the Staged System
The staged system is patched the same way as any Oracle Applications system using AutoPatch to apply the patch drivers. Refer to Oracle Applications Maintenance Utilities for more information on how to apply patches.
Note: While performing this step, no patches may be applied to the Production system. If they are, you will have to recreate your staged system.
Section 4: Update the Production System
1. Update the Production Database

Once patching the staged environment is complete, you are ready to update your Production system. Ensure you are able to connect to your Production database from your staged systems. You may need to create a tnsnames file in your staged system with entries for Production. You can use the s_ifile AutoConfig variable for this purpose. Refer to section 4 of OracleMetaLink Note 387859.1, Using AutoConfig to Manage System Configurations in Oracle E-Business Suite Release 12.

Once your environment is set correctly, and all services on the Production system have been disabled, run AutoPatch for the database portion of the patch you wish to apply, by specifying options=nocopyportion, nogenerateportion on the AutoPatch command line. Ensure the database name prompted by AutoPatch is correct.

If you applied multiple patches to the staged system, you will need to run the database update for each patch you applied to stage, in the same order. To reduce downtime further in such a case, you should consider merging patches prior to staging.
2. Update the Production APPL_TOP

The Production APPL_TOP needs to be synchronized with the staged APPL_TOP. To minimize downtime, you can complete this while the Production database is being updated. There are many ways to accomplish this task, ranging from a simple copy command to utilities such as rdist. Some storage providers offer hardware solutions as well. If your topology includes multiple APPL_TOPs, each APPL_TOP needs to be copied over to the Production system. If you share a single APPL_TOP, you only need to synchronize one system. The $COMMON_TOP directory, which on some systems may reside outside the APPL_TOP, also needs to be updated for each APPL_TOP in the Applications system.

Certain configuration files, log directories and environment scripts are specific to an APPL_TOP. These files and directories must be excluded when copying. (if using the rdist utility, you can use a distfile to exclude them)

Specifically, do not copy the following files and directories:
Note: If you have any additional custom directories or files, you will need to determine whether they should be copied.
Section 5: Synchronizing Patch Histories
The staged applications system strategy fragments your patch history. At this point in the process, the copy and generate portions of the patch history for patches applied using a staged applications system are stored in your staged database, and the database portion of the patch history for these patches is stored in both your staged database and in your production database. It is important that the patch history of your production system be complete. To accomplish this, you must now load the copy and generate portions of all patches applied using a staged applications system into your production database.
Use the utility located in the bin directory to export the patch history for the copy and generate portions of patches applied using a staged applications system from your staged database, then use AutoPatch to import the extracted patch history data into your production database. For each patch applied using a staged applications system, you must export patch history for each APPL_TOP in the staged applications system and import it for the corresponding APPL_TOP in the production applications system. Both exporting patch history data from the staged database and importing patch history data into the production database can be done with users on the production system. To ensure correct results, you should finish consolidating patch history for the production system before applying additional patches to it or using patch-related Oracle Applications Manager features on it.
Export Patch HistoryUse the utility. is located in the bin directory under AD_TOP. Enter -help to see all valid options for We recommend that you export patch history for each APPL_TOP separately, as you will need to import it for each APPL_TOP separately.
Ensure you specify nodatabaseportion=Y on the command line. This ensures that the patch history data for the database portion of patches applied against the staged applications system is not exported. This data should not be imported into the production database, because the database portion of each patch has already been applied directly to the production database.
Export example:
$ perl $AD_TOP/bin/ userid=apps/apps \
startdate=’2007/10/10 00:00:00′ enddate=’2007/14/10 00:00:00′ \
appsystemname=stage appltopname=tafnw1 nodatabaseportion=Y
This command will generate two data files for each run of AutoPatch on the staged APPL_TOP, one for java updates and one for all other patch actions. Check adphmigr.log to ensure the data files represent the patch runs you wish to export, and that the start and end times specified did not include any unwanted AutoPatch runs.
How to Import Patch HistoryYou should have extracted a separate set of data files for each APPL_TOP in your staged applications system. For each APPL_TOP in your production applications system, copy the data files extracted for the corresponding staged APPL_TOP to the $APPL_TOP/admin/ directory. AutoPatch will automatically upload these data files the next time it runs in this APPL_TOP. To load the data files immediately, start AutoPatch in interactive mode, answer the prompts until prompted for the name of the patch driver file, then exit AutoPatch by entering “abort” at the patch driver file prompt.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: