Saturday, September 11, 2010

Concurrent Manager's not starting after Cloning

Once after doing Rapid cloning some of concurrent managers were not starting. The issue was that the node was wrongly defined as source node in Administer Manager screen. I then checked the FND_NODES table which wrongly had the source nodes as well apart from the target nodes.
I performed the following action plan which resolved the issue->
  • Shutdown the apps services
  • EXEC FND_CONC_CLONE.SETUP_CLEAN;
    COMMIT;
    EXIT;
  • Ran AutoConfig on all tiers, firstly on the DB tier and then the APPS tiers.
  • Start the apps services
Actually FND_CONC_CLONE.SETUP_CLEAN clears up the tables with nodes information and when we run autoconfig, it repopulates these tables with correct node information.
The metalink note-Note:732709.1 describes this issue.

4 comments:

Unknown said...

We have to execute 'FND_CONC_CLONE.SETUP_CLEAN' on apps tier or db tier.
If we're executing this on apps then what is the need of running autoconfig on db tier. Please explain as i'm unable to understand the concept.

Unknown said...

and please tell me what this PL/SQL procedure will do?
will it clean concurrent manager tables?

Oracle Applications DBA said...

Hi Ankur,

First of all the above mentioned procedure needs to be executed in APPS schema under db-tier. Why because as you cloned the instance from PROD/QA Instances the respective nodes details will not be wiped out automatically unless you execute the mentioned procedure and it will even reflect in the cloned instance.

So inorder to clean those fnd_nodes details we need to run the procedure in apps schema.

SQL>show user;
"APPS"
SQL> EXEC FND_CONC_CLONE.SETUP_CLEAN;
COMMIT;
EXIT;

Now after executing the above procedure Run AutoConfig on all tiers, firstly on the DB tier and then the APPS tiers, to repopulate the
required system tables.

Unknown said...

Thanks Bhaiya for the detailed explanation it really helped me.

Post a Comment