February 2008 – Persistent Storage Solutions

Increasing JVM heap size in E-business Suite

Published on February 22, 2008 by Advait3 Comments

Introduction:

Many time we face the performance issue in e-business suite, specially in mid-tier. And most of the time the issue is memory. JVM fall short of memory. This post will demonstrate you about how to increase the JVM memory in middle tier.

If some one ask you a question as an APPS DBA, where will you change if you want to change the memory sizing in middle tier. Without even thinking we should say CONTEXT FILE. Thats right !!! Every thing in middle tier is controlled by CONTEXT FILE.

E-Business suite has some standard values for JVM memory that it set when you clone the instance. You can see the memory values in CONTEXT FILE as given below.

Checking the current memory sizing for mid-tier

We have following variables defined in CONTEXT FILE which defines the memory allocation to different components of application.

s_forms_jvm_start_options -> For defining memory allocation for forms.

We will have 2 elements defined for forms: forms_jvm_start_options and forms_jvm_stop_options

</pre>
<forms_jvm_start_options oa_var="s_forms_jvm_start_options">-server -verbose:gc -Xmx256M -Xms64M -XX:MaxPermSize=128M -XX:NewRatio=2 -XX:+PrintGCTimeStamps -XX:+UseTLAB -XX:+UseParallelGC -XX:ParallelGCThreads=2 -Djava.security.policy=$ORACLE_HOME/j2ee/oacore/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false -Doracle.security.jazn.config=/slot/ems1883/appmgr/inst/apps/ma1st210_rws60051rems/ora/10.1.3/j2ee/forms/config/jazn.xml</forms_jvm_start_options>
<forms_jvm_stop_options oa_var="s_forms_jvm_stop_options">-server -verbose:gc -Xmx256M -Xms64M -XX:MaxPermSize=128M -XX:NewRatio=2 -XX:+PrintGCTimeStamps -XX:+UseTLAB -XX:+UseParallelGC -XX:ParallelGCThreads=2 -Djava.security.policy=$ORACLE_HOME/j2ee/oacore/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false</forms_jvm_stop_options>
<pre>

-Xmx256M -> this mean maximum heap size is 256MB
-Xms64M -> this mean initial heap size is 64MB
-XX:MaxPermSize -> specifies the the maximum size for the permanent generation heap

Similarly we have the following variables as well for oacore and oafm, each having start_options and stop_options

s_oacore_jvm_start_options -> For defining memory allocation for oacore.
s_oafm_jvm_start_options -> For defining memory allocation for oafm.

The above setup if for increasing the JVM size for 1 JVM. You can also increase the number of JVM processes as well.

-bash-3.00$ grep nproc $CONTEXT_FILE
<frmsrv_nprocs oa_var=”s_frmsrv_nprocs”>1</frmsrv_nprocs>
<forms_nprocs oa_var=”s_forms_nprocs”>2</forms_nprocs>
<oacore_nprocs oa_var=”s_oacore_nprocs”>2</oacore_nprocs>
<oafm_nprocs oa_var=”s_oafm_nprocs”>1</oafm_nprocs>

If you see here we have nproc (number of JVM processes) defined for each of the component. We can even change number of JVM processes for each component. How to change these settings … keep reading !!!

Changing the JVM memory size

When you are changing the memory size, once cannot just increase the memory size. One needs to check what is the current physical memory available on this system. System I mean to say the host. Also one should see, how many environments are running on that host. Depending on these factors, you need to come up with memory available to your host.

