Oracle Technologies Blog

By ASKM

Archive for the ‘Oracle Apps R12’ Category

R12 Patching Enhancement

Posted by Srikrishna Murthy Annam on October 16, 2009

R12 Patching Enhancement:

Patching R12 Application Oracle Homes

  1. Opatch is used to apply patches to the 10.1.3 and 10.1.2 Oracle Homes.
  2. Requires access to the Oracle Homes inventory
  3. List of patches already applied through  Ex : Opatch lsinventory – detail

Application Patching Enhancements

  1. Codelines(12.0:A, 12.1:B) and Codelevels(R12.AD.A.1, R12.AD.A.2)
  2. Patch prereq checking: only require a codelevel as a prerequisite
  3. Registering flagged files to understand a patch’s impact on customizations
  • Replaces the applcust.txt file in 11i
  • Customized files are now maintained in database format
  • Display flagged files affected by a patch through impact analysis

Patch Application Assistant (admsi.pl)

  1. PAA (Patch Application Assistant) is tool/Perl script to generate customized installation instructions for a patch in Oracle Applications R12 which helps user to track and perform manual steps during patching.
  2. cd $AD_TOP/bin ; perl admsi.pl -patch_top=<patch-top-directory> -appspass=<apps-password>

Patch Wizard functionality improvement

Easy to identify applied patch, file history and patch timing and action summary
Screen Shots :

Code Level and CodeLine :

code level

Codeline and codelevel

Patch Wizard :

patch wizard

Applied Patches :

Applied Patches

Register Flagged Patches :

Register Flagged Files

Patch Impact Analysis Summary :

Patch Impact Analysis Summary

Posted in Oracle Apps R12 | Leave a Comment »

R12 – Codelines , Codelevels and Types of Patches

Posted by Srikrishna Murthy Annam on October 16, 2009

R12 – Codelines , Codelevels and Types of Patches:

Types of Application Patches :

There are several different types of Oracle Applications patches. These are the more common patches:
One-off patch: This is the simplest type of patch. It is created to resolve a specific bug.
Minipack patch: This is a collection of one-off patches and enhancements related to a particular module. Alphabetic characters denote the Minipack version for the module; for example, the product code for the Application DBA utilities is AD, and version Minipack I of this product would be called AD.I.
Family Pack patch: This is a collection of Minipack patches for a particular family group of application modules. Alphabetic characters denote the Family Pack version; for example, the J version of the Human Resources Suite Product Family would be HR_PF.J.
Maintenance Pack patch: This is a collection of Family Packs that serves as a point-level release upgrade; Oracle Applications Release 11.5.10 is an example of a Maintenance Pack.

There are also other special types of patches:
Consolidated patch: This is a collection of one-off fixes for a Family Pack or Maintenance Pack; Oracle Applications 11.5.10 Consolidated Update 2 (CU2) is an example of a consolidated patch.
Interoperability patch: This is a patch that is required for Oracle Applications to function with a newer version of a technology stack component; for example, you would apply an interoperability patch when upgrading the database to version 10g.
NLS patch: This is a patch that updates language-specific information for multi-language installations.
Rollup patch: This is a collection of one-off patches that update code levels for particular products.
Legislative patch: This is a special patch for HR Payroll customers; it contains legislative data for multiple countries.

As the patch group size increases from one-off patches to Maintenance Packs, the complexity of the patch application process also increases. More research is required for Family Packs than is required for a Minipack. Due to the increased complexity, there is more planning required for Maintenance Packs and Family Packs than other patches.

Codelines(12.0:A, 12.1:B)
In release 12, Oracle Applications introduces codelines and codelevels to ease tracking of patch prerequisites, dependencies, and compatibilities. Patches are associated with a codeline, which not only identifies the set of product features, but also the order of the various patches released to provide fixes to that set of features.
A codeline begins with a base point that consists of a unique set of product features, and progresses to include all the patches created to provide fixes to that base point. For example, Oracle Financials and Oracle Human Resources are active in your system.
The initial set of features or base point of Oracle Financials and Oracle Human Resources are FIN.A and HR.A, respectively. When fixes are required for the base point, a patch (or a set of patches) is released, and the order in which the patch created is indicated by a number appended to the base point. Each new patch is called a codelevel. For example, codelevel FIN.A.1 is the first set of fixes to base point, FIN.A, and FIN.A.2 is the second set of fixes, and so on.

