Enable JServ Logging in Apps

It is quite common for Oracle Tech support, while troubleshooting any 11i E-Business Suite Self Service Applications (SSWA) related error messages, to ask to enable debug logging in JServ configuration files.

The procedure to enable debug logging in JServ is to update following line in file $IAS_ORACLE_HOME/Apache/Jserv/etc/jserv.properties from log=false to log=true, and then bounce Apache using:

$ cd $COMMON_TOP/admin/scripts/$CONTEXT_NAME

$ adapcctl.sh stop

$ adapcctl.sh start

After the bounce, we start seeing debug messages in the log file $IAS_ORACLE_HOME/Apache/Jserv/logs/jserv.log.

Please note, the logfile’s and config file’s locations can be different from those mentioned above. In case you have a shared tech stack implemented, replace $IAS_ORACLE_HOME with $CONF_TOP/iAS.

The main problem with this procedure is the bounce of Apache. In cases where the client is not a heavy SSWA user and the issue isn’t affecting a significant number of users, then often we will be asked to wait until off-business hours to do the bounce of Apache. These delays can make your metalink SR hop between different Oracle support offices in different timezones, which can lead to delays in resolution of the issue.

Let’s have quick review of JServ configuration files which are of interest to us. jserv.conf — this is the configuration file of mod_jserv module in Apache. Here’s a snippet from jserv.conf:

# jserv.conf

ApJServGroup OACoreGroup 1 1 /test/prodora/iAS/Apache/Jserv/etc/jserv.properties

ApJServGroup DiscoGroup  1 1 /test/prodora/iAS/Apache/Jserv/etc/viewer4i.properties

ApJServGroup FormsGroup  1 1 /test/prodora/iAS/Apache/Jserv/etc/forms.properties

ApJServGroup XmlSvcsGrp  1 1 /test/prodora/iAS/Apache/Jserv/etc/xmlsvcs.properties

Its syntax is as follows: ApJServGroup groupname num_of_jvms weight configuration_file. In the above example, each group gets one JVM started and this JVM reads parameters from the corresponding configuration file.

Here is a trick that you can use to make changes in jserv.properties, forms.properties, viewer4i.properties, and xmlsvcs.properties take effect immediately. Each of the JVMs that gets started has a logfile in the $IAS_ORACLE_HOME/Apache/Jserv/logs/jvm directory.

$ ls |sort

DiscoGroup.0.stderr

DiscoGroup.0.stdout

FormsGroup.0.stderr

FormsGroup.0.stdout

OACoreGroup.0.stderr

OACoreGroup.0.stdout

XmlSvcsGrp.0.stderr

XmlSvcsGrp.0.stdout

So let’s say you want to make changes in jserv.properties. In effect, the corresponding log file is OACoreGroup.0.stdout, so find the process that’s writing to this and kill it. Here’s how:

$ /sbin/fuser OACoreGroup.0.stdout

OACoreGroup.0.stdout: 21433

$ /sbin/fuser -k OACoreGroup.0.stdout

OACoreGroup.0.stdout: 21433

$ /sbin/fuser OACoreGroup.0.stdout

OACoreGroup.0.stdout: 22194

The PID of the JVM that was writing to the log file was 21433; we killed it using fuser -k. The JVM gets restarted immediately by the mod_oprocmgr module, and we can see the new JVM pid in effect.

The procedure we followed here saved us a complete bounce of Apache, but unfortunately, for changes in jserv.conf to take effect, we still need a complete Apache bounce. This trick will only work for files jserv.properties, forms.properties, viewer4i.properties, and xmlsvcs.properties.

Concurrent Managers

Concurrent processing is at the core of every oracle applications instance. Over the years Oracle Applications has come through a number of changes but concurrent processing has retained itself and in fact got new features added on to its self with very new version.

The request processing on Oracle Applications takes place through the implementation of concurrent Managers. These Managers allow for a concurrent processing of jobs and also scheduling and queuing of jobs.