Example in my case I have a host with 8GB RAM. I have 2 environments available on this host. So that gives me 4GB RAM for each instance (Assuming that both the instances are of similar type).
So out of 4GM of physical RAM memory, I will need 1GB for database (my SGA_TARGET is set to 1G).
We are now left with 3GB of RAM memory. Most of the issues and processing goes with oacore. So its a good idea to concentrate more on oacore and then on forms.
We can set -Xmx for s_oacore_jvm_start_options to 1024 and -Xms & -XX:MaxPermSize to 256M. That mean 1 JVM process for oacore will not consume 1G memory. We have defined 2 processes for oacore (s_oacore_nprocs parameter). So for oacore we have allocated 2G memory. We are not left with 1G memory.
Forms having max heap size (-Xmx256M) 256MB and 2 processes defined for the same. Thats makes 512MB if memory for forms. So remaining 512MB can be allocated to oafm process.

Exmaple s_oacore_jvm_start_options will look as given below.

</pre>
<oacore_jvm_start_options oa_var="s_oacore_jvm_start_options">-server -verbose:gc -Xmx1024M -Xms256M -XX:MaxPermSize=256M -XX:NewRatio=2  -XX:+PrintGCTimeStamps -XX:+UseTLAB -XX:+UseParallelGC  -XX:ParallelGCThreads=2  -Dcom.sun.management.jmxremote -Djava.security.policy=$ORACLE_HOME/j2ee/oacore/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false -Doracle.security.jazn.config=/slot/ems1636/appmgr/inst/apps/tkr12r3d_rws60029rems/ora/10.1.3/j2ee/oacore/config/jazn.xml</oacore_jvm_start_options>
<pre>

Once you make the changes in context file, run autoconfig. This will configure the memory sizing for mid-tier.

References:

Metalink note ID: 472781.1

Reducing datafile size to recover free space – Oracle Database 10g

Published on February 21, 2008February 21, 2008 by Advait20 Comments

At time, we want to recover some space from database just to allocate the same to some other tablespace or to return it back to OS disk. This situation arises many times.
And many time we hit with error “ORA-03297: file contains used data beyond requested RESIZE value“.
The concept is simple and many of you must be knowing, but just putting in a simpler words.

Lets take an example of one of the datafile in a database.

Lets see the total free space in a datafile 194.

SQL> select sum(bytes)/1024/1024 from dba_free_space
2 where tablespace_name = ‘APPS_TS_TX_DATA’
3 and file_id = 194;

SUM(BYTES)/1024/1024
——————–
1844.125

Now lets see the distribution for the file.

SQL> select file_id, block_id, blocks, bytes, ‘Free’ from dba_free_space
2 where tablespace_name = ‘APPS_TS_TX_DATA’
3 and file_id = 194
4 and rownum < 7
5 order by block_id desc;

   FILE_ID   BLOCK_ID     BLOCKS      BYTES ‘FRE
———- ———- ———- ———- —-
194      35001     220992 1810366464 Free
194      13433         16     131072 Free
194      13417         16     131072 Free
194      13401         16     131072 Free
194      13385         16     131072 Free
194      13369         16     131072 Free

We can see that there are so many blocks which are free. Its divided into chunks of 16 Blocks and each of these chunks are given a block ID. Now we can see that this formating is done until block 35001 and after that there is no partitions. Beyond the block ID 35001, the whole space is available as a single large unit. This is because of high water mark. When a object is created, it will be created physically in the datafile and will be allocated a block. The number of blocks it will be allocated will depend on the parameter “INITIAL EXTENT” which can be given at the time of creating an object. If we dont give this parameter it will take a default value of 16. So 16 block gets assigned when you create any abject, example a table.

You might be wondering that after block 35001, we have all free space and also we have free space at blocks 13401, 13417, 13433 etc. But where are the blocks between 13433 and 35001??

The answer can be found from dba_extents. All the blocks between 13433 and 35001 are occupied by the objects and are not free. That why you are not able to see them in dba_free_space view. But you can find then in dba_extents. So in case of file 194, objects were getting created until block no 35001 (so we can see that block formating till block 35001) and then at later point of time some of the objects got dropped, so the space got freed, but the formating of blocks remain intact (example block IDs which got freed are 13401, 13417, 13433 etc.). This we call it as high water mark for a datafile.