Codelevels(R12.AD.A.1, R12.AD.A.2)
Codelevels are cumulative — each one contains the initial set of features plus all the fixes created to date (except those replaced by subsequent patches) for that product family.
Some patches may contain new features. These patches create new base points or start new codelines. For example, when Oracle Financials releases new features in a patch (instead of being part of a complete upgrade of Oracle Applications), the patch starts a new codeline, FIN.B. Then, the subsequent release of patches (or codelevels) with fixes to the expanded set of features are named accordingly: FIN.B.1, FIN.B.2, FIN.B.3, and so on.
As a user, you can choose to accept a patch to fix your existing codeline or you can accept a patch on a more recent codeline, which will not only provide fixes to your products, but will also add feature enhancements to your system.

What is pre-requisite patch ?
A prerequisite patch fulfills a dependency for another patch.  In Release 12, only codelevels can be prereq patches. Strictly speaking, they are co-requisites and can be applied in any order before using the system. We recommend that you merge a patch with its required prerequisites, with the exception of prerequisite patches for the AD product.

Oracle Patch Application Assistant (PAA) helps you track and perform manual steps during patching.

How do I determine what baseline I’m on ?
Following select will tell you the R12 version:
SQL>select ‘RELEASE ‘||RELEASE_NAME from APPLSYS.FND_PRODUCT_GROUPS;

Following select will tell you the products and their corresponding baselines:
SQL>set pages 999
SQL>set long 9999
SQL>column BASELINE format a8
SQL>break on baseline
SQL>select BASELINE,upper(abbreviation),name from AD_TRACKABLE_ENTITIES order by baseline,abbreviation;

.

Posted in Oracle Apps R12 | 1 Comment »

R12 – PAA ( Patch Application Assistant )

Posted by Srikrishna Murthy Annam on October 16, 2009

R12 – PAA  ( Patch Application Assistant ):

Patch Application Assistant (admsi.pl)
PAA (Patch Application Assistant) is tool/Perl script to generate customized installation instructions for a patch in Oracle Applications R12 which helps user to track and perform manual steps during patching.

- Oracle Patch Application Assistant (PAA) helps you track and perform manual steps during patching
- For patches with manual steps, PAA generates a customized set of instructions specific to your installation and displays the relevant manual steps
- For merged patches, PAA automatically merges the contents of the individual patch readme files.
- If you need to use PAA, the patch readme will ask you to run admsi.pl

This utility can be run in either CLI mode or GUI mode

Run the admsi.pl script to generate customized installation instructions for applying the patch. You will need to provide the location of your patch top directory and the applmgr password.

$ cd $AD_TOP/bin
$ perl admsi.pl -patch_top=<patch-top-directory> -appspass=<apps-password>
For details, run “perl admsi.pl –help”

The steps are contained in the customized installation instructions generated by the admsi.pl script. Additional steps are also detailed in the customized installation instructions depending on the patch, the state of your system, and the products you have installed.

Posted in Oracle Apps R12 | Leave a Comment »

Important tables for ADPATCH

Posted by Srikrishna Murthy Annam on October 14, 2009

Important Tables For ADPATCH :

AD_APPL_TOPS
AD_APPLIED_PATCHES
AD_BUGS
AD_PATCH_DRIVERS
AD_FILE_VERSIONS
AD_FILES
AD_PATCH_DRIVER_LANGS
AD_PATCH_DRIVER_MINIPKS
AD_PATCH_RUN_BUG_ACTIONS
AD_PATCH_RUN_BUGS
AD_PATCH_RUNS
AD_RELEASES
AD_PATCH_COMMON_ACTIONS

Posted in Oracle Apps R12 | Leave a Comment »

Applying hrglobal driver

Posted by Srikrishna Murthy Annam on October 14, 2009

Applying hrglobal  driver:

Ref Notes :   796167.1  and  140511.1

Check Note 145837.1 “Latest HRMS (HR Global) Legislative Data Patch Available” to determine which legislative patches are needed.
Run datainstall utility to determine which legislations are installed
$AFJVAPRG oracle.apps.per.DataInstall apps <apps passwd> thin <db server>:<listener port>:<SID>
Select option 1. This will show you which language legislations are currently installed. Use this list to determine which legislation patches are required according to the note above.
To exit the application, type <return>, select option 4, and choose ‘N’.
Apply all recommended LEGISLATIVE PATCHES (NLS: Required if applicable)

Run datainstall utility
$AFJVAPRG oracle.apps.per.DataInstall apps <apps passwd> thin <db server>:<listener port>:<SID>
Choose to FORCE install already installed legislations

Apply $PER_TOP/patch/115/driver/hrglobal.drv – using adpatch