The objective of the current post is to go through a overview of Concurrent Managers and concurrent processing in Oracle Applications.

The default installation of Oracle Applications comes with a number of pre defined concurrent managers however you can create your custom concurrent managers to spread out the load of your job processing.

Apart from taking care of the load of your jobs the concurrent managers can also be made to schedule periodic jobs and you could also have the concurrent managers run in specific workshifts thus allowing specific programs to be run with specific priority and specific times.

Concurrent managers also allows you to tweak the number of concurrent process that it can handle concurrent if the request exceed this prescribed limt they are automatically put on pending state. The processing of a request takes place based on the time of request submission and priority of the request submitted.

As mentioned there are different types of concurrent mangers in Oracle Applications among them the three important manager which are required by any oracle applications installation are stated below

• Internal Concurrent Manager (ICM) - The Internal concurrent manager or the ICM is the 'master' concurrent manager. Its primary responsibility is to take care of the starting and stopping of all other concurrent managers that have been defined in the system and activated. However once the other managers are up and running the ICM does not play much of a role. It is for the same reason that despite your ICM being down oracle applications continues to perform as expected most of the times. That is you would be able to continue submitting requests even with the ICM down. However there are cases where you can evolve your ICM to do larger roles like acting as a conflict resolution manager or in case you have generic service management enabled your ICM can take care of starting and stopping other application services also.

• Standard Concurrent Manager - This the core manger and the most hard working of the three. It takes care of managing all the concurrent requests in the system. If however specific programs have been defined to use specific concurrent manager they would be taken care by that manager in all other cases the standard manager will be the default concurrent manager and will process the request. That is by default all the concurrent programs are defined to be run by the standard manager and they should not be excluded unless you have included them to run by an other manager. Though we can change a few setting of the standard concurrent manager like the number of process it can handle, most of the other definition should remain unchanged.

• Conflict Resolution Manager (CRM) - The conflict resolution manager of the CRM is responsible of handling any conflicts that might occur within the concurrent programmes. This conflict could be as a result of various reasons for example there might be a business requirement that two instances of a particular report should not be executed at the same time or during a particular period. In case such a scenario occurs the CRM is responsible for taking care of such request. As in the case of the standard concurrent manager the definition for the CRM should be rarely changed.

Apart from these three concurrent manages there is another type of concurrent manager known as the Transaction Manager also exists. The transaction manager is responsible for taking the load off the concurrent request table for pooling the request submitted by the user.The transaction manager takes care of these requests and sends it to standard manager directly.In a RAC environment the Transaction manager is required to be activated on each node of the RAC environment.

From the front end you could view the status of your concurrent manager by logging with the System Administration responsibility and going to the Concurrent Manager administer screen.








The concurrent managers are like other process which run on the oracle applications executable FNDLIBR. The FNDLIBR executable is located at $FND_TOP/bin.

You could also grep the FNDLIBR executable to check if any concurrent manager process are running

$ ps -ef|grep FNDLIBR

The $FND_TOP/sql/afcmstat.sql script gives you a list of concurrent managers and their respective status.

The status of concurrent managers and the nodes on which they are configured can also be known from the Oracle Applications manager.

Check Versions of Oracle Applications Components

Help-> About Oracle Applications from any of the forms sessions.

Or

Connect as apps user
select release_name from apps.fnd_product_Groups;

Version of Applications Forms (fmb,fmx) or reports (rdf)

To find the version of any oracle applications files
strings -a ICQTYED.fmx | grep Header

Alternatively you can also use the adident command
adident Header ICQTYED.fmx

Version of a Java class File
To find the version of a java class file
$ strings | grep '$Header'

Version of JDBC

In your middle tier, edit the jserv.properties file located in the iAS_ ORACLE_HOME/Apache/Jserv/etc directory
Locate the wrapper.classpath that is pointing to the jdbc zip file
/d01/oracle/viscomn/java/jdbc14.zip

Or
http://.:port/OA_HTML/jsp/fnd/aoljtest.jsp
Look for String ” JDBC driver version” under Connection String

