Get information on Oracle Applications Inventory

There is a good utility for checking all the techstack components and there versions present in e-business application. This is applicable to both 11i and R12 environments.

There is a script $FND_TOP/patch/115/bin/txkInventory.pl on apps side which is going to fetch the versions of all components on apps side. This script can be run by giving input to $FND_TOP/patch/115/bin/TXKScript.pl script. TXKScript.pl script takes 2 mandatory arguments, one is the script to run and another is the directory for storing log file and out file. Other then these arguments you must give context file name and location and apps password as well. Also you need to give outfile where it will create report of techstack components.

Login to apps side of your application and source the environment. Run the below command

(appmgr06) appmgr - -bash $ perl $FND_TOP/patch/115/bin/TXKScript.pl -script=$FND_TOP/patch/115/bin/txkInventory.pl -txktop=$APPLTMP -contextfile=$CONTEXT_FILE -appspass=apps -outfile=$OA_HTML/techstack_info.html
*** ALL THE FOLLOWING FILES ARE REQUIRED FOR RESOLVING RUNTIME ERRORS
*** STDOUT = /slot06/appmgr/scmc2mq0comn/rgf/scmc2mq0/TXK/txkInventory_Fri_May_16_04_01_03_2008_stdout.log
Reportfile /slot06/appmgr/scmc2mq0comn/html/techstack_info.html generated successfully.

You can access the above report file using http://(hostname.domain):(port)/OA_HTML/techstack_info.html

The report will have following information.

• Summary of environment details
• Inventory of HTTP Server Node
• Inventory of Forms Server Node
• Inventory of Concurrent Processing Server Node
• Inventory of Administration Server Node

Similarly you can check on DB side as well

(oracle06) scmc2mq0 - -bash $ perl $ORACLE_HOME/appsutil/bin/TXKScript.pl -script=$ORACLE_HOME/appsutil/bin/txkInventory.pl -txktop=$ORACLE_HOME/appsutil/temp -contextfile=$CONTEXT_FILE -appspass=apps -outfile=$ORACLE_HOME/appsutil/temp/master_db.html

HAPPY LEARNING!

ALL NEW IN R12 !

Main points about Installer:
1) config.txt is now configSID.txt , for adding node, you can use configSID.txt or get details from database directly using host.domain:port:sid format
2) Install types: Standard and Express
3) Shared APPL_TOP, COMN_TOP and tech stack as well, but not for Windows
4) Easy load balancing of CP and Web communications
5) Technology Stack Components : Oracle 10g R2 Database home, Oracle Developer 10i (forms, reports) and Oracle 10g Application Server 10.1.2 (http server)
6) Java Development Kit (JDK) 5.0 is automatically installed by Rapid Install
7) Disk Space : Applications node 28 GB , Fresh DB 45 GB, Vision DB 133 GB, Stage for fresh install 33 GB, TEMP 500 Mb
8) Create Stage : CD's are in DVD Format, and run adautostg.pl to create dir structure, which requires perl 5.0053 in PATH, and creates subdirectories startCD, oraApps, oraDB, oraAS, and oraAppDB under stage12
9) Want to install on virtual hostname, use -servername as command line parameter with rapidwiz. There are 2 more command line parameters, -restart to restart any failed install, and -techstack to install only technology stack.
10) Incase of multiuser installation, start installer using root account
11) For additional language, you must use OAM (oracle applications manager)
12) There is new concept of INST_TOP which mainly stores instance specific files including runtime files, log files and configuration files
13) In R12 there are Services concept instead of nodes (forms/web/concurrent). Following is the list of services in R12 :
* Root Service Group which supports • Oracle Process Manager (OPMN)
* Web Entry Point Services which supports • HTTP Server
* Web Application Services which supports • OACORE OC4J • Forms OC4J • OAFM OC4J
Batch Processing Services which supports • Applications TNS Listener • Concurrent Managers • Fulfillment Server
Other Service Group which supports • Oracle Forms Services • Oracle MWA Service
* : Thses services must be installed on same / one machine (which is nothing but Web node, according to 11i )
14) Regardless of type of services confugured on perticular server, all files (forms, reports, jsp) are stored in APPL_TOP (Unified), basically to have pure 3 tier arch
15) Installer gives option to configure OCM (Oracle configuration manager) where in OCM keeps track of key Oracle and OS stats. This collected data is sent to oracle support via https for better understanding of issues and quick resulations to any issues reported

Main points about Upgrade:
1) You can only upgrade to R12 from 11i, if you are at older version (like 10.7 or 11.0.3 etc), you must upgrade first to 11i, and then upgrade to R12
2) High level R12 Upgrade process :
• Run rapid installer first time to layout new file structure and tech stack
• Migrate or Upgrade database to 10g R2
• Run Autopatch to run database driver to bring DB to R12 level
• Run rapid installer second time to configure and start services