adpatch defaultsfile=$APPL_TOP/admin/<SID>/onlinedef.txt \
patchtop=$PER_TOP/patch/115/driver  \
logfile=HRGLOBAL.log driver=hrglobal.drv \
workers=24  \
flags=hidepw

Country codes
==========

http://www.theodora.com/country_digraphs.html

SELECT DECODE(hli.legislation_code
,null,’Global’
,hli.legislation_code)                legCode
, hli.application_short_name                  asn
, hli.status status, last_update_date
FROM hr_legislation_installations hli
where hli.status = ‘I’;

Posted in Oracle Apps R12 | Leave a Comment »

Explaining Patch c,d,g and Unified Driver

Posted by Srikrishna Murthy Annam on October 14, 2009

Explaining Patch c,d,g and Unified Driver:

The unzipped patch contains three  drivers “c,d,g” or “u”. These are called copy,database,generate drivers or Unified drivers. The unified driver is the combination of all the three c,d,g drivers.

Now we will see these drivers one by one ….

Copy Driver : (cXXXXX.drv )
– Copies all files to the appropriate directory ( ex:  .fmb , .pll files)
– Relinks executable

Ex :
copy    ap     forms/US      APXIISIM.fmb     110.8
Driver will check the versions of APXIISIM.fmb on your system. If it is less than 110.8, then it will copy this file to the $AU_TOP/forms/US directory.

copy    ap     patch/110/sql apaiithb.pls     110.2
Driver will check the versions of apaiithb.pls on your system. If it is less than 110.2, then it will copy this file to the $AP_TOP/patch/110/sql directory.

copy    fnd    resource      JE.pll           110.8
Driver will check the versions of JE.pll on your system. If it is less than 110.8, then it will copy this file to the $AU_TOP/resource directory.

Database Driver : ( dXXXXXX.drv )
This is the driver that runs .sql, .pls, .odf and other files that update the database. As mentioned previously, some common ways the database is updated by the this driver are:
– Create packages
– Create new error messages
– Add a new table or view to the database
– Add a new column to a table
– Add new seed data to a table

The database driver uses the same command structure:
<command>  <product>  <subdirectory>  <file>  <other arguments….>
However, as you will see, it uses the <other arguments> section much more. There are numerous different arguments that can be used, but following are some more common examples:
- sql Run the script directly from the worker
- sqlplus Spawn a new sqlplus session and run the script
- package Same as sqlplus but performs package version checking

Another argument you may see at the end of the command string is a ‘phase=’’ command. Before performing any actions, adpatch divides all actions contained in the patch driver file into phases based on information specified in the patch driver. Adpatch performs all actions grouped in one phase in parallel before proceeding to the next.
Many ‘d’ drivers in patches contain phase definitions that determine what order the files in the driver will
run. If the driver does not contain any phase definitions, then the files are executed in the order they appear in the driver.
There are currently around 19 different phases that can be defined, but some examples are:
Phase name      Action taken
seq             Create sequences
tab             Create tables and indexes
pls             Create package specifications (specs)
vw              Create Views
plb             Create package bodies

Following are some examples of common commands found in a dXXXXXX.drv driver, and a brief explanation.
sql  ar   patchsc/107/sql b512706a.sql  !AR_PERIOD_TYPES  &un_ar  &pw_ar sql  &phase=tab
Run the sql script $AR_TOP/patchsc/107/sql/b512706a.sql using the ar username and password. The !AR_PERIOD_TYPES is another parameter expected by the .sql script. As discussed previously the &phase argument specifies what type of action this script is doing, in this case creating a table, and when the script will be executed by the driver.

sql  ar   patchsc/107/sql    ARTEHPCS.pls    none none none package &phase=pls
Run the script $AR_TOP/patchsc/107/sql/ARTEHPCS.pls which creates a package (phase=pls).

sql ar patchsc/107/sql artcall5.sql none none none sqlplus &phase=tbm+5 &un_ar &pw_ar
Run the script $AR_TOP/patchsc/107/sql/artcall5.sql. The phase ‘tbm’ tells you that it is altering a table.
The +5 is a way of determining the order a script will run within a phase. For example, within a phase, commands would be run in the following order:
&phase=tbm
&phase=tbm+5
&phase=tbm+99