Version of Apache
Go to the $iAS/Apache/Apache/bin directory and enter the following command:
$ httpd -version

Version Of The OA Framework
To find out the version of your Oracle appplication Framework
Option 1
http://.:port/OA_HTML/OAInfo.jsp

Option 2
adident Header %FND_TOP%/html/OA.jsp
adident Header %OA_HTML%/OA.jsp

Note: OA.jsp should be of the same version in both the places

Version of Application Product or Patch Set Level.

One of the most common things you will asked by your support engineer is the version or commonly known as the patch set level of your Oracle Applications product, while or after raising your service request. You can query this by logging on to your application database as the apps user.

select patch_level from fnd_product_installations where patch_level like '%AD%';

Version of Discoverer

cd $APPL_TOP/admin
grep -I s_disco_ver_comma **xml

Version of OJSP

Log in to the application server as the applmgr user
cd $OA_HTML
edit the jtflogin.jsp file to add the following line
OJSP Version: <%= application.getAttribute("oracle.jsp.versionNumber") %>
clear your cache and bounce your apache server
soruce the jtflogin.jsp from your browser

http://[your web server]:[your port]/OA_HTML/jtflogin.jsp
OJSP Version: 1.1.3.5.2

Version of JSP
Log on to your HTTP Server node, and change to the OA_HTML directory.
Using a text editor, create a file called test.jsp with only the following line:
<%= application.getAttribute("oracle.jsp.versionNumber") %>

Access this JSP from a web browser, using the URL:
http://[your web server]:[your port]/OA_HTML/test.jsp

Version of Portal
select fnd_oracle_schema.getouvalue(’PORTAL’) from dual;

FND_ORACLE_SCHEMA.GETOUVALUE(’PORTAL’)
——————————————————————————–
PORTAL30 <= to retrieve the portal user

select version from PORTAL30.wwc_version$;

VERSION
——————————————————————————–
3.0.9.8.1

or

begin
execute immediate 'select fnd_oracle_schema.getouvalue(''PORTAL'') from
dual' into portal_user;
begin
execute immediate 'select user_name from fnd_user where user_name like
upper('''||portal_user||''')'
into portal_user_name;
if portal_user is not null then
execute immediate 'select version from '||portal_user||'.wwc_version$'
into portal_ver;
check_message := ' [PASS] Your Applications database contains
Portal version: '||portal_ver;
dbms_output.put_line(check_message);
end if;
exception
when no_data_found then
null;
end;
exception
when others then
null ;
end;

Version of XML Parser

You can find out the version of your XML Parser using the following query
SQL> select WF_EVENT_XML.XMLVersion() XML_VERSION
2 from sys.dual;
XML_VERSION
--------------------------------------------------------------------------------
Oracle XDK Java 9.0.4.0.0 Production

Version of XML Publisher

To check weather XML publisher is installed or not you can query the FND_PRODUCT_INSTALLATIONS table or you can lookup the
reports in Oracle Applications Manager. You can find out the version for your XML publisher from the output of your report or from MetaInfo.class file.

$OA_JAVA/oracle/apps/xdo/common/MetaInfo.class.

Version of WorkFlow

You can find out the version of your workflow using the following query
SQL> select TEXT Version from WF_RESOURCES
2 where TYPE = 'WFTKN' and NAME = 'WF_VERSION';
VERSION
--------------------------------------------------------------------------------
2.6.0

Version of Oracle Login Server

begin
execute immediate 'select fnd_oracle_schema.getouvalue(''LOGINSERVER'') from
dual' into sso_user;
begin
execute immediate 'select user_name from fnd_user where user_name like
upper('''||sso_user||''')' into
sso_user_name;
if sso_user is not null then
execute immediate 'select version from '||sso_user||'.wwc_version$' into
sso_ver;
check_message := ' [PASS] Your Applications database contains Login
Server version: '||sso_ver;
dbms_output.put_line(check_message);
end if;
exception
when no_data_found then
null;
end;
exception
when others then
null ;
end;

