On one of Oracle Applications 11i cloned instance, OAM (Oracle Application Manager) was showing “Application System Name” as source Instance.
1. My first thought was to look at FND_NODES to see if any node entry still pointing to source instance. All records in this table were pointing to target instance.
If FND_NODES contain entry to source instance, I could have cleaned it using below methods
a)Login to sqlplus as user APPS
b) EXEC FND_CONC_CLONE.SETUP_CLEAN; (This procedure will delete all nodes from FND_NODES and related data in other tables)
c)Repopulate FND_NODES by running Autoconfig on all middle tier nodes (CM, Web Forms)
2. Next obvious thought was to look at profile option at Server, Responsibility level (During cloning only site level profile options are updated to target instance).
SQL> select PO.PROFILE_OPTION_NAME,PV.PROFILE_OPTION_VALUE, PV.LEVEL_ID
from fnd_profile_option_values pv, fnd_profile_options po
where upper(PROFILE_OPTION_VALUE) like ‘%&enter_source_in_UPPERCASE%’
In above query level_id represents following level
10001 – SITE
10002 – APP
10003 – RESP
10004 – USER
10005 – SERVER
10006 – ORG
10007 – ServerResponsibility
No profile option was pointing to source instance (I already changed workflow related profile options mentioned in post clone steps)
3. Googled to check if others encountered similar issue and I got one hit here but solution was to clone again and I wasn’t convinced
4. Next Step was to identify table and column name from where OAM (Oracle Application Manager) was populating “Application System Name” in Applications Dashboard & Site Map
SELECT table_name, column_name
–WHERE column_name LIKE ‘%’
After some permutations & combinations I reached to below query
SELECT table_name, column_name
WHERE column_name LIKE ‘APPLICATION%SYSTEM%NAME%’;
and output was
My immediate focus was on table AD_APPL_TOPS & FND_PRODUCT_GROUPS
Checked and found that APPLICATIONS_SYSTEM_NAME in FND_PRODUCT_GROUPS was pointing to source instance where as it should be same as SID.
Fix was simply to update table FND_PRODUCT_GROUPS like
Backup existing table as
SQL>create table FND_PRODUCT_GROUPS_BAK as select * from FND_PRODUCT_GROUPS;
Update table with target name
SQL> update FND_PRODUCT_GROUPS
set APPLICATIONS_SYSTEM_NAME = ‘<NEW DATABASE NAME>’ ;
5. Final hard thing to find was which step in cloning update this table so I started digging cloning log file.
– At one step cloning runs Autoconfig on target instance which runs script
$OAD_TOP/admin/install/$CONTEXT_NAME/adadmprf.sh (This script set profiles in database) and calls adadmprf.sql
This script does same as we did above and for some reason it failed during Autocnfig phase of Rapid Clone
REMREM Update FND_PRODUCT_GROUPS, if needed REM
declare statement varchar2(200); l_new_asn varchar2(30); begin if :fpg_has_column = 'TRUE' then l_new_asn := :new_apps_system_name;
statement := 'update fnd_product_groups '||
'set applications_system_name = :new_asn '|| 'where product_group_id = 1';
execute immediate statement using l_new_asn; end if; -- end if applications_system_name column
exists in fnd_product_groups end; /
6. Finally to ensure that every thing is correct I executed $OAD_TOP/admin/install/$CONTEXT_NAME/adadmprf.sh again,
Bounced Apache and Application System Name pointing to target insatnce this time.
230672.1 Cloning Oracle Applications Release 11i with Rapid Clone
165195.1Using AutoConfig to Manage System Configurations with Oracle Applications 11i
564112.1 A Number of Managers Show the Wrong Node Post Clone
213339.1 Adpatch Fails : ‘The Applications System names per the APPL_TOP and the database are different’
Oracle ACE, Author, Speaker and Founder of K21 Technologies & K21 Academy : Oracle Gold Partner specialising in Design, Implement, and Trainings.
Find Us On