As we saw earlier that we have around 1844.125 MB free space. Can we recover all of them?? I wish .. but no, we cannot. Reason being that, some of the blocks are free “in-between” and there is a fragmentation. To make my point clear, lets try to reduce the file size.

Lets try that !!

This file original size is 2000M

SQL> select bytes/1024/1024 from dba_data_files where file_id = 194;

BYTES/1024/1024
—————
2000

and as per dba_free_space its having 1844.125 MB free space. Lets reduce the file size by 1800 MB and it will definately give error.

SQL> alter database datafile 194 resize 200M;
alter database datafile 194 resize 200M
*
ERROR at line 1:
ORA-03297: file contains used data beyond requested RESIZE value

What happened??

The reason you are not able to free the space is because we have certain objects created in between and there is no chunk of 1800MB free. The structure of this file is as given below.

X -> Occupied Block
0 -> Free Block

So here block 35001, 13433 are free, but in-between blocks are occupied. When you are trying to reduce the size of datafile by 1800 MB, you are going beyond block ID 35001, where the objects do exits. After those objects there may be free space, but that doesnt matter, you can at max reduce the size of datafile until block ID 35001, and not beyond that.

So here if we see that there are around 220992 blocks free after block ID 35001. That makes a space of around (220992 X 8192 = 1810366464 bytes = 1726.5 MB free). Thats what the bytes column is showing.
So we can reduce the size of this datafile by maximum of 1810366464 bytes = 172.5 MB. If you try to reduce the size more than that, then you will hit with an error ORA-03297: file contains used data beyond requested RESIZE value.

Now try reducing by 1700 MB and it will succeed !!!

SQL> alter database datafile 194 resize 300M;

database altered

What if you want to still reduce the size beyond 1800 MB. i.e. what if you want to make the size to 200MB.

To do that, you need to do following steps.

– Find block ID at 1800th byte.

We know that last 1810366464 bytes are free.
1800 MB = 1887436800 Bytes
Bytes Remaining = 1887436800 – 1810366464 = 77070336 Bytes = 9408 Blocks
Block ID till we want to clear the objects id 35001 – 9408 = 25593

– Drop all the objects which are beyond this block. That will make 1800MB free in this datafile and you can reduce the size of datafile by 1800 MB.

Moral of story is dont get into these many calculations. Its good to know the logic and helps in crisis situation. But not good to go for such drop object, reduce the size if file and recreate the object again.

Generating Event level Traces in Oracle Applications

Published on February 11, 2008February 11, 2008 by Advait2 Comments

We have seen how the event traces can be generated for a database user session using Oracle Trace Utility. Now what if we need to generate the trace for some application user (either Apps 11i or E-business suite R12). In this case when a user connects to an application its very difficult to track the session.

For this reason we have a profile option, which can be set to generate trace file for any event we want within the application.

Follow the below steps for enabling the event level tracing within an application.

1) Login to application and go to “System Administrator” responsibility.

2) Navigate to “Profile -> System”

3) In the user field, enter the name of user you want to enable tracing for. This will be your application user.

4) On the profile search screen search for “Initialization SQL Statement – Custom” profile.

5) When the profile is shown you can set the value as

begin fnd_ctl.fnd_sess_ctl(”,”,’TRUE’,’TRUE’,’LOG’,’ALTER SESSION SET EVENTS=”10046 TRACE NAME CONTEXT FOREVER, LEVEL 12” tracefile_identifier=”AppsTrace_10046”’); end;

All the quotes are single quote here. You can just copy and paste the profile value.

6) DO NOT SAVE THE PROFILE

7) In another browser window, login as the user you are going to trace and prepare to reproduce the problem

8 ) Once you are ready to reproduce the problem, go back to the Applications Forms and Save the profile change

9) Reproduce the problem

10) Back in the Applications form, set profile to null so it does not trace anymore and Save the change

11) The trace will be located in the user_dump_dest. The trace can be identified using the trace identifier we have set – “AppsTrace_10046”. If you have set some different identifier, then you can search using that key word.

