Cleaning up the FND_NODES Table.

After a clone, you may notice that FND_NODES still contains entries for the source system. You may also see the same thing if you relocate services to a new node. You can query FND_NODES but an easy way to see this is via OAM (Oracle Applications Manager) on the opening overview screen:

(Hostnames blanked for obvious reasons..)



This particular environment has a single application tier and database tier, which means there are 7 extra rows. Note:260887.1 details how to clean up the FND_NODES table (11.5.10-12.0.x) and its very easy to do if your on the latest TXK Autoconfig rollup patch.

Here are the steps:

• Verify you have at least the TXK AUTOCONFIG ROLLUP PATCH Q (JUL/AUG 2007), patch number 5985992. My environment is a bit out of date so I applied the latest rollup patch S from April/May 2008, patch number 6372396. Personally, if a patch has been replaced I try to go with the latest unless there are too many pre-requisites. In the past i've been bitten by applying the minimum requirement only to have to apply the latest version a little while later. So if its not much more effort, it makes sense to do it.
  
  • The patch took about 2 hours to apply.
    
  • NOTE: Make sure you review the README file for this patch. If you have manually added product tops you may need to apply another patch. As well there are a few post-steps but the main one is to refresh the RDBMS AutoConfig files:
    

    
    Create the appsutil.zip file by executing:
     $ADPERLPRG $AD_TOP/bin/admkappsutil.pl
     (On Windows: %ADPERLPRG% %AD_TOP%\bin\admkappsutil.pl)
     This will create appsutil.zip in $APPL_TOP/admin/out .
    

    
    Copy/ftp the appsutil.zip file to your RDBMS server and:
    

    
    cd $ORACLE_HOME
    unzip -o appsutil.zip
    execute AutoConfig:
     $ORACLE_HOME/appsutil/scripts/<context_name>/adautocfg.sh
    

  
  
  
• From sqlplus execute the following command:
  
  SQL> EXEC FND_CONC_CLONE.SETUP_CLEAN;
  COMMIT;
  
  This deletes data from a few FND tables such as FND_NODES but after AutoConfig has been executed they will contain the correct values.
  
• Run AutoConfig ($COMMON_TOP/admin/scripts/<context_name>/adautocfg.sh) on each tier.
  
• Startup the environment.
  

You should now have a nice and clean FND_NODES table:



So why would you want to do this? Personally it just annoyed me seeing incorrect values in OAM. As well, seeing production information in a cloned environment always makes me uneasy. There are other reasons as to why you would want to or may have to do this. If you search Metalink for FND_CONC_CLONE.SETUP_CLEAN you will get a couple of dozen hits. Quite a few notes are related to cloning, clean up or services not starting properly.

There you go, now you have a nice clean FND_NODES table!