DOYENSYS Knowledge Portal




We Welcome you to visit our DOYENSYS KNOWLEDGE PORTAL : Doyensys Knowledge Portal




Wednesday, September 30, 2015

Difference in location of Log files in Oracle EBS Release 12.1.3 and Oracle EBS Release 12.2.4

The Log files locations in Oracle EBS Release 12.1.3 and  Oracle EBS R 12.2.4  are given below:

1.Instance startup and configuration Log files are located for INST_TOP in Oracle Release 12.1.3 are below:

$INST_TOP/logs/appl/admin/log
Startup/Shutdown error message related to tech stack (10.1.2, 10.1.3 forms/reports/web)
$INST_TOP/logs/ora/ (10.1.2 & 10.1.3)
$INST_TOP/logs/ora/10.1.3/Apache/error_log[timestamp](Apache log files)
$INST_TOP/logs/ora/10.1.3/opmn/ (OC4J, oa*, opmn.log)
$INST_TOP/logs/ora/10.1.2/network/ (listener log)
$INST_TOP/apps/$CONTEXT_NAME/logs/appl/conc/log (CM log files)

2. Log files related to cloning in R12.1.3 are as below:

 Preclone log files in source instance
Database Tier – $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/(StageDBTier_MMDDHHMM.log)
Application Tier –
$INST_TOP/apps/$CONTEXT_NAME/admin/log/(StageAppsTier_MMDDHHMM.log)

Clone log files in target instance
Database Tier – $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ApplyDBTier_.log
Apps Tier – $INST_TOP/admin/log/ApplyAppsTier_.log

3. Patching related log files in R12.1.3 are as below:

i) Application Tier adpatch log – $APPL_TOP/admin/$SID/log/
ii) Developer (Developer/Forms & Reports 10.1.2) Patch – $ORACLE_HOME/.patch_storage
iii) Web Server (Apache) patch – $IAS_ORACLE_HOME/.patch_storage
iv) Database Tier opatch log – $ORACLE_HOME/.patch_storage


4. Autoconfig related log files in R12.1.3 are as below:

a) Database Tier Autoconfig log :
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/MMDDHHMM/adconfig.log
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/MMDDHHMM/NetServiceHandler.log


b) Application Tier Autoconfig log : 
$INST_TOP/apps/$CONTEXT_NAME/admin/log/$MMDDHHMM/adconfig.log

5.Autoconfig context file location in R12.1.3 :
$INST_TOP/apps/$CONTEXT_NAME/appl/admin/$CONTEXT_NAME.xml


6)R12.1.3 Installation Logs in R12.1.3 are as below:

 Database Tier Installation
RDBMS_ORACLE_HOME/appsutil/log/$CONTEXT_NAME/.log
RDBMS_ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ApplyDBTechStack_.log
RDBMS_ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ohclone.log
RDBMS_ORACLE_HOME/appsutil/log/$CONTEXT_NAME/make_.log
RDBMS_ORACLE_HOME/appsutil/log/$CONTEXT_NAME/installdbf.log
RDBMS_ORACLE_HOME/appsutil/log/$CONTEXT_NAME/adcrdb_.log RDBMS_ORACLE_HOME/appsutil/log/$CONTEXT_NAME/ApplyDatabase_.log
RDBMS_ORACLE_HOME/appsutil/log/$CONTEXT_NAME//adconfig.log
RDBMS_ORACLE_HOME/appsutil/log/$CONTEXT_NAME//NetServiceHandler.log
Application Tier Installation
$INST_TOP/logs/.log
$APPL_TOP/admin/$CONTEXT_NAME/log/ApplyAppsTechStack.log
$INST_TOP/logs/ora/10.1.2/install/make_.log
$INST_TOP/logs/ora/10.1.3/install/make_.log
$INST_TOP/admin/log/ApplyAppsTechStack.log
$INST_TOP/admin/log/ohclone.log
$APPL_TOP/admin/$CONTEXT_NAME/log/installAppl.log
$APPL_TOP/admin/$CONTEXT_NAME/log/ApplyAppltop_.log
$APPL_TOP/admin/$CONTEXT_NAME/log//adconfig.log
$APPL_TOP/admin/$CONTEXT_NAME/log//NetServiceHandler.log
Inventory Registration:
$Global Inventory/logs/cloneActions.log
$Global Inventory/logs/oraInstall.log
$Global Inventory/logs/silentInstall.log

7) Log files related with relink,Network,OUT inventory logs for R12.1.3 are as below:
 1) Database Tier
1.1) Relink Log files :
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME /MMDDHHMM/ make_$MMDDHHMM.log
1.2) Alert Log Files :
$ORACLE_HOME/admin/$CONTEXT_NAME/bdump/alert_$SID.log
1.3) Network Logs :
$ORACLE_HOME/network/admin/$SID.log
1.4) OUI Logs :
OUI Inventory Logs :
$ORACLE_HOME/admin/oui/$CONTEXT_NAME/oraInventory/logs
2) Application Tier
$ORACLE_HOME/j2ee/DevSuite/log
$ORACLE_HOME/opmn/logs
$ORACLE_HOME/network/logs
Tech Stack Patch 10.1.3 (Web/HTTP Server)
$IAS_ORACLE_HOME/j2ee/forms/logs
$IAS_ORACLE_HOME/j2ee/oafm/logs
$IAS_ORACLE_HOME/j2ee/oacore/logs
$IAS_ORACLE_HOME/opmn/logs
$IAS_ORACLE_HOME/network/log
$INST_TOP/logs/ora/10.1.2
$INST_TOP/logs/ora/10.1.3
$INST_TOP/logs/appl/conc/log
$INST_TOP/logs/appl/admin/log