Check Developer Forms Patch Set Level

1.Login though applmgr account

2.Create a file fpslevel.sh

cat > fpslevel.sh
copy the following contents in fpslevel.sh file.

#!/bin/sh
########################################
#fpslevel.sh - Used to find out the forms patchset level
########################################
clear
PatchLevel=0
f60gen > /dev/null 2>&1
if [ $? -eq 127 ]
then
echo "Environment is not Set"
else
PatchLevel=`f60gen | grep '(Form Compiler)' | grep -v Release | awk -F. '{print $5}' `
echo 'Forms Patchset Level :' ` expr $PatchLevel - 9 `
fi
echo 'For More Information '
echo 'Refer to Metalink Note:232313.1 for More Information'

3.Grant the execute permission to the script
chmod 777 fpslevel.sh

4.Execute the script.
./fpslevel.sh

Check Database Performance by these queries

SELECT * FROM v$log;

SELECT COUNT(*) FROM v$process;

SELECT COUNT(*) FROM v$session WHERE status='ACTIVE'

SELECT COUNT(*) FROM dba_locks WHERE blocking_others='Blocking';

SELECT COUNT(*) FROM dba_objects WHERE status='INVALID' AND owner IN ('ABC','DEF') GROUP BY owner;

SELECT A.Tablespace_Name,TRUNC((SUM(A.Tots)/1024/1024),3) Tot_Size,
TRUNC(((SUM(A.Tots)/1024/1024)-(SUM(A.Sumb)/1024/1024)),3) Tot_Used
FROM (
SELECT Tablespace_Name,0 Tots,SUM(Bytes) Sumb,
MAX(Bytes) Largest,COUNT(*) Chunks
FROM Sys.Dba_Free_Space A
GROUP BY Tablespace_Name
UNION
SELECT Tablespace_Name,SUM(Bytes) Tots,0,0,0
FROM Sys.Dba_Data_Files
GROUP BY Tablespace_Name) A, V$instance B
GROUP BY A.Tablespace_Name
ORDER BY A.Tablespace_Name

SELECT (1-(SUM(DECODE(name,'physical reads', value, 0))/
(SUM(DECODE(name,'db block gets', value, 0)) +
SUM(DECODE(name,'consistent gets', value, 0))))) * 100 "Read Hit Ratio"
FROM v$sysstat

SELECT d.status "Status",
d.tablespace_name "Name",
d.CONTENTS "Type",
d.extent_management "Extent Management",
TO_CHAR(NVL(a.bytes / 1024 / 1024, 0),'99G999G990D900') "Size (M)",
TO_CHAR(NVL(NVL(f.bytes, 0), 0)/1024/1024 ,'99G999G990D900') "Free (MB)",
TO_CHAR(NVL((NVL(f.bytes, 0)) / a.bytes * 100, 0), '990D00') "Free %"
FROM sys.dba_tablespaces d, (SELECT tablespace_name, SUM(bytes) bytes
FROM dba_data_files GROUP BY tablespace_name) a,
(SELECT tablespace_name, SUM(bytes) bytes
FROM dba_free_space GROUP BY tablespace_name) f
WHERE d.tablespace_name = a.tablespace_name(+) AND d.tablespace_name = f.tablespace_name(+)
AND NOT (d.extent_management LIKE 'LOCAL' AND d.CONTENTS LIKE 'TEMPORARY')
UNION ALL
SELECT d.status "Status", d.tablespace_name "Name", d.CONTENTS "Type", d.extent_management "Extent Management",
TO_CHAR(NVL(a.bytes / 1024 / 1024, 0),'99G999G990D900') "Size (M)",
TO_CHAR(NVL((a.bytes-t.bytes), a.bytes)/1024/1024,'99G999G990D900') "Free (MB)",
TO_CHAR(NVL((a.bytes-t.bytes) / a.bytes * 100, 100), '990D00') "Free %"
FROM sys.dba_tablespaces d, (SELECT tablespace_name, SUM(bytes) bytes
FROM dba_temp_files GROUP BY tablespace_name) a,
(SELECT tablespace_name, SUM(bytes_cached) bytes
FROM v$temp_extent_pool GROUP BY tablespace_name) t
WHERE d.tablespace_name = a.tablespace_name(+) AND d.tablespace_name = t.tablespace_name(+)
AND d.extent_management LIKE 'LOCAL' AND d.CONTENTS LIKE 'TEMPORARY'
ORDER BY 7

