Wednesday, 19 March 2014

getaddrinfo(localhost, NULL, 1) failed (Name or service not known): No such file or directory

During the start up of middle tier services opmn was failed to start with the below error.

When attempting to start up the R12 middle tier services, the following error occurs.

ERROR

getaddrinfo(localhost, NULL, 1) failed (Name or service not known): No such file or directory
getaddrinfo(localhost, NULL, 1) failed (Name or service not known): No such file or directory
getaddrinfo(localhost, NULL, 1) failed (Name or service not known): No such file or directory
opmnctl: opmn start failed.

The issue can be reproduced at will with the following steps:
1. Apply R12 prerequisites
2. Install R12 using Rapid wizard
3. Startup middle tier services.

CAUSE

The hosts file does not contain the localhost entry needed for loopback
127.0.0.1 localhost.localdomain

SOLUTION

To implement the solution, please execute the following steps:

1. Modify hosts file and add localhost entry to look like below (example for Linux):

127.0.0.1 localhost.localdomain localhost
Note: For other platforms please check how the hosts entries should look like in the platform specific "Oracle Applications Installation and Upgrade Notes Release 12" note.


Start middle tier services.


Reference:
http://crescentitsme.blogspot.com/2014/01/getaddrinfolocalhost-null-1-failed-name.html

Saturday, 1 March 2014

Size of Oracle Applications R12 increasing rapidly

There can be number of reasons behind the rapid increase of oracle applications, few of them are listed below which I encountered.

CASE I:

There might be some sort of logging/ debugging enabled in system. You can check them from following queries.

Profiles 'Utilities: SQL Trace' and 'Concurrent: Allow Debugging' are set on site and user levels. If they are set, disable them.

select p.profile_option_name SHORT_NAME,
n.user_profile_option_name NAME,
decode(v.level_id,
10001, 'Site',
10002, 'Application',
10003, 'Responsibility',
10004, 'User',
10005, 'Server',
10007, 'SERVRESP',
'UnDef') LEVEL_SET,
decode(to_char(v.level_id),
'10001', '',
'10002', app.application_short_name,
'10003', rsp.responsibility_key,
'10005', svr.node_name,
'10006', org.name,
'10004', usr.user_name,
'10007', 'Serv/resp',
'UnDef') "CONTEXT",
v.profile_option_value VALUE
from fnd_profile_options p,
fnd_profile_option_values v,
fnd_profile_options_tl n,
fnd_user usr,
fnd_application app,
fnd_responsibility rsp,
fnd_nodes svr,
hr_operating_units org
where p.profile_option_id = v.profile_option_id (+)
and p.profile_option_name = n.profile_option_name
and p.profile_option_name in
('SQL_TRACE', 'FND_CONC_ALLOW_DEBUG')
and usr.user_id (+) = v.level_value
and rsp.application_id (+) = v.level_value_application_id
and rsp.responsibility_id (+) = v.level_value
and app.application_id (+) = v.level_value
and svr.node_id (+) = v.level_value
and org.organization_id (+) = v.level_value
order by short_name, level_set;

Run the sql below to check if any concurrent program is trace enabled on concurrent program define form. If there are any, un-check the flag on the concurrent program define form.

select application_id,
concurrent_program_name,
last_update_date,
last_updated_by
from fnd_concurrent_programs
where enable_trace = 'Y';

Connect SQLPLUS with command as below with DB user(e.g. oravis):

>sqlplus /nolog
SQL> conn / as sysdba
SQL> show parameter user_dump_dest

The returned directory will store ALL .trc & .trm file, this may cause increase size rapidly.

CASE II:

Size of core files might increasing path of which is: "/opt/oracle/PROD/inst/apps/PROD_prodapps/ora/10.1.2/forms"

So according to support note
Note 1331304.1: Forms Core Dump Files generated in E-Business Suite R12 (Doc ID 1331304.1)

 Edit context parameter value "s_forms_catchterm"
FROM
<FORMS_CATCHTERM oa_var="s_forms_catchterm">1</FORMS_CATCHTERM>
TO
<FORMS_CATCHTERM oa_var="s_forms_catchterm">0</FORMS_CATCHTERM>


Run Autoconfig to make change effective.

FORMS_CATCHTERM. This variable enables or disables the Forms abnormal termination handler which captures middle tier crashes and writes diagnostic information into the dump file or the forms server log file. Allowed values are {0,1}. By default, this value is set to '1' which enables the Forms termination handler. Setting this variable to '0' disables the Forms termination Handler.

So, set it to 0 is to disable the Forms termination Handler.


You can remove those core files as they are not needed, because they are OK to remove. You can just use OS command to delete them.

Moreover,
Note 356878.1: R11i / R12 : How to relink an E-Business Suite Installation of Release 11i and Release 12.x (Doc ID 356878.1)

Another oracle support note was found in this regard if above solution doesn't work.

Note 1194383.1: R12: Frequent frmweb core files created in $INST_TOP/ora/10.1.2/forms (frmweb core dumps) (Doc ID 1194383.1)
to apply Patch 8940272 - MULTIPLE CORE DUMPS FOUND DURING LOAD TESTING.


You can apply with command:
>opatch apply
You also can rollback it with command:
>opatch rollback -id 8940272