How to Fix “Cannot identify any valid application tier nodes in ADOP_VALID_NODES table” in Oracle EBS R12.2

 

While applying patches on an Oracle E-Business Suite R12.2 environment using adop, I encountered the following fatal error during the patch apply phase.

The patching command was executed as below:

adop phase=apply patchtop=/u02/Patch/R12_2/APPS/R12.2.7 patches=25820806,25828573 hotpatch=yes merge=yes

After providing the required passwords for APPS, SYSTEM, and WLSADMIN, the ADOP session started validating credentials and initialized the run and patch edition context files.

However, the process failed with the following error:

*******FATAL ERROR*******
PROGRAM : (/u02/UAT/fs1/EBSapps/appl/ad/12.0.0/bin/adzdoptl.pl)
FUNCTION: ADOP::GlobalVars::_GetMandatoryArgs [ Level 1 ]

ERRORMSG: Cannot identify any valid application tier nodes in
ADOP_VALID_NODES table. Ensure AutoConfig has been run on all nodes.

ADOP also suggested running the log scanning utility:

adopscanlog -latest=yes

The patching session finally exited with:

adop exiting with status = 9 (Fail)

 

Cause

This issue normally occurs when ADOP is unable to find valid application tier node information in the required EBS metadata tables.

In Oracle EBS R12.2, ADOP depends on application node information stored in tables such as:

FND_NODES
FND_OAM_CONTEXT_FILES
ADOP_VALID_NODES
AD_APPL_TOPS

If these tables are not synchronized properly, or if AutoConfig has not updated the node information correctly for both Run and Patch file systems, ADOP may fail during initialization.

This issue is commonly seen after cloning, node cleanup, context file changes, or incomplete AutoConfig execution on the application tier.

 

 

Solution 1: Clean Node Information and Run AutoConfig

First, I connected to the database using the APPS user and executed the node cleanup procedure.

Important: Before running cleanup commands in any production environment, take backup of the related tables and validate the action with Oracle Support / your internal DBA standards.

sqlplus apps/<APPS_PASSWORD>
EXEC FND_CONC_CLONE.SETUP_CLEAN;
COMMIT;

After this, I ran AutoConfig on the database tier and application tier.

For EBS R12.2, make sure AutoConfig is executed properly for both file systems where applicable, especially if the issue is related to missing Run or Patch file system context entries.

 

Run AutoConfig on Database Tier

Source the database environment and run:

cd $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME
./adautocfg.sh

 

Run AutoConfig on Application Tier

Source the application environment and run AutoConfig:

cd $ADMIN_SCRIPTS_HOME
./adautocfg.sh

If you are working on an R12.2 dual file system environment, also verify that the Patch file system context is properly available and synchronized.

Once AutoConfig completed successfully, I restarted the failed ADOP session using the restart=yes option:

adop phase=apply patchtop=/u02/Patch/R12_2/APPS/R12.2.7 patches=25820806,25828573 hotpatch=yes merge=yes restart=yes abandon=no

 

 

Solution 2: Validate Synonyms and Node Metadata Tables

If the issue still persists after running AutoConfig, then validate the important EBS metadata tables and synonyms.

Connect as APPS and check the following:

select * from FND_OAM_CONTEXT_FILES;

select APPL_TOP_ID, NAME from AD_APPL_TOPS;

select * from FND_NODES;

In my case, the issue was related to incorrect or invalid synonyms for some EBS metadata objects. I recreated the required synonyms as below.

drop synonym apps.fnd_nodes;

create synonym apps.fnd_nodes for applsys.fnd_nodes;

drop synonym apps.fnd_oam_context_files;

create synonym apps.fnd_oam_context_files for applsys.fnd_oam_context_files;

After recreating the synonyms, I restarted the ADOP session again:

adop phase=apply patchtop=/u02/Patch/R12_2/APPS/R12.2.7 patches=25820806,25828573 hotpatch=yes merge=yes restart=yes abandon=no

This time ADOP was able to identify the valid application tier nodes and continued successfully.

 

Additional Validation Queries

Before restarting ADOP, it is better to validate whether the required node information is visible.

select node_name, server_id, support_cp, support_web, support_admin, support_forms
from fnd_nodes;

select name, path, status from fnd_oam_context_files;

select appl_top_id, name from ad_appl_tops;

You should confirm that the application node name, context file path, and APPL_TOP information are correct.

 

Important Notes

Do not directly execute cleanup commands in production without taking backups of the affected tables.

Recommended backup commands:

create table apps.fnd_nodes_bkp as select * from apps.fnd_nodes;

create table apps.fnd_oam_context_files_bkp as select * from apps.fnd_oam_context_files;

create table apps.adop_valid_nodes_bkp as select * from apps.adop_valid_nodes;

Also, always run:

adopscanlog -latest=yes

This helps identify the exact log file and error snippet generated during the failed ADOP session.