AutoConfig

What is Autoconfig?
Autoconfig is a tool for configuring application instance.

What are the programs and program name involved in Auto Config?
You can see perl,shell,cmd and java programs.

1.adconfig.pl- Its a main program which inturn call Java APIs for configuring appl instance.
args-appl context file location

2.adautocfg.sh/adautocfg.cmd-This program inturn calls adconfig.pl
args-apps password

3.adconfig.sh-This program again calls adconfig.pl

These three programs used for running Auto config.

4. adchgatname.pl - This program will validating the APPL_TOP name in context file .If the APPL_Top name is changed, then this utility will take care of storing the old APPL_TOP name in APPL_TOP/admin/ATName.txt.Adconfig.pl calls this program .

Archiving Oracle Applications

Why Archive?
After an implementation of Oracle Application which has been around from some years, you would see a substantial growth in the database size.
As your Oracle Application continues to grow and upgrade the database also grows with it. A lot of data which resides in this database would no longer be needed to be updated and a significat amount of this data would rarely be used for any kind of Reporting. Nevertheless we cannot simply go ahead and purge or trash this data for obvious compliance and regulatory reasons. Another added advantage of archiving is that you can implement data masking in your non production environment while in the process of archiving, this reduces the risks from exposing your production data after subsequent clones.

There are many challenges associated with a large growing database like

• Increase in storage costs.
• Decrease in system responsiveness.
• Increase in times taken to complete cloning cycles.
• Increase in recovery times in cases of system failures.

What to archive ?
This is the most difficult when it came to implement an archive policy. Fortunately most of the archive solutions available in the market came with an out of box solution for Oracle Applications which made sure to preserve the referential integrity of the data. since data in an application is in its normalized form its important to ensure that the archived data is valid enough to be reported from when required. To ensure this a meta data repository is bundled along with the solution which defines the rules for archiving and the associated constraints.

Archiving Options
when it came to archiving options available with the ebusiness suite. these were quite a few of them available. Most of these solutions adopted a similar approach to archiving.
After going through the popular ones solutions available i can categorize them in the following groups.

• Proprietary File Type Based Solutions.
• Archive Database Based Solutions.

Proprietary File Type Based Solutions
Under these kinds of archiving solution the data is archived from Oracle Applications and stored in a flat file system which is generally in a proprietary format. The main and the biggest advantage of adopting such kind of the solution is that the need to maintain a large database is reduced. Also the archived data in the file system can be further compressed further to shrink the size. The major disadvantage of this approach is that you loose the capacity to do a seemless reporting from within your application. That is in order to be able to report from your archived data you would need to be depended on the proprietary reporting tool, rather than being able to do so from with oracle applications.

Archive Database Solutions
In the archive database based solutions, the archived data is stored in a separate database as opposed to a file system. This archive database could reside on a low cost second tire storage system. The main advantage in this structure is that you have the ability to a get to your archive data from within the application itself, in other words you do not need any third party tools to access your data.
One of the disadvantages of this approach is that, this would result in atleast one more database to maintain apart from the production system despite of the fact that this database would be on a lost cost second tier storage.

Limitations.
One of the main limitations that most of these archiving solutions had that, although most of them were able to archive the data from your application they failed to do a database reorg.
After the archiving cycle the database would need to be reorged manually to reclaim the space and see an increase in the system performance.
Also in the even of applications upgrade when the structure of your database tables changed the process of propagating the changes in the archives, though available was a complex process.