In EBS R12.2.4 the log files locations are as below:

1)Log files file Online patching (adop) in EBS R12.2.4 are in below location:

The adop log files are located on the non-editioned file system (fs_ne), under:

$NE_BASE/EBSapps/log/adop/<adop_session_id>/<phase>_<date>_<time>/<context_name>/log

This log directory will contain patch logs,patch worker logs.

adop(phase=fs_clone) Online pathcing filesystem cloning process related log files are found under:

$INST_TOP/admin/log


2)Log files for Autoconfig process in Oracle EBS R12.2.4 are below:

On Applicaion Tier: $INST_TOP/admin/log/<MMDDhhmm>
On Database Tier: $ORACLE_HOME/appsutil/log/<CONTEXT_NAME>/<MMDDhhmm>

3)Log files for start/stop of services from $ADMIN_SCRIPTS_HOME

In below directory we will find log files related to start/stop process of oacore, forms, apache, opmn, 
weblogic admin server/node manager:

$LOG_HOME/appl/admin/log


4)Log/Out files for Concurrent programs/managers in Oracle R12.2.4 are in below location:

Log/Out files for Oracle Release 12.2 are stored in Non-Editioned filesystem(NE).

Log files: $APPLCSF/$APPLLOG (or $NE_BASE/inst/<CONTEXT_NAME>/logs/appl/conc/log)
Out files: $APPLCSF/$APPLOUT (or $NE_BASE/inst/<CONTEXT_NAME>/logs/appl/conc/out)


5)Log files for OPMN and OHS processes in Oracle R12.2.4 are in below location:

Below directory contains log files related OPMN process(opmn.log), 
OPMN Debug logs(debug.log), HTTP Transaction logs (access.log),security settings related logs.

$IAS_ORACLE_HOME/instances/<ohs_instance>/diagnostics/logs


6)Log file for Weblogic Node Manager in Oracle R12.2.4 are in below location:

Log file is generated by Node Manager and contains data for all domains that 
are controlled by Node Manager on a given physical machine.

$FMW_HOME/wlserver_10.3/common/nodemanager/nmHome1/nodemanager.log


7)Log file for Weblogic  in Oracle R12.2.4 for Oracle Management Service are below

Initial settings for AdminServer and Domain level information is written in this log file

$EBS_DOMAIN_HOME/sysman/log


8)Log files for server processes initiated through Weblogic in Oracle R12.2.4 are in below location:
Stdout and stderr messages generated by the forms, oafm and oacore services are located 
at NOTICE severity level or higher are written by Weblogic Node Manager to below directory.

$EBS_DOMAIN_HOME/servers/<server_name>/logs/<server_name>.out

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.

Reference - Using a Staged Applications System (APPL_TOP) to Reduce Patching Downtime in Oracle E-Business Suite Release 12 (Doc ID 734025.1)

Using Staged Applications System to reduce patching downtime in R12



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. Refer to My Oracle Support Knowledge Document 406982.1, Cloning Oracle Applications Release R12 with Rapid Clone, for details of the latest Rapid Clone patch for Release 12.

Create the Release 11i 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.

Upgrade the Staged System to Release 12.1.1

Upgrade the Staged Release 11i system to Release 12.1.1 by following Oracle E-Business Suite Upgrade Guide Release 11i to Release 12.1.1, and Oracle Applications Release Notes, Release 12.1.1
After upgrading the Staged system to Release 12.1.1, apply Patch 9794897:R12.AD.B to the Staged system.

1. Update the Production APPL_TOP

        1. Copy 12.1.1 APPL_TOP and application tier files from the Staged system to Production (This step can be done while the Release 11i Production system is running). Be sure to maintain the same directory structure of APPL_TOP and application tier on both the systems.
        2. Stop all services and enable Maintenance Mode on the Production system.
        3. On the new Release 12.1.1 Production APPL_TOP, run $COMMON_TOP/clone/bin/adclonectx.pl to generate a new context file for the Production instance, as outlined in My Oracle Support Knowledge Document 384248.1, Sharing The Application Tier File System in Oracle E-Business Suite Release 12, Appendix B, "Step 2: Create applications Context File and Instance Home". Follow the instructions on running the script.
        4. Regenerate the environment files by running AutoConfig, using the new context file on the new Production system Release 12.1.1 APPL_TOP.
        5. Re-source the environment to discard any remaining values set when the previous environment file was run.

2. Update the Production Database

         1. The database upgrade should be performed according to the instructions in Oracle E-Business Suite Upgrade Guide, Release 11i to Release 12.1.1.
         2. Once the database upgrade is complete, apply all the AD patches mentioned in the Upgrade Guide and release notes, in their entirety first, followed by database portion of all the patches that were applied on the Staged system. Use the AutoPatch option 'nocopyportion,nogenerateportion' on the Release 12.1.1 APPL_TOP of the Production system.
                   
 An example of using the adpatch command in this context is:
           $ adpatch options=nocopyportion,nogenerateportion driver=u_merged.drv

Start the services, disable Maintenance Mode using AD Administration, and check all is   running normally.
                   
 An example of the command to start the services is:
           $ $INST_TOP/admin/scripts/adstrtal.sh <APPSUSER>/<APPSPASSWORD>
                
         3. Synchronize the Patch Histories as mentioned below

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.

Reference - Using a Staged Applications System (APPL_TOP) to Reduce Patching Downtime in Oracle E-Business Suite Release 12 (Doc ID 734025.1)