Generate Driver : (gXXXXXX.drv )
Following are some examples of commands in a ‘g’ driver. Once again, remember that
– The .fmb files are stored in $AU_TOP, and when generated the executable (.fmx) is stored under the product.
– The .pll is stored under $AU_TOP, and when generated the executable (.plx) is also stored under $AU_TOP.
genform    ap     forms/US     APXIISIM.fmb
Generate the form $AU_TOP/forms/US/APXIISIM.fmb and store the executable in $AP_TOP/forms/US/APXIISIM.fmx
genrep     ap     reports      APXIIADV.rdf
Generate the report $AP_TOP/reports/APXIIADV.rdf, and store the resulting file APXIIADV.rdf in the same directory.
genfpll    fnd    resource     JE.pll
Generate the PL/SQL library $AU_TOP/resource/JE.pll, and store the executable JE.plx in $AU_TOP/resource.

Unified Driver : ( uXXXXXXX.drv )
The u driver is a merged driver that is a combined c, d, and/or g driver. Oracle is beginning to release a majority of its patches as unified driver patches. If a patch is a unified driver patch, then only the u driver is applied.

Posted in Oracle Apps R12 | Tagged: , , , , , | Leave a Comment »

Applying Applications Patch Using adpatch

Posted by Srikrishna Murthy Annam on October 14, 2009

Applying Applications Patch Using adpatch:

Adpatch is a utility we use to apply application patches.Patches are used either to fix some issue or to intoroduce a new feature. There are different types of patches and we can explain different types of patches in some other article. Let us know focus on how to apply the patch to applications.

Following are the basic steps we follow to apply the patch

1) prepatch analysis
2) pre health checks
3) shutdown MT services
4) Enable Maintenance mode
5) Apply patch using adpatch
6) Disable Maintenance mode
7) Start all MT services
8 ) Perform any post patch steps
9) Post health checks

Prepatch analysis :
First download correct patch for your platform to local machine and unzip the patch. Review the readme file provided with patch and check that all the pre-requisite patches are applied to the system. If there is any pre-required patches to be applied , we will list those patches also to apply to the system. And finally we come to the conclusion with the list of all the patches to be applied.

Pre health checks :
It is important to do pre-health checks to cross verify the impact of patch comparing the post health checks with pre health checks.
Check the status of the following components on all MT nodes :
- Conc Manager status
- Forms status
- URLs check
- Opmn Processes status
- MWA status if configured
- Discoverer status
- Record invalids
- Record workflow status
- Check if there are any NLS Lang available for the patch

Use the following queries …

SQL> create table apps.invalids_askm_bak tablespace bkpd as (select owner,object_name,object_type from dba_objects where status=’INVALID’);
SQL> select fsc.COMPONENT_NAME,fsc.STARTUP_MODE,fsc.COMPONENT_STATUS from APPS.FND_CONCURRENT_QUEUES_VL fcq, fnd_svc_components fsc where fsc.concurrent_queue_id = fcq.concurrent_queue_id(+) order by COMPONENT_STATUS , STARTUP_MODE , COMPONENT_NAME;
SQL> select nls_language, language_code, installed_flag from apps.fnd_languages where installed_flag in (‘I’,’B’);
SQL> select * from apps.ad_bugs where bug_number=’&bug’;

Shutdown MT services :
Use the adstpall.sh script to stop all MT services. Wait for some time to make sure that all the processes are down. Kill if there are any defunct processes and runaway processes.

Enable Maintenance mode :

SQL> @$AD_TOP/patch/115/sql/adsetmmd.sql ENABLE
SQL> select fnd_profile.value(‘APPS_MAINTENANCE_MODE’) from dual; –> to check

Apply patch using adpatch:
Now upload the patch zip file to any temporary directory and unzip the patch. Move into the unzipped directory. And then apply the patch …

adpatch defaultsfile=$APPL_TOP/admin/$TWO_TASK/default.txt logfile=patch.log \
patchtop=$APPL_TOP/patches/xxxxxxx options=noautoconfig,nocompilejsp,nocompiledb workers=8 \
driver=xxxxxxxx.drv

Answer to the prompts given by the adpatch and wait till you get the message that “autopatch is complete”. Then review the log files to check if there are any error in the logfiles. Logfiles are located in  $APPL_TOP/admin/<SID>/log.
Apply NLS patches if any in the same way.

Disable Maintenance mode :

SQL> @$AD_TOP/patch/115/sql/adsetmmd.sql DISABLE
SQL> select fnd_profile.value(‘APPS_MAINTENANCE_MODE’) from dual; –> to check

Start all MT services :

Start all the MT services using adstrtal.sh script.

Perform any post patch steps :
Patch readme file contains the details if there are any post patch steps to be performed. Complete all the post patch steps.

