Could not start Service Manager FNDSM_

CM.... Wake Up... Wake Up...

Issue: CM not cmg up after JDK upgrade to 1.6.0_18. Got the below err in Log

Starting STANDARD Concurrent Manager               : 25-OCT-2010 10:29:42

Could not start Service Manager FNDSM_APPSDBAEXPERTS_TEST1. The TNS alias could not be located, the listener process on APPSDBAEXPERTS could not be contacted, or the listener failed to spawn the Service Manager process.

Routine AFPEIM encountered an error while starting concurrent manager STANDARD with library /test1/applmgr/11510/fnd/11.5.0/bin/FNDLIBR.

Check that your system has enough resources to start a concurrent manager process. Contact your system administrator : 25-OCT-2010 10:29:42

                     Process monitor session ended : 25-OCT-2010 10:29:42

Sol:

-- From the error we thought its issue with tnsfiles. Found some differences ( as we ran autoconfig ), so restored the backup files and retried bringing up the CM.

   But still CM is not happy to come Up :-)

-- Then we thought of relinking FND executables will solve the issue. But..still CM is said NO..

-- We found Note 470100.1 with exact error ( But this note mostly appeals post clone issue where fnd_nodes table contains non-existent nodes info ).

   Note says:
  1. Execute FND_CONC_CLONE.SETUP_CLEAN

  2.  Run AutoConfig on DB.

  3.  Run AutoConfig on MT

  4.  Retest CM

   -- Tried this...thinking may b it will work.... CM said.. Wat U think I am...? I am not gng to get convinced doing something or the other...

-- Finally.....

   We got the Exact Hit...

   Note 423170.1

   As per this note the issue is bec of FNDSM coredump issue.

   try,

   $ cd $FND_TOP/bin

   $ FNDSM

   Segmenation Fault

   -- In gen.. we should not get any o/p at all if tht is good.

   -- It's exactly the same issue in our case.

   Action Plan:-

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

   1. Apply patch 3830807: " PATCH 3293983 NEEDS TO INCLUDE ALL THE MAKEFILES UNDER THE 8.0.6 ORACLE_HOME".

   2. Relink all executables using adadmin.

   3. Retest CM.

   Note: The Concurrent Manager should start without any errors. There should be no errors in the 8.0.6 listener log file.

--- Finally, Our CM is very much Happy 2 come Up... nd It Came Up......... :-)

--- Actually this issue has been fixed by my frd..nd collegue Srini :-) bef him.. lot of trail nd errors done for many hrs..bt he fixed..in a fly... :-)

Bye..Guys..

K I R A N...

Prod patching taking v long time compared to Non Prod

Issue: In Prod, Patching taking v long time compared to Non Prod.

          Checked the system load and all. All are normal. Still we are facing performance issue.

Sol : After doing lot of R & D we got one reason y this might be happening in PROD.

In PROD:

SQL> select count(*) from dba_tables where last_analyzed < sysdate-30;

COUNT(*)

----------

20000

In Non PROD:

SQL> select count(*) from dba_tables where last_analyzed < sysdate-30;

COUNT(*)

----------

500

--- there are many tables with statistic older than 30 days on PROD.

--- We thought of running GSS in parallel to patching ( In our cases we had still around

     20hrs more work of patching. So, it worth running GSS since there is a long work to complete )

--- Since running GSS will also take long time nd consume lot of resources, better run

     GSS for identified Shemas for which you are about to patch next

--- In our case we are about to proceed with HRMS patching.. So we ran GSS for HR

     and AR modules and proceeded with patching.

   

     as SYS

     exec dbms_stats.gather_schema_stats(ownname=> 'HR' , estimate_percent=> 25 ,degree=>8);

     exec dbms_stats.gather_schema_stats(ownname=> 'AR' , estimate_percent=> 25 ,degree=>8);

           

Also.. It will be much helpful..if U too can update on perfomance issues which U faced while patching.

This will help a lot bec...most of the times we will fall short of downtime.. in tht cases we can have some options to go for...

Thanks,

K K K...Kiran :-)

ORA-03113 ORA-01041 ORA-07445

Hi Team,

Very Nice to C Erros nd Sol's --- next 2 each Other :) like best frds :)

Now, I'm gng to introduce one more Err-Sol frds...

Issue:

While applying a patch its failed compiling a pkb by worker with below error

SQL> @/appsdba_experts/applmgr/11510/pqp/11.5.0/patch/115/sql/pqpospfn.pkb

CREATE OR REPLACE PACKAGE BODY pqp_gb_osp_functions AS
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel

ERROR:
ORA-01041: internal error. hostdef extension doesn't exist

-- Tired compiling from another session..it failed again..with same error
-- Checked the staus of pks,pkb both r invalid.
-- In alert logfile we found 'ORA-07445' when we r trying to compile.

ORA-07445: exception encountered: core dump [kgldtf()+8] [SIGSEGV] [ADDR:0x0] [PC:0x26412A4]


Sol:

Run DB revalidation.

- Stard DB in Upgrade Mode
- run utlirp.sql
- run utlrp.sql

- Compiled the package now. Got compiled.

Note : 1. to speed up the utlrp.sql process ( for us it took total 7 hrs for revalidation, which is not acceptable in most of the cases ) please set job_queue_processes to recommended values other than 0 , after compilation revert back to original value.
2. We tried lot of work arounds to avoid 7-8hrs loss but nothing worked. Finally we came to conclusion that this is the only way...even though its a long way ( Naa Daaari...Rahadari..Better c:)me in my Way :)... Tht's wat DB said )
3. Along with this we have few other packages failed with similar error

Cause : Error is raised due to inconsistencies in the data dictionary between objects and their dependencies and that likely the inconsistency exists before patching is started.

Will meet U again..with new Err-Sol frds's

Bye..

Key+Run ....

Register concurrent program with request group.

Most of us came across a situation where
after defining(promoting) a concurrent program ,to make other users be able to
run the program we need to add the program to a request group(which we used to
do by navigation through security->responsibility->Request).
The same can be achieved by running package FND_PROGRAM as foloows.

DECLARE
BEGIN
FND_PROGRAM.add_to_group
(
PROGRAM_SHORT_NAME =>'XX_XXXXXX'
,PROGRAM_APPLICATION =>'AR'
,REQUEST_GROUP =>'Receivables All'
,GROUP_APPLICATION =>'AR'
) ;
commit;
exception
when others then
dbms_output.put_line('Object already exists');
END ;
/