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:
$APPL_TOP/admin/<SID>
$APPL_TOP/log
$APPL_TOP/patches
$COMMON_TOP/util/apache
$COMMON_TOP/admin/scripts
$COMMON_TOP/html/bin/appsweb.cfg
$COMMON_TOP/html/US/ICXINDEX.htm
$COMMON_TOP/html/_pages
$COMMON_TOP/html/iby_debug.log
$COMMON_TOP/html/iby_error.log
$FND_TOP/log
$FND_TOP/out
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.
Export example
$ 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.

ReferenceUsing
a Staged Applications System (APPL_TOP) to Reduce Patching Downtime in Oracle
E-Business Suite Release 12 (Doc ID 734025.1)
  • September 30, 2015 | 13 views