Post health checks :
Perform all the post health checks and compare it with pre patch health checks. Compile new invalids if any. Contact Oracle Support if you have any problem in applying the patch and provide all the patch logfiles to the support.

Posted in Oracle Apps R12 | Leave a Comment »

Do we have mod_plsql,jserv,reports server in R12 ?

Posted by Srikrishna Murthy Annam on October 13, 2009

Do we have mod_plsql,jserv,reports server in R12 ?

mod_plsql :

Mod_plsql is an Apache web server extension that can be used to develop web application pages using Server PL/SQL.
Unlike Oracle E-Business Suite Release 11i, Release 12 does not include mod_plsql as part of its technology stack.
Modplsql component of Apache is removed in R12 .you have to see the alternate for custom developed programs which will be using this.
If you have developed mod_plsql extensions to Oracle E-Business Suite Release 11i, and are considering upgrading to Release 12, you will have to take some action to preserve that functionality.
mod_plsql is replaced by Oracle Application Framework in R12. The reasong for replacing the mod_plsql with Oracle Application Framework in R12 is that , mod_plsql does not provide solutions for a number of important problems that must be solved in a robust and secure web application.

The following components/modules were removed from Release 12
1. mod_plsql
2. Oracle Reports Server
3. Oracle Graphics Integration with Oracle Forms
4. Oracle Applications Framework pages in the AK Repository (AK mode)

JServ :

OC4J replaces the Jserv component which is there in the current release 11i of Oracle Applications. Also as a result the mod_jserv component would be replaced by the mod_oc4j component in release 12 of Oracle Applications. The mod_oc4j is used to communicate between different OC4J instances.

The default installation Release 12 of Oracle Applications creates 3 OC4J instances

– Oacore: This runs the OA Framework -based applications.
– Forms: This runs the Forms-based applications.
– OAFM: This is responsible for running the web services.

The Jserv groups which are there current in Oracle Applications Release 11i are also planned be replaced by OC4J instances.

As mentioned earlier the OC4J properties are controlled using the XML files and OC4J.properties file. These files are managed by the standard Oracle Applications Autoconfig.

The Java code deployment in Oracle E-Business suite for OC4J is done at the time of install using rapid install and maintained by ad tools like adadmin and adpatch. New custom code deployment can be done by using the Application Server Control user interface.

The OC4J implementation In Oracle Applications Release 12 includes the following directory structure.

– applications: Contains applications deployed
– applications-deployment: Contains configuration settings for the applications deployed
– config: Contains common configuration setting for the OC4J instance.

Remember there are no jserv.properties or jserv.conf or zone.properties in R12 (new techstack), Jserv is replaced by Oacore.

Finally …
- Jserv component is removed and it is replaced in R12 by OC4J(oacore)
- mod_plsql is replaced by Oracle Application Framework
- The reports server has been removed in R12 and it runs as a spawned process called rwrun which is spawned by conc manager.

Ref Note : 726711.1

Posted in Oracle Apps R12 | Tagged: , , , , , , , , , | 1 Comment »

Killing runaway processes after terminating concurrent Request

Posted by Srikrishna Murthy Annam on October 13, 2009

Killing runaway processes after terminating concurrent Request:

Every concurrent Request uses some resources for running. If you feel that the concurrent request is taking long time and decided to terminate the concurrent request , the resources may not be released soon. These processes are called runaway processes. So we need to manually kill the processes at database and os level to have the resources released to the system.

Terminate the concurrent request from the front end. Then …
SQL>select request_id,oracle_process_id,os_process_id from fnd_concurrent_requests where request_id=’&Req_Id’;

SQL>select p.spid , s.sid , s.serial# from v$session s , v$process p where s.paddr = p.addr and s.process = &os_process_id ;

SQL> alter system kill session ‘session-id,session-serial’

$ kill -9 <server pid>

Complete details about the request can be found using the following query :

