Wednesday, September 30, 2015
Using Staged Applications System to reduce patching downtime during R12 Upgrade
Section 1: Overview
A Staged Applications system represents an exact copy of your Production system, including all APPL_TOPs and a copy of the Production database. Patches are applied to this Staged system, while your Production system remains operational. When all patches have been successfully applied to the Staged system, the reduced downtime for the Production system can begin. The Staged APPL_TOP is used to run the database update into the Production database, as well as synchronizing the Production APPL_TOP.
This document describes the recommended procedure by which a Staged Applications system can be created and deployed across the wide variety of hardware and architectures utilized by Oracle E-Business Suite customers. It also describes how the procedure can be used to upgrade from Oracle E-Business Suite Release 11i to Release 12.
Section 2: Check Prerequisites
1. Apply the latest AutoConfig template patch on the source system
Update the Oracle Applications file system with the latest AutoConfig template files by applying the TXK AutoConfig Template rollup patch to all application tier server nodes.
2. Apply the latest Rapid Clone patch on the source system
Update the Oracle Applications file system with the latest Rapid Clone patches posted in the Rapid Clone Documentation.
3. 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.
4. 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.
5. Create the Staged System
Create a clone of your Production database and of each APPL_TOP of your Production Applications system.
Key points to observe:
* Production and Staged systems 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.
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.
Note: While performing this step, no patches may be applied to the Production system. If they are, you must 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.ora file in your Staged system with entries for Production. You can use the s_ifile AutoConfig variable for this purpose.
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. Do this 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 the Staged system, in the same order. To reduce downtime further in such a case, 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 cp command to more specialized 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.
Note: The context file will need to be regenerated using AutoConfig on each of the existing APPL_TOP.
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 if they exist in your environment:
Note: If you have any additional custom directories or files, you will need to determine whether they should be copied.
Section 5: Synchronize Patch Histories
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 the patch history for each APPL_TOP in the Staged Applications system, and import it for the corresponding APPL_TOP in the Production Applications system.
Export Patch History
Use the adphmigr.pl utility, located in the bin directory under AD_TOP. You can enter adphmigr.pl -help to see all valid options for the utility.
Note: Patch history should be exported for each APPL_TOP separately, as you will need to import it for each APPL_TOP separately.
Ensure you specify nodatabaseportion=Y on the adphmigr.pl command line.
$ perl $AD_TOP/bin/adphmigr.pl 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 (javaupdates<TIMESPAMP>.txt), and one for all other patch actions (adpsv<TIMESPAMP>.txt).
Check the adphmigr.log file to ensure that 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.
Import Patch History
By now, you 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/<DB NAME> 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.
Reference - Using a Staged Applications System (APPL_TOP) to Reduce Patching Downtime in Oracle E-Business Suite Release 12 (Doc ID 734025.1)