Hope this helps !!

FNDCPASS – Best Practices and Tricks

Published on February 6, 2008 by Advait9 Comments

In Oracle Application 11i and R12, we have an FND functionality for changing the passwords for either application user, or product schema password or most important – the “APPS” password. The FND binary which will help us is doing these things is FNDCPASS. This is present in $FND_TOP/bin directory.

This post explains the usage of FNDCPASS, best practices that needs to be followed while using FNDCPASS and some tricks when FNDCPASS screws up the instance :))

Using FNDCPASS

Below is the usage for FNDCPASS

-bash-2.05b$ FNDCPASS
Usage: FNDCPASS logon 0 Y system/password mode username new_password
where logon is username/password[@connect]
system/password is password of the system account of that database
mode is SYSTEM/USER/ORACLE
username is the username where you want to change its password
new_password is the new password in unencrypted format
example FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS WELCOME
FNDCPASS apps/apps 0 Y system/manager ORACLE GL GL1
FNDCPASS apps/apps 0 Y system/manager USER VISION WELCOME

You can just type FNDCPASS and press enter, it will give you these details.

The first usage

FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS WELCOME
is for changing the password for apps and applsys. These are the database schema users (most important for application to work). Password for both these users should be in synch. You can change the password of these users using this command. Note that this is the only way to change the password for apps and applsys. Please do not try any other method for changing apps and applsys password. Oracle recomends using FNDCPASS only to change apps and applsys password. Also note that using this command will change the password for both apps and applsys.

Following activities will take place

(1) applsys validation. (make sure APPLSYS name is correct)
(2) re-encrypt all password in FND_USER
(3) re-encrypt all password in FND_ORACLE_USERID
(4) update applsys’s password in FND_ORACLE_USERID table.
(5) Update apps password in FND_ORACLE_USERID table.

Also changes are made in DBA_USERS table.

The second usage

FNDCPASS apps/apps 0 Y system/manager ORACLE GL GL1
is for changing password for any other product schema like MSC, GL etc.
Following activities will take place

(1) update GL’s password in FND_ORACLE_USERID table. The new password is re-encrypted with the current applsys password.

If GL does not exists, step (2) below does not happen. Message for invalid oracle user is written in the log file.

(2) alter user to change GL’s password.

The third usage

FNDCPASS apps/apps 0 Y system/manager USER VISION WELCOME
is for changing the application level passwords like sysadmin etc used for logging into application.

Following activities will take place

(1) update VISION’s password in FND_USER table. The new password is re-encrypted with the current applsys password.

If VISION does not exist, message for invalid application user is written in the log file.
No products affected by the patch

When you run FNDCPASS command it will check the integrity of all schema password in the application. If any of the password is corrupt then this will through and error and will not change the password.

The tables that it uses is FND_USER and FND_ORACLE_USERID. All the application passwords and schema passwords are stored in these two tables. Ofcourse DBA_USERS will have the schema users and password stored as well.

When we run FNDCPASS it will update all the above 3 tables.

Best practices for using FNDCPASS

Before using FNDCPASS and changing the passwords from default to some thing else, always follow the following best practices.

1) Always, Always, Always keep the back of tables FND_USER and FND_ORACLE_USERID. You can take back of these tables using CREATE TABLE — AS SELECT * FROM —.
You must have backup of these tables before running FNDCPASS. In case if FNDCPASS fails then it might corrupt the passwords of your application and worst can happen that the application wont come up. So always be cautions about this command.

2) If possible also keep an export dump of these two tables.

3) verify each arguement you are providing to FNDCPASS. Like verify that apps and system passwords you are providing is correct.

4) Never update apps, applsys or any schema password directly from database using the alter command. Always use FNDCPASS. System password can be set directly using ALTER command in database.

Issue with APPLSYS and APPS password

Scenario 1:

As you know that apps and applsys password should be in synch and should be changed using FNDCPASS.

There can be situation where a novice user changes applsys password from the backend database. In that case when you try to start the services it will show following error

APP-FND-01496: Cannot access application ORACLE password
Cause: Application Object Library was unable access your ORACLE password.

You can even reproduce this issue (ofcourse after taking the backup of FND_USER and FND_ORACLE_USERID table) using the following steps

1. Use the ALTER USER command to change the APPLSYS password

2. Try to run the adstrall.sh script to start Apps services.

3. You will get an error “Cannot complete applications logon. You may have entered an invalid applications password, or there may have been a database connect error.”

4. Then try FNDCPASS to fix password and you will get the error the APP-FND-01496 error.

If this situation happens then you cannot access the application. Infact the services even wont start.

Resolution to such problem is to rollback the 2 tables FND_USER and FND_ORACLE_USERID. Once you rollback the tables, apps and applsys passwords will be in synch and password will be older one. You can then run FNDCPASS and change the password.

Scenario 2:

Some times when you run FNDCPASS, you get following error

APP-FND-01502: Cannot encrypt application ORACLE password
Cause: Application Object Library was unable encrypt your ORACLE password.
Action: Contact your support representative. (ORACLEUSER=APPS_SERV)

The error comes because the table fnd_oracle_userid contain rows for schemas that does not exist. Those rows must be deleted from the table.

Use the following query to get the details of the schema that doest not exists

select * from fnd_oracle_userid
where oracle_username not in
(select username from all_users);

The rows returned by this query can be deleted from FND_ORACLE_USERID table. This will resolve this issue.

Scenario 3:

There can be situation where users has update APPLSYS password using ALTER command in database directly and also you dont have backup of those tables. Under such situation, it is very difficult to recover the application and make it working. Still following methodology is proposed which might help you to restore the password back and make your application work fine.

For this to work you should have some other application (may be debug or UAT) which is having the same passwords or default passwords for schemas. If you have such application the following the below steps in the application which is affected by password mismatch.
This method is for resetting apps and applsys passwords. Below are the SQL statements that will help you reset the APPS and APPLSYS passwords to APPS, the APPLSYSPUB password to PUB, and the SYSADMIN password to SYSADMIN.

WARNING: This procedure will cause all user passwords to become invalid. ALL users passwords will need to be reset through the sysadmin responsibility.

Step 1) Reset the Oracle User IDs

Open a SQL*Plus as SYSTEM and reset the passwords for the APPS, APPLSYS, and the APPLSYSPUB Oracle user ID:

ALTER USER apps IDENTIFIED BY apps;
ALTER USER applsys IDENTIFIED BY apps;
ALTER USER applsyspub IDENTIFIED BY pub;

Step 2) Backup the FND_ORACLE_USERID and FND_USER tables (even though these tables are right now corrupted, do take a backup. You can restore the same when ever you want).

Open a SQL*Plus session as APPLSYS and backup the tables:

create table FND_ORACLE_USERID_BAK as (select * from FND_ORACLE_USERID);

create table FND_USER_BAK as (select * from FND_USER);

Step 3) Reset the APPS and APPLSYS application encrypted passwords

Open a SQL*Plus session as APPLSYS and update the FND_ORACLE_USERID table.

update FND_ORACLE_USERID
set ENCRYPTED_ORACLE_PASSWORD = ‘ZGA34EA20B5C4C9726CC95AA9D49EA4DBA8EDB705CB7673E645EED570D5447161491D78D444554655B87486EF537ED9843C8’
where ORACLE_USERNAME in (‘APPS’, ‘APPLSYS’);
commit;

This encrypted string we are updating is the default encrypted string for apps. So if your application is having apps password the encrypted string will look like this. We are updating this encrypted string here directly.

Verify the table update:

select ENCRYPTED_ORACLE_PASSWORD
from FND_ORACLE_USERID
where ORACLE_USERNAME IN (‘APPS’, ‘APPLSYS’);