SELECT qt.user_concurrent_queue_name
, fcr.Request_Id Request_id
, fu.User_name
, p.spid
, s.sid ||’, ‘|| s.serial# SIDSERIAL
, substr( Fcpv.Concurrent_Program_Name ||’ – ‘|| Fcpv.User_Concurrent_Program_Name, 1,46) Program
, to_char( fcr.actual_start_date, ‘mm/dd hh24:mi’ ) actual_start_date
, phase_code, status_code
, to_char( trunc(sysdate) + ( sysdate – fcr.actual_start_date )
, ‘hh24:mi:ss’ ) duration
FROM apps.Fnd_Concurrent_Queues Fcq
, apps.fnd_concurrent_queues_tl qt
, apps.Fnd_Concurrent_Requests Fcr
, apps.Fnd_Concurrent_Programs Fcp
, apps.Fnd_User Fu
, apps.Fnd_Concurrent_Processes Fpro
, v$session s
, v$process p
, apps.Fnd_Concurrent_Programs_Vl Fcpv
WHERE phase_code = ‘C’
AND status_Code = ‘X’
AND s.paddr = p.addr
AND fcr.requested_by = user_id
AND fcq.application_id = qt.application_id
AND fcq.concurrent_queue_id = qt.concurrent_queue_id
AND userenv(’lang’) = qt.language
AND fcr.os_process_id = s.process
AND fcr.Controlling_Manager = Concurrent_Process_Id
AND (fcq.concurrent_queue_id = fpro.concurrent_queue_id
AND fcq.application_id = fpro.queue_application_id )
AND (fcr.concurrent_program_id = fcp.concurrent_program_id
AND fcr.program_application_id = fcp.application_id )
AND (fcr.concurrent_program_id = fcpv.concurrent_program_id
AND fcr.program_application_id = fcpv.application_id )
ORDER BY fcr.actual_start_date;

Posted in Applications Scripts, Oracle Apps R12 | 2 Comments »

R12 – How to deploy form on a server

Posted by Srikrishna Murthy Annam on October 12, 2009

R12 – How to deploy form on a server:

We use f60gen in R11i for deploying forms , but f60gen is deprecated in R12. We use frmcmp_batch.sh for forms compilation in R12.

Steps
=====
1) Backup the existing form in location $AU_TOP/forms/US
2) Copy the new form ( *.fmb ) to the location $AU_TOP/forms/US
3) Set the forms env var
4) Compile the form using :
frmcmp_batch.sh userid=apps/xxxxxx Module=xxxxx.fmb Module_Type=form compile_all=special output_file=xxxxxx.fmx
5) Copy the generated form ( *.fmx) to the corresponding product top  ( $PROD_TOP/forms/US )
6) Check the permission on file *.fmx ( it should be 755 )

Deploying forms from graphical interface :

Use the “frmcmp” in vnc server to open the graphical interface. The screen shot will look like this ….

form_comp

Posted in Oracle Apps R12 | 1 Comment »

R12 – Various LogFiles Locations

Posted by Srikrishna Murthy Annam on October 12, 2009

R12 – Various LogFiles Locations :

Startup/Shutdown Log files for Application Tier in R12

$LOG_HOME/appl/admin/log/

Service Logfile Name
TNS Listener Start/Stop log adalnctl.txt
Fulfillment Server Start/Stop log jtffmctl.txt
Oracle HTTP Server start/stop log adapcctl.txt
Concurrent Managers and ICM start/stop log adcmctl.txt
Forms OC4J start/stop log adformsctl.txt
OACore OC4J start/stop log adoacorectl.txtq
OAFM OC4J start/stop log adoafmctl.txt
OPMN start/stop log adopmnctl.txt

Tech Stack  10.1.3 (Web/HTTP Server) Logs

Log File Name Log File Location
AD script log files (e.g.from adapcctl.sh) $INST_TOP/logs/appl/admin/log
CM Log Files ($APPLCSF/$APPLLOG) $INST_TOP/logs/appl/conc/log
AD tools log files (e.g. ADPATCH) $APPL_CONFIG_HOME/admin/$TWO_TASK/log
OPMN Log Files (text and ODL) $ORA_CONFIG_HOME/10.1.3/opmn/logs (may move to  $INST_TOP/logs/10.1.3/opmn)
Apache Log Files (text and ODL) $INST_TOP/logs/10.1.3/Apache/
OC4J Log Files (text) $INST_TOP/logs/10.1.3/j2ee/oacore/
OC4J Log Files (ODL) $INST_TOP/logs/10.1.3/j2ee/oacore/log/oacore_default_group_1/oc4j

Log files related to cloning in R12:

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/apps/$CONTEXT_NAME/admin/log/ApplyAppsTier_.log

Patching related log files in R12

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

Autoconfig related log files in R12

Database Tier Autoconfig log :
– $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/MMDDHHMM/adconfig.log
– $ORACLE_HOME/appsutil/log/$CONTEXT_NAME/MMDDHHMM/NetServiceHandler.log
Application Tier Autoconfig log :
– $INST_TOP/apps/$CONTEXT_NAME/admin/log/$MMDDHHMM/adconfig.log
Autoconfig context file location in R12
– $INST_TOP/apps/$CONTEXT_NAME/appl/admin/$CONTEXT_NAME.xml