Admin Scripts:

adautocfg.sh - run autoconfig
adstpall.sh - stop all services
adstrtal.sh - start all services
adapcctl.sh - start/stop/status Apache only
adformsctl.sh - start/stop/status OC4J Forms
adformsrvctl.sh - start/stop/status Forms server in socket mode
adoacorectl.sh - start/stop/status OC4J oacore
adoafmctl.sh - start/stpp/status OC4J oafm
adopmnctl.sh - start/stop/status opmn
adalnctl.sh - start/stop RPC listeners (FNDFS/FNDSM)
adcmctl.sh - start/stop Concurrent Manager
gsmstart.sh - start/stop FNDSM
jtffmctl.sh - start/stop Fulfillment Server
adpreclone.pl - Cloning preparation script
adexecsql.pl - Execute sql scripts that update the profiles in an AutoConfig run
java.sh - Call java executable with additional args, (used by opmn, Conc. Mgr)

Note: To understand this page, you should have prior knowledge or background of APPS 11i

HAPPY LEARNING !

Monitoring on an Apps 11i Web Tier Server Proactively

When asked how many were proactively monitoring their access_log. Not many people will put their hands up.

There is a wealth of information in the access_log that can be mined to give information about user behaviour, possible user or system problems, as well as having the potential to give valuable performance information.

Here are just three examples where you can quickly answer important questions about your system with very little effort:

1. How long does it take 9iAS to serve requests?

The main performance information is the time taken to serve a request. This is not included in the access_log by default (I have raised enhancement request 5349693 to include this data), but can easily be added by adding the following line to the httpd.conf file via an AutoConfig customization (see Metalink Note 270519.1):

LogFormat "%h %l %u %t \"%r\" %>s %b %T"

This line can be added anywhere in the file, but would sensibly be placed after the existing LogFormat entries. This directive adds an extra column into the access_log to show the
time in seconds it took from receiving a request to sending back a
response. Valid log formats are described in the Apache documentation.

2. Am I getting any server errors?

The access_log includes the HTTP status code of the request. They are listed in full in RFC 2616 but the codes we would be immediately concerned about are any in the 400 or 500 range.

For example:

• Status 500 (internal server error) may typically be seen for a JServ request and often means the JVM has some kind of problem or has died.
  

  For example: This entry may indicate that the JServ JVM is not responding to any requests:
  
  192.168.1.10 - - [21/Jun/2006:13:25:30 +0100] "POST /oa_servlet/actions/processApplicantSearch HTTP/1.1" 500 0

  
  
• Status 403 (forbidden) could typically be seen for oprocmgr
  
  For example: This entry in access_log may indicate a problem with system configuration (oprocmgr.conf): requests and often means there is a misconfiguration that needs to be resolved.

myserver - - [21/Jun/2006:13:25:30
+0100] "GET
/oprocmgr-service?cmd=Register&index=0&modName=JServ
&grpName=OACoreGroup&port=16000
HTTP/1.1" 403 226

3. Are users having problems accessing pages?

The status code of 200 means the request was successful, however a dash ( - ) for the "Bytes sent" column, normally means that the request hit the Apache timeout. You would also see a time taken to serve request above 300 seconds as the default Apache timeout is 5 minutes.

If you see this situation occurring regularly then your users are either navigating away from the browser page before it has rendered, or are likely to be getting a "white screen of death" in their browser window where it will appear to hang.

In this situation you need to identify why the requests are not being processed in good time, which is a large subject in itself.

Identifying these issues

Hopefully these examples will inspire you to want to analyse your access_log, but I hear you ask, "Where will I get the time?"

Luckily the access_log is a simple text file, so if you do not have commercial monitoring software you can use some "quick and dirty" scripts to report just the exceptions you are interesting in seeing. For example I would often use the following to scan access_logs for problems:

## Start of script
##
##  Check for HTTP statuses in 400 or 500 range for JServ
##  or PLSQL requests only
##
awk ' $9>=400 && $9<=599 { print $0 }' access_log* | grep -e    "servlet" -e "\/pls\/" | grep -v .gif ## ##  Check for requests taking more than 30 seconds to be returned ## awk ' $11>30 {print $0} ' access_log*
##
##  This one is not an exception report, you need to manually check
##  Look for when the JVMs are restarting
##
grep "GET /oprocmgr-service?cmd=Register" access_log*
##
## End of script

[Editor: Due to formatting restrictions on this blog, if you're cutting-and-pasting this script, you must manually join the line above ending with grep -e with the following line starting with "servlet" into a single unbroken line.]

Conclusion

Proactive monitoring of the access_log will help you to :-

• Baseline your system performance
• Identify user usage patterns
• Highlight possible system or user problems
• Identify areas with possible performance issues
• Verify user reported problems

HAPPY LEARNING!