Step 4) Reset the APPLSYSPUB application encrypted password

Open a SQL*Plus session as APPLSYS and update the FND_ORACLE_USERID table.

update FND_ORACLE_USERID
set ENCRYPTED_ORACLE_PASSWORD = ‘ZG31EC3DD2BD7FB8AD2628CE87DDDF148C1D2F248BE88BE987FDF82830228A88EF44BC78BC7A9FAD4BFB8F09DAD49DF7280E’
where ORACLE_USERNAME = (‘APPLSYSPUB’);
commit;

The above encrypted string is the encrypted string for password pub. If your applsyspub password is pub then the encrypted string in FND_ORACLE_USERID will look like this.

Verify the table update:

select ENCRYPTED_ORACLE_PASSWORD
from FND_ORACLE_USERID
where ORACLE_USERNAME = ‘APPLSYSPUB’;

Once these updates are done, try your luck by running FNDCPASS and it should work fine.

Hope this help !!!

References

Metalink note ID 445153.1

Metalink note ID 429244.1
Oracle Apps Technology Blog

Upgrading Jinitiator for Oracle Applications 11i

Published on February 4, 2008February 4, 2008 by Advait2 Comments

Oracle JInitiator is basically available on two streams of JDK for Oracle Applications 11i customers. One stream is based on Jinitiator version 1.1.8.X version and another stream is based on 1.3.1.X version. As JDK 1.1.8 has long been de-supported by Sun, Oracle will continue to provide critical updates to Jinitiator 1.1.8 through the de-support date for Release 11.0;

Oracle strongly recommends that Oracle Applications 11i customers move to the latest certified version of JInitiator 1.3.1.x. In some cases, migration to JInitiator 1.3.1.x requires additional technology upgrades.

Many a times you might face a situation where you need to upgrade your Jinitiator version to the latest version available. Also some times users are unable to open the forms. When they click on forms, system constantly ask for jinitiator upgrade, and even after upgrading the Jinititator system keeps on asking to install the same version again and again.

This happens because of fundamental reason — Your client system is not having correct version of Jinitiator then your application is at currently. Example the situation might be that your client PC is having a Jinitiator version of 1.3.1.18 where as your application expects a Jinitiator version of 1.3.1.25. In that case when you click on the forms window it will automatically ask you for installation of required Jinitiator version. But note that installation of required Jinitiator version is only one time job. Next time click on forms should open the forms window correctly.

Reason for asking to install Jinitiator repeatedly is that if your application system is not having a correct version of Jinitiator then it will prompt to install the highest available version with it. If this version happens to be lower version then the required then it will repeatedly as you to install the same Jinitiator version again and again.

This problem has two solutions. First solution is to download the correct version of Jinitiator manually and install in your client PC.

Another solution is to upgrade your Jinitiator version in application system. This will put the correct Jinit exe in your application which will be downloaded and installed first time when you click on forms. With proceeding clicks it will open up the forms correctly.

This post explains about upgrading Jinitiator version of your application system.

For more details, please refer to metalink note ID 124606.1.

Upgrading JInitiator for application system

For upgrading JInitiator version of your application, you need to apply 2 patches as given below depending on your Jinitiator current version.

JInitiator Version	JInitiator Patch	Interop Patch
1.3.1.29	6350285	6169479
1.1.8.27	6612584	6615232

In the JInitiator patch (6350285 or 6612584) , there will be jinit*.exe. You can extract this exe file by unzipping the patch.

Once the exe file is extracted, place the exe file at $COMMON_TOP/util/jinitiator/ directory. This is the place from where the jinitiator will be downloaded in your local client PC.

After placing the exe, apply the interop patch for the respective version using the following steps.

1) Apply the patch driver in the interop patch using AutoPatch.

2) Run the jinit.sh script from the <patch_top>/<interop_patch_number>/fnd/patch/115/bin/ directory, against the web node of your middle tie.