Other log files in R12

Database Tier
Relink Log files :
– $ORACLE_HOME/appsutil/log/$CONTEXT_NAME /MMDDHHMM/ make_$MMDDHHMM.log

Alert Log Files:
– $ORACLE_HOME/admin/$CONTEXT_NAME/bdump/alert_$SID.log

Network Logs:
– $ORACLE_HOME/network/admin/$SID.log

OUI Logs
OUI Inventory Logs :
– $ORACLE_HOME/admin/oui/$CONTEXT_NAME/oraInventory/logs

Application Tier

– $ORACLE_HOME/j2ee/DevSuite/log
– $ORACLE_HOME/opmn/logs
– $ORACLE_HOME/network/logs

Posted in Oracle Apps R12 | Tagged: | 8 Comments »

R12 – How to enable logging for Apache,Oc4j and Opmn

Posted by Srikrishna Murthy Annam on September 29, 2009

R12 – How to enable logging for Apache,Oc4j and Opmn:

Apache Logging ( Plain Text )
==============================

1) Edit the file $ORA_CONFIG_HOME/10.1.3/Apache/Apache/conf/httpd.conf and set
LogLevel warn (s_apache_loglevel in context file)
2) Bounce the apache
3) Try to access the home URL or reproduce the issue.
4) Collect the following logfiles from $LOG_HOME/ora/10.1.3/Apache
access_log.<unique id>
error_log.<unique id>

Values that can be set to LogLevel variable in httpd.conf file
LogLevel = emerg,alert,crit,error,warn,notice,info,debug.

Apache Logging ( ODL Logging)
=============================

1) Set the following parameters in file $ORA_CONFIG_HOME/10.1.3/Apache/Apache/conf/httpd.conf
OraLogMode [oracle|odl|apache]
OraLogSeverity <message type>:<message level>

Message type: INTERNAL_ERROR, ERROR, WARNING, NOTIFICATION & TRACE
Message level: 1-32 (1 most severe, 32 least)
2) Bounce the apache
3) Try to access the home URL or reproduce the issue.
4) Collect the logfiles from $LOG_HOME/ora/10.1.3/Apache/oracle

OC4J Logging
============

By default Oracle Applications R12 creates 3 OC4J instances:
*  OACore: runs OA Framework-based applications
* Forms: runs Forms-base applications
* OAFM (Oracle Apps Fusion Middleware): runs web services, mapviewer, ascontrol

Loglevel is set in the file
$ORA_CONFIG_HOME/10.1.3/j2ee/<oacore, forms, oafm>/config

Log file path is specified in the file
$ORA_CONFIG_HOME/10.1.3/j2ee/<oacore, forms, oafm>/application-deployments/<oacore, forms, oafm>/orion-application.xml

1) Open the file to set the following log level $ORA_CONFIG_HOME/10.1.3/j2ee/<oacore, forms, oafm>/config/j2ee-logging.xml
2) Come to the location located as
“<logger name=’oracle’ level=’NOTIFICATION:1‘ …..
3) Set the desired logging using following values
<message type>:<message level>
Message type: INTERNAL_ERROR, ERROR, WARNING, NOTIFICATION & TRACE
Message level: 1-32 (1 most severe, 32 least)
4) Locate the log file path from the file
$ORA_CONFIG_HOME/10.1.3/j2ee/<oacore, forms, oafm>/application-deployments/<oacore,forms,oafm>/orion-application.xml
(Will be identified with tag : <log> <file path=…> </log>)
5) Bounce the OC4J instance and reproduce the issue
6) Collect the log files from the following locations .
Plain text -> $LOG_HOME/ora/10.1.3/j2ee/<oacore, forms, oafm>/<oacore,forms,oafm>_<default_group_1>/application.log
ODL Log -> $LOG_HOME/ora/10.1.3/j2ee/<oacore, forms, oafm>/<oacore,forms,oafm>_<default_group_1>/log.xml

OPMN Logging
============

1) Open the file $ORA_CONFIG_HOME/10.1.3/opmn/conf/opmn.xml to set the logging parameter
2) Logging is enabled per component (internal, ons or pm)
3) Levels that can be set are (component codes) as following:
none, fatal, error, warn, notify          (written to .log)
debug1, debug2, debug3, debug4    (written to .dbg)
Ex :
opmnctl set target=log comp=warn
opmnctl set target=debug comp=debug1
4) Bounce opmn services and reproduce the issue
5) Collect the opmn log files generated in $LOG_HOME/ora/10.1.3/opmn
opmn.log , opmn.dbg and opmn.out

