Staged APPL_TOP in R12

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.

Pre steps
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.

. 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.
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.

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 Appendix C 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)

Post steps
1) 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 adphmigr.pl 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.

a) Export Patch History
Use the adphmigr.pl utility. adphmigr.pl is located in the bin directory under AD_TOP. Enter adphmigr.pl -help to see all valid options for adphmigr.pl. 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 adphmigr.pl 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/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 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.
b) Import Patch History
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/ 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.

----------------
Source:-http://appsoracle.blogspot.com/2011/07/staged-appltop-in-r12.html
----------------