The usage of the script is

jinit.sh <jversion>

Example: jinit.sh 13129
(If you are upgrading to 1.3.1.29 version).

The script will return the appropriate file, or prompt you for the following values:

– Location of APPSORA.env file (This is located in APPL_TOP)

– Location of Context File (echo $CONTEXT_FILE will give the location of context file)

– Password for the APPS User in the database

This will make the necessary changes to the application system and JInitiator version is now upgraded.

You can bounce the services now and access the application. This will download the correct latest JInitiator version that you have upgraded to your local PC and it will install. You will be able to access the forms as well correctly.

You can verify the JInitiator version that you have upgraded by enabling the Jinitiator’s console as per the steps given in metalink note ID 124606.1.

Hope this helps !!

References:

Metalink note ID 124606.1

Changing Forms Servlet mode to Socket mode – E-Business Suite R12

Published on February 4, 2008February 4, 2008 by Advait1 Comment

In E-Business suite R12, by default we have forms servlet mode for opening up the forms. If we check the opmnctl for the OC4J forms services, the forms services are listed as shown below.

-bash-2.05b$ ./adopmnctl.sh status

You are running adopmnctl.sh version 120.4

Checking status of OPMN managed processes…

In servlet mode a java servlet called the Forms Listener Servlet manages the communication between the Forms Java Client and the OracleAS Forms Services. The Forms Listener Servlet communicates through the HTTP server port and does not need extra ports to handle the communication between the client and the Oracle Applicaiton Server Forms Services.

Although this is the preferred method for accessing the forms, in R12 one can also use socket mode connectivity for accessing the forms. In case of socket mode a separate port is configured for client to connect to the server. The connection is not made through Apache port. It means that in case the Apache services are down the forms services will be still up.

This may be required in the following situations:

Customers network topology is multinode and the forms Services are configured on a node different from the node on which Web services(Web Entry Point and Web Applications) are configured.
Customers constrained by network bandwidth, or machine resources may consider socket mode as an alternative to improve performance.
To reduce network traffic. The servlet mode uses http protocol on each transaction between a client and the Forms Server requiring the exchange of cookies and http headers which increases network traffic.
To reduce consumption of resources use by the JVMS needed in servlet mode architecture.

For difference between socket mode of Forms 6i and Forms 10g check metalink node ID 384241.1.

Enabling Forms Socket Mode

Changing forms servlet mode to forms socket mode is very easy. This needs running of just 1 script and bouncing the services.

Follow the below steps for changing from forms servlet mode to forms socket mode. Also note that both these modes cannot co-exits.

1) Stop all services using adstpall.sh present in $ADMIN_SCRIPTS_HOME location.

Note that while stopping this will call adformsctl.sh script for stopping forms services. This is because the current mode is servlet mode.

2) Run the following command to enable Forms Socket Mode:

$FND_TOP/bin/txkrun.pl -script=ChangeFormsMode \ [-contextfile=<CONTEXT_FILE>] \ -mode=socket \ [-port=<Forms port number>] \ -runautoconfig=<No or Yes> \ -appspass=<APPS password>

Example :

$FND_TOP/bin/txkrun.pl -script=ChangeFormsMode \ -contextfile=$INST_TOP/appl/admin/mycontext.xml \ -mode=socket \ -port=9095 \ -runautoconfig=Yes

In this case you can get the forms port number from context file.

Make sure that autoconfig has run successfully and that it has updated the forms launcher in database.

3) start the services using adstrtall.sh present in $ADMIN_SCRIPTS_HOME

Note that this time it will use adformsrvctl.sh script to start the forms. This is the script for starting forms in socket mode.

Executing service control script:
/slot02/appmgr/inst/apps/SCM3R3X3/admin/scripts/adformsrvctl.sh start
script returned:
****************************************************

You are running adformsrvctl.sh version 120.9.12000000.6

Starting FORMS Server in Socket Mode…

adformsrvctl.sh: exiting with status 0

adformsrvctl.sh: check the logfile /slot02/appmgr/inst/apps/SCM3R3X3/logs/ora/10.1.2/forms/socket.log for more information …

You have new mail in /var/spool/mail/appmgr02

.end std out.

.end err out.

After converting to forms socket mode the ICX_FORMS_LAUNCHER will take below form.

<web_protocol>://<web_host>.<web_domain>:<web_port>/OA_HTML/frmservlet

Also adopmnctl.sh will not list the forms process now.

-bash-3.00$ ./adopmnctl.sh status

You are running adopmnctl.sh version 120.4.12000000.3

Checking status of OPMN managed processes…

adopmnctl.sh: exiting with status 0

Hope this helps !!

References:

Metalink note ID 384241.1

Error while starting oacore in R12 – failure looking up ConnectionFactoryJndiName

Published on February 4, 2008 by Advait1 Comment

In case of E-Business suite R12, Some times if the services of middle tier is not stopped properly then there are changes that while bringing up the services it will fail with an error code of 204. Specially this is the case with oacore and oc4j process for forms.

Usually Apache wont cause any problem while coming up.

Following error can be seen in $INST_TOP/log/ora/10.1.3/opmn/oacore_default_group_1/oacorestd.err file.

==========================================================

08/02/03 21:39:32 Error: <connector name=”OracleASjms” path=”OracleASjms.rar” /> will not be bootstrapped since corresponding module declaration was not found in application.xml.
08/02/03 21:39:33 *** (SEVERE) Failed to set the internal configuration of the OC4J JMS Server with: XMLJMSServerConfig[file:/slot/ems1696/appmgr/inst/apps/mz2st121_rws60050rems/ora/10.1.3/j2ee/oacore/config/jms.xml]
08/02/03 21:39:34 Error initializing server: Error initializing ejb-modules: Resource exception(OracleASjms) for MessageDrivenBean event during endpoint activation: failure looking up ConnectionFactoryJndiName:jms/XAQueueConnectionFactory: javax.resource.spi.ResourceAdapterInternalException: Looking up jms/XAQueueConnectionFactory: javax.naming.NameNotFoundException: jms/XAQueueConnectionFactory not found
08/02/03 21:42:28 Error: <connector name=”OracleASjms” path=”OracleASjms.rar” /> will not be bootstrapped since corresponding module declaration was not found in application.xml.

==========================================================

When we start the services, a lock file will be generated for the process and this lock file will persist till the time services are up.

This is a “safety feature” within the lightweight (pure java) OC4J Java Messaging System (JMS) implementation. The OC4J Java Messaging System creates a lock file to constrain access to a specific persistent message store to the single OC4J instance that created it.

The persistence lock file captures information about the OC4J instance that owns or previously owned the persistence store and this information includes the IP address of the owning oc4j instance. During startup if the OC4J Java Messaging System (JMS) discovers that a persistence store it has been configured to use has a lock file that it doesn’t own it will abort the startup procedure to avoid data corruption.When we bring down the services, the lock file will be removed automatically.

Now when the services are not brought down gracefully then in that case the lock file will be still present and this file will create problem when we try to bring up the environment. Because for system, the message store is owned by some other OC4J instance and so it won’t allow any other OC4J instance to start the service.

Solution to this problem is to remove these lock files and start the service. Lock files will be present at the below locations.

In case of OACORE services, lock file will be present at $INST_TOP/ora/10.1.3/j2ee/oacore/persistence/oacore_default_group_1 directory.

Remove all the files under this directory and start the oacore service.

In case even the forms are not opening and giving the same error, then lock files for forms can be located at $INST_TOP/ora/10.1.3/j2ee/forms/persistence/forms_default_group_1 directory and all the files under this directory can be removed. Forms services will come up, once these lock files are removed.

Hope this helps.

References:

Metalink note ID 372412.1

Metalink note ID 398973.1