NOTE : Logfiles can be enabled for rotation using parameter s_opmn_log_rotation_size, s_opmn_log_rotation_time in opmn.xml

Various Other Logfiles :
========================

$LOG_HOME/appl/admin/log/

Service Logfile Name
TNS Listener Start/Stop log adalnctl.txt
Fulfillment Server Start/Stop log jtffmctl.txt
Oracle HTTP Server start/stop log adapcctl.txt
Concurrent Managers and ICM start/stop log adcmctl.txt
Forms OC4J start/stop log adformsctl.txt
OACore OC4J start/stop log adoacorectl.txtq
OAFM OC4J start/stop log adoafmctl.txt
OPMN start/stop log adopmnctl.txt

Posted in Oracle Apps R12 | Tagged: , , , , | Leave a Comment »

R12 – Concurrent Program Tracing

Posted by Srikrishna Murthy Annam on September 25, 2009

Concurrent Program Tracing :

Reference Note : 296559.1

CASE 1 : Concurrent Program Tracing without bind variables
1) Follow the following navigation to enable logging for conc prog
Goto Sysadmin > Concurrent > Program > Define
Query the concurrent program
Check the trace box to enable trace
2) Execute the concurrent program using the following navigation and note down the request id
3) Collect the trace file using the script provided here

CASE 2: Concurrent Program Tracing with bind variables and waits
1) Note down the following values

SELECT value FROM v$parameter WHERE name = ‘max_dump_file_size’;
SELECT value FROM v$parameter WHERE name = ‘timed_statistics’;

2) Execute the following commands as sysdba

ALTER SYSTEM SET max_dump_file_size = unlimited;
ALTER SYSTEM SET timed_statistics = true;
ALTER SYSTEM SET EVENTS ’10046 trace name context forever, level 12′;

3) Execute the concurrent program using the following navigation and note down the request id
4) Collect the trace file using the script provided here
5) Turn off tracing the reset the values

ALTER SYSTEM SET EVENTS ’10046 trace name context off’;
ALTER SYSTEM SET max_dump_file_size = <value from step 1>;
ALTER SYSTEM SET timed_statistics = <value from step 1>;

CASE 3:
Enabling the trace for a concurrent request for which you donot have privileges to run the concurrent Request.

1) Ask the person who is privileged to run the concurrent program and get the request id ‘xxxxx’
2) Get the oracle_process_id for that concurrent request.

SQL>select request_id,oracle_process_id from fnd_concurrent_requests where request_id in (‘xxxxxxx’);

3) Now get the session details ( SID and Serial ) using value obtained from step 2

col “SID/SERIAL” format a10
col username format a15
col osuser format a15
col program format a40
select s.sid || ‘,’ || s.serial# “SID/SERIAL”
, s.username
, s.osuser
, s.status
, p.spid “OS PID”
, s.inst_id
, s.module
from sys.gv_$session s
, sys.gv_$process p
Where s.paddr = p.addr
and s.inst_id = p.inst_id
and p.spid=&value_from_step2
order by to_number(p.spid);

4) Execute the following command to enable the trace :

SQL> EXECUTE dbms_support.start_trace_in_session (&SID,&SERIAL,binds=>true,waits=>true);

NOTE : You need to run this command on the corresponding rac node, inst_id from step3)
5) Collect the trace from udump location and investigate the issue.

Posted in Oracle Apps R12 | Tagged: , , , , , , | 1 Comment »

R12 – Changing APPS password

Posted by Srikrishna Murthy Annam on September 24, 2009

Changing APPS password

There are some situations where you may need to change the apps password. Some times you may or may not know the apps password. And some times the password may be reset if it is corrupted.

Action Steps ( when you know the old apps password )
1) Shutdown all the MT services
2) Change apps password using FNDCPASS
FNDCPASS apps/[oldpasswd] 0 Y system/pwd SYSTEM APPLSYS <new_pwd>
3) Run autoconfig
4) Startup all the MT services

Action Steps ( when you forgot/dont know the apps password)
Follow metalink Note 160337.1 to change the apps password and then run autoconfig.

Encrypted Passwords details :

SQL> select oracle_username,encrypted_oracle_password from fnd_oracle_userid where oracle_username IN (‘APPS’, ‘APPLSYS’,’APPLSYSPUB’);
SQL> select encrypted_foundation_password, encrypted_user_password from fnd_user where user_name = ‘SYSADMIN’;

Posted in Oracle Apps R12 | Tagged: , , | 1 Comment »

 
%d bloggers like this: