How to Delete Old (Inactive) Patches in Oracle 19c Using OPatch

How I Clean Up Old (Inactive) Patches in Oracle Using OPatch

If you have been consistently installing RUs on your Oracle Database, one of the things that will occur to you after some time is your Oracle Home being crammed with outdated patches.

They're not active anymore, but they're still lingering.

I ran into the same situation recently while checking one of our 19c environments. There were multiple old RUs lying around, and I thought it’s a good time to clean things up a bit.

Here’s how I usually handle deleting inactive patches using OPatch.

 

First, Check Your OPatch Version

Before doing anything, I always make sure OPatch is up to date. Some of these utilities won’t even work properly on older versions.

cd D:\oracle\product\19.3.0\dbhome_1\OPatch opatch version Make sure it’s 12.2.0.1.37 or higher. (In my case, it was 12.2.0.1.45, so good to go.)

 

Check What’s Actually Inactive

Next step is to see what patches are inactive. This command is quite handy:

D:\oracle\product\19.3.0\dbhome_1\OPatch>opatch util listorderedinactivepatches Oracle Interim Patch Installer version 12.2.0.1.45 Copyright (c) 2025, Oracle Corporation.  All rights reserved.     Oracle Home       : D:\oracle\product\19.3.0\dbhome_1 Central Inventory : C:\Program Files\Oracle\Inventory    from           : OPatch version    : 12.2.0.1.45 OUI version       : 12.2.0.7.0 Log file location : D:\oracle\product\19.3.0\dbhome_1\cfgtoollogs\opatch\opatch2025-09-05_09-50-10AM_1.log   Invoking utility "listorderedinactivepatches" List Inactive patches option provided   The oracle home has the following inactive patch(es) and their respective overlay patches:   The number of RU chains is  1   ***** There are 2 inactive RU patches in chain 1 -Inactive RU/BP 35046439:Windows Database Bundle Patch : 19.19.0.0.230418 (35046439), installed on: Fri Jul 28 10:22:30 GST 2023, with no overlays -Inactive RU/BP 36521936:Windows Database Bundle Patch : 19.24.0.0.240716 (36521936), installed on: Thu Oct 24 11:31:40 GST 2024, with no overlays -Active RU/BP 37486199:Windows Database Bundle Patch : 19.26.0.0.250121 (37486199), installed on: Sat May 17 10:22:50 GST 2025, with no overlays   OPatch succeeded.

 

There are 2 inactive RU patches in chain 1

-Inactive RU/BP 35046439: 19.19.0.0.230418
-Inactive RU/BP 36521936: 19.24.0.0.240716
-Active   RU/BP 37486199: 19.26.0.0.250121

So clearly:

• 2 old patches are inactive
• 1 is the current active RU

Pretty typical scenario after a couple of patch cycles.

 

Important Thing I Almost Missed Once

Now here’s something you should not ignore.

Oracle recommends keeping at least 2 inactive patches in the Oracle Home.

Why?
Because if something goes wrong and you need to rollback or investigate, having older patches helps.

So don’t just go and delete everything blindly.

 

Cleaning Up the Old Ones

To remove inactive patches, I use:

D:\oracle\product\19.3.0\dbhome_1\OPatch>opatch util deleteinactivepatches Oracle Interim Patch Installer version 12.2.0.1.45 Copyright (c) 2025, Oracle Corporation.  All rights reserved.     Oracle Home       : D:\oracle\product\19.3.0\dbhome_1 Central Inventory : C:\Program Files\Oracle\Inventory    from           : OPatch version    : 12.2.0.1.45 OUI version       : 12.2.0.7.0 Log file location : D:\oracle\product\19.3.0\dbhome_1\cfgtoollogs\opatch\opatch2025-09-05_09-50-50AM_1.log   Invoking utility "deleteinactivepatches" Inactive Patches Cleanup option provided Delete Inactive Patches .......   ***** There are 2 inactive RU patches in chain 1   ***** 1 inactive patches will be deleted -To be deleted inactive RU/BP 35046439:Windows Database Bundle Patch : 19.19.0.0.230418 (35046439), installed on: Fri Jul 28 10:22:30 GST 2023, with no overlays -To be retained inactive RU/BP 36521936:Windows Database Bundle Patch : 19.24.0.0.240716 (36521936), installed on: Thu Oct 24 11:31:40 GST 2024, with no overlays -Active RU/BP 37486199:Windows Database Bundle Patch : 19.26.0.0.250121 (37486199), installed on: Sat May 17 10:22:50 GST 2025, with no overlays   Do you want to proceed? [y|n] y User Responded with: Y Deleted RU/BP patch: 35046439   OPatch succeeded.

 

Notice something interesting here — even though there were 2 inactive patches, OPatch decided to delete only 1.

That’s because it automatically ensures the minimum required patches are retained.

I just confirmed with:

y

And that’s it:

Deleted RU/BP patch: 35046439

OPatch succeeded.

 

A Couple of Things I Always Keep in Mind

From experience, a few small precautions go a long way:

• I prefer doing this during a maintenance window (just to be safe)
• If it’s a critical system, I take a quick backup of Oracle Home
• Always check logs if something looks off:

%ORACLE_HOME%\cfgtoollogs\opatch

 

Final Thoughts

This is one of those small maintenance activities that’s easy to ignore, but it helps keep your environment clean.

Inactive patches don’t harm directly, but over time they just add clutter and confusion  especially when you’re troubleshooting or auditing patch levels.

 

How to Patch Oracle 19c to Release 19.29 – A Complete Step-by-Step Blog

 

How to Patch Oracle 19c to Release 19.29 – A Complete Step-by-Step Blog

 

Introduction

I recently had to patch one of my Oracle 19c databases from 19.28 to 19.29. As always, the goal was simple — stay secure, stable, and aligned with Oracle’s quarterly patch cycle. Since this is something we DBAs do every few months, I decided to write down the exact steps I followed. The procedures are the same for all 19c versions.

This is more than just a technical dump. I will walk through all the practical, step-by-step guide, including downloads, checks, patching, verification required for the patching.

Note: On production systems, please do not follow this mindlessly. Always apply on test/dev first!

 

How to Apply Oracle 19.29 Patch – Full Walkthrough

Let’s dive into the actual process.

---

1. Download the Patch and OPatch Utility

• Log in to Oracle Support using your org credentials.
• Select Patches & Product certification matrix from search box
• Provide patch no : 38291812 , 6880880
• Select your platform: For e.g. Linux x86-64
• Download & review the README file 
• Download:
• Patch file: p38291812_190000_Linux-x86-64.zip
• OPatch utility: p6880880_190000_Linux-x86-64.zip

 

  

2. Check and  update OPatch Utility

In the server:

[oracle@ocisoumya ~]$cd $ORACLE_HOME/OPatch [oracle@ocisoumya ~]$./opatch version

 You need version 12.2.0.1.48 or higher.

If it doesn’t show above version, update opatch

[oracle@ocisoumya ~]$mv OPatch OPatch_backup1 [oracle@ocisoumya ~]$cp p6880880_190000_Linux-x86-64.zip $ORACLE_HOME [oracle@ocisoumya ~]$cd $ORACLE_HOME [oracle@ocisoumya ~]$ unzip p6880880_190000_Linux-x86-64.zip

 

Update your .bash_profile to run opatch globally:

[oracle@ocisoumya ~]vi /home/oracle/.bash_profile PATH=$ORACLE_HOME/OPatch:$PATH :wq [oracle@ocisoumya ~]  . ~/.bash_profile

 

3. Prepare the Patch Directory

[oracle@ocisoumya ~]mkdir /home/oracle/patch [oracle@ocisoumya ~] chmod -R 777 /home/oracle/patch

 

Transfer both ZIP files (Patch + OPatch) to this directory using WinSCP or similar.

4. Unzip the Patch

[oracle@ocisoumya ~]cd /home/oracle/patch [oracle@ocisoumya ~]unzip p38291812_190000_Linux-x86-64.zip [oracle@ocisoumya ~]cd 38291812

 

5. Run Pre-checks

Before applying the patch, check for conflicts:

[oracle@ocisoumya ~] ./opatch prereq CheckConflictAgainstOHWithDetail -ph ./

 

If you see “Success”, you’re good to go.

6. Stop Database and Listener

[oracle@ocisoumya ~]sqlplus / as sysdba SQL> shutdown immediate SQL> exit [oracle@ocisoumya ~] lsnrctl stop

 

Verify that all services are down.

---

7. Clean Up Inactive Patches (Optional)

[oracle@ocisoumya ~]cd $ORACLE_HOME/OPatch [oracle@ocisoumya ~]./opatch util listOrderedInactivePatches [oracle@ocisoumya ~]./opatch util deleteInactivePatches

 

8. Make Sure You Have Enough Space

You’ll need at least 12 GB free in /home.

[oracle@ocisoumya ~] df -h

---

9. Apply the Patch

[oracle@ocisoumya ~]cd /home/oracle/patch/38291812 [oracle@ocisoumya ~] ./opatch apply

 

Watch for success messages during the patch process.

---

10. Run DataPatch

This registers the patch inside the database:

[oracle@ocisoumya ~]cd $ORACLE_HOME/OPatch [oracle@ocisoumya ~] ./datapatch -verbose

 

Start Database and Verify Patch

[oracle@ocisoumya ~]sqlplus / as sysdba SQL>startup SQL> select * from v$version; SQL> select * from dba_registry_sqlpatch;

 

You should see 19.29.0.0.0 listed in the output!

 

Final Tips

•  Always patch standby first in Data Guard setups.
•  Never patch production first — test on a non-prod clone.
•  Always read the README.
•  Share this guide if it helped!

 

How to Fix formsweb.cfg When Fusion Middleware Enterprise Manager Is Not Accessible

Recently for one of my customer  I ran into a tricky situation while Fusion Middleware Enterprise Manager (EM) 12c was completely inaccessible. Normally, any configuration changes in Oracle Forms, reports or for weblogic  we use Fusion Middleware Enterprise Manager (EM) . Our requirement was to update especially formsweb.cfg which generally is changed through EM. But when EM itself is down, we had to find a way out.

Below is exactly what we did to safely make the change and bring the environment back without causing configuration corruption.

 

Step 1 — Shut Down the Required Services

First, we stopped the Forms managed server and Admin Server to avoid any configuration lock or file corruption.

• Shutdown WLS_FORMS
• Shutdown Admin Server

 

Step 2 — Navigate to Domain Home

[appltest@testapp ~]$ cd $DOMAIN_HOME [appltest@testapp ~]$ pwd [appltest@testapp ~]$ /u01/app/oracle/product/12.2.1.4/user_projects/domains/prd

 

Step 3 — Clear Configuration Lock (edit.lok)

WebLogic sometimes leaves an edit session lock if a previous configuration change did not complete properly.

If the following file exists, remove it

[appltest@testapp ~]$  rm -rf edit.lok

 

Step 4 — Clear Pending Changes

WebLogic stores in-progress configuration updates inside a pending directory. If this folder contains files, the Admin Server assumes an edit session is still active.

Delete any files inside $DOMAIN_HOME/pending/*

[appltest@testapp ~]$ rm -rf $DOMAIN_HOME/pending/*

 

Step 5 — Clear Temporary and Cache Directories

To ensure a clean startup, we removed temporary and cache files. These directories will be recreated automatically when servers restart.

[appltest@testapp ~]$ $DOMAIN_HOME/servers/AdminServer/tmp/ [appltest@testapp ~]$ $DOMAIN_HOME/servers/WLS_FORMS/tmp/ [appltest@testapp ~]$ $DOMAIN_HOME/servers/WLS_FORMS/cache/

 

Step 6 — Edit formsweb.cfg Manually

After cleanup, we updated the required configuration directly in the file:

[appltest@testapp ~]$  vi $DOMAIN_HOME/config/fmwconfig/components/FORMS/instances/forms1/config/formsweb.cfg   userid=new_username/new_password@orcl

 

Step 7 — Restart serivces and Verify

1. Start the Admin Server
2. Wait until it reaches RUNNING state
3. Start Forms services and verify changes.

Dealing with the "Stuck" Workflow Mailer in EBS 12.2: A Practical Guide

 

We all have  seen something like this . We just finished a fresh clone from Production to Test. After the post-clone steps are done, the services are coming up, but then we found the Workflow Notification Mailer is stuck. Its stuck at starting phase.

In a recent project for one of our customer, we noticed this exact scenario. After a successful clone, the mailer was perpetually stuck in a "Starting" phase.

The Problem: New Credentials vs. Old State

After cloning, the Test environment still has the Production SMTP and IMAP settings. Naturally, you have to update these fields—changing the server name which should point to correct smtp address and a valid credential to match the test or your cloned instance mailboxes

The issue seems to be that the Workflow Mailer is trying to start using the new credentials that were recently updated, but it is getting confused because  it is still seeing the previous Running state and some old control messages that came along with the Production snapshot.

The Root Cause: "Identity Crisis"

When an EBS environment is cloned, the target database initially behaves as if it’s still part of the source system. Even after completing adcfgclone and AutoConfig, the Workflow Advanced Queues (AQ) may still retain references or cached state information from the Production environment.

In this situation, the Workflow Mailer was trying to initialize, but it was encountering leftover control messages and orphaned process IDs that did not exist on the new Test server, which prevented it from starting properly.

So here is how we resolved the problem:-

Clearing the Database Block

Our first approach was to manually reset the component status. However, the UPDATE statement became unresponsive, indicating that another session was holding a lock on the FND_SVC_COMPONENTS table.

So, we identified the blocking session and killed it at the database level.

Once the session was killed, lock was cleared, we successfully forced the status to 'STOPPED'

To check workflow mailer status:-

SQL> SELECT component_status FROM fnd_svc_components WHERE component_name = 'Workflow Notification Mailer';

Find out the session stuck with 'FND_SVC_COMPONENTS' component

SQL> SELECT     l.session_id AS blocking_session,     s.username,     s.osuser,     s.program,     s.status,     s.last_call_et AS seconds_in_wait FROM v$locked_object l JOIN v$session s ON l.session_id = s.sid WHERE l.object_id in (SELECT object_id FROM all_objects WHERE object_name = 'FND_SVC_COMPONENTS');

Kill the Session

If the above query shows any rows, it means a session is holding a lock and must be killed to release it. Use the SID and SERIAL# values from the query output and kill that session at the db level.

SQL> Alter system kill session ‘sid , serial#’ immediate;

Update the fnd_svc_components table forcefully as stopped.

SQL> UPDATE fnd_svc_components SET component_status = 'STOPPED' WHERE component_name = 'Workflow Notification Mailer';

Reset the main component status

SQL>UPDATE fnd_svc_comp_requests SET component_status = 'STOPPED' WHERE component_id = (SELECT component_id FROM fnd_svc_components WHERE component_name = 'Workflow Notification Mailer'); SQL> COMMIT;

Also, you must check at OS level. If there is a "zombie" process, the mailer will never start correctly even after the above update.

ps -ef | grep FNDCPGSC

If a process exists, use kill -9 <PID>.

 

Once above steps are done, try to Workflow notification mailer. It should get started.

Datapatch Fails in Oracle 12c on Windows – Root Cause and Step-by-Step Fix

  

Recently, while applying a patch on an Oracle 12c (12.2.0.1) database on Windows, I ran into a frustrating issue: datapatch kept failing with cryptic errors.

D:\oracle\product\12.2.0\dbhome\bin>D:\oracle\product\12.2.0\dbhome\OPatch\datapatch -verbose SQL Patching tool version 12.2.0.1.0 Production on Fri Sep 12 09:11:37 2025 Copyright (c) 2012, 2021, Oracle.  All rights reserved.   Log file for this invocation: D:\oracle\product\12.2.0\dbhome\cfgtoollogs\sqlpatch\sqlpatch_5332_2025_09_12_09_11_37\sqlpatch_invocation.log   Connecting to database... Connection using O/S authentication failed. Enter userid that can connect as SYSDBA: sys Enter password for sys: Connecting to database...OK   catconInit failed, exiting   Please refer to MOS Note 1609718.1 and/or the invocation log D:\oracle\product\12.2.0\dbhome\cfgtoollogs\sqlpatch\sqlpatch_5332_2025_09_12_09_11_37\sqlpatch_invocation.log for information on how to resolve the above errors.

After verifying the logs pointed to catcon.pl and sqlpatch_catcon_*.log,  the real culprit turned out to be something deceptively simple — the wrong SQL*Plus version was being used.

SQL*Plus: Release 10.1.0.5.0 - Production ORA-12560: TNS:protocol adapter error SP2-0640: Not connected

 

This was strange because I was patching a 12.2 database — why would it use a 10.1 client?

Root Cause:-

On Windows, datapatch invokes SQL*Plus internally via catcon.pl. It will pick up the first sqlplus.exe it finds in the system PATH.

To verify this I ran in cmd

D:\oracle\product\12.2.0\dbhome\bin>where sqlplus D:\oracle\product\12.2.0\dbhome\bin\sqlplus.exe  ← correct (12.2) D:\oracle\developer\BIN\sqlplus.exe  ← wrong (10.1, Oracle Developer 10g)

 

Since the Developer 10g client was earlier in the PATH, datapatch tried to use that. And of course, a 10g SQL*Plus cannot talk to a 12c database.

Solution:-

1. Quick Fix (per session)

Run these commands in your Command Prompt before executing datapatch:

set ORACLE_HOME=D:\oracle\product\12.2.0\dbhome set ORACLE_SID=ORCL set PATH=%ORACLE_HOME%\bin;%PATH%   cd %ORACLE_HOME%\OPatch datapatch -verbose

 

This forces Windows to use the 12.2 SQL*Plus first and the datapatch was successful.

 

2. Permanent Fix (system-wide)

• Go to System Properties → Environment Variables
• Edit the PATH variable

Move D:\oracle\product\12.2.0\dbhome\bin above: D:\oracle\developer\BIN   Or remove the old Developer path completely if you no longer need it.

How to Recreate the Patch File System in Oracle EBS R12.2 – Step-by-Step Guide

Env details:-

EBS Version: R12.2.5

AD/TXK Delta Patch level: 10

OS : OEL 7.9

Step 1: Source the Run Edition Environment

Before beginning, source the environment of the currently active run edition:

[appltest@testapp ~]$ . /apdata/erp/EBSapps.env run       E-Business Suite Environment Information   ----------------------------------------   RUN File System           : /apdata/erp/fs2/EBSapps/appl   PATCH File System         : /apdata/erp/fs1/EBSapps/appl   Non-Editioned File System : /apdata/erp/fs_ne       DB Host: testdb.suprajit.com  Service/SID: TEST       Sourcing the RUN File System ...

 

Step 2. Verify Admin Server Status:

[appltest@testapp ~]$ $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh status   You are running adadminsrvctl.sh version 120.10.12020000.10   Enter the WebLogic Admin password: Enter the APPS Schema password:    The AdminServer is not running

 

If not running, start it:

[appltest@testapp ~]$ $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start Enter the WebLogic Admin password: Enter the APPS Schema password: Starting WLS Admin Server...

 

 

 

Step 3. Execute Preclone on Apps Tier:

[appltest@testapp ~]$ cd $INST_TOP/admin/scripts [appltest@testapp scripts]$ perl adpreclone.pl appsTier

 

Step 4: Detach Existing Patch Oracle Homes

Navigate to the OUI Binary Directory:

[appltest@testapp scripts]$  cd $FMW_HOME/oracle_common/oui/bin

 

This step is performed from the RUN file-system which will detach oracle_homes on the PATCH file-system

Replace {oracle_home_path} with the actual paths:

Please note that we are removing ORACLE_HOME registered with patch file system only.

 

./runInstaller -detachhome ORACLE_HOME={oracle_home_path} -silent

 

For example:

[appltest@testapp bin]$ ./runInstaller -detachhome ORACLE_HOME=/apdata/erp/fs1/FMW_Home/Oracle_EBS-app1 -silent   [appltest@testapp bin]$ ./runInstaller -detachhome ORACLE_HOME=/apdata/erp/fs1/FMW_Home/webtier -silent   [appltest@testapp bin]$ ./runInstaller -detachhome ORACLE_HOME=/apdata/erp/fs1/FMW_Home/oracle_common -silent

 

 

Remove the 10.1.2 Oracle Home

[appltest@testapp bin]$ ./runInstaller -removeHome ORACLE_HOME=/apdata/erp/fs1/EBSapps/10.1.2 -silent

 

Step 5: Replicate Run File System to Patch File System

Ensure Run Environment is Down (optional but recommended):

[appltest@testapp bin]$ $ADMIN_SCRIPTS_HOME/adstpall.sh

 

 

Copy directories from RUN to Patch filesystem

[appltest@testapp bin]$ cd $RUN_BASE [appltest@testapp fs2]$ pwd /apdata/erp/fs2 [appltest@testapp fs2]$ ls EBSapps  FMW_Home  inst [appltest@testapp fs2]$ cp -r EBSapps /apdata/erp/fs1/

 

Remove Existing FMW_Home in Patch File System:

[appltest@testapp]$  rm -rf /apdata/erp/fs1/FMW_Home

 

Step 6: Disable ebs_logon Trigger

Connect to the Database:

[oratest@testdb ~]$ sqlplus / as sysdba   SQL> ALTER TRIGGER system.ebs_logon DISABLE;   Trigger altered.

 

Step 7: Configure the Patch File System

Login to application server and open a new termina.

Unset any application environment file

Navigate to Clone Directory:

[appltest@testapp ~]$ cd /apdata/erp/fs1/EBSapps/comn/clone/bin/ [appltest@testapp bin]$ perl adcfgclone.pl appsTier                        Copyright (c) 2002, 2015 Oracle Corporation                         Redwood Shores, California, USA                           Oracle E-Business Suite Rapid Clone                                    Version 12.2                         adcfgclone Version 120.63.12020000.60                   ***********************************************************                 In AD-TXK Delta 7, we recommend you clone the run and patch                 file systems in a single operation using the 'dualfs' option.                 Separate cloning of the run and patch file systems will be deprecated                 ************************************************************   Enter the APPS password :   Enter the Weblogic AdminServer password :   Do you want to add a node (yes/no) [no] :     Running: Context clone...   Log file located at /apdata/erp/fs1/EBSapps/comn/clone/bin/CloneContext_0607140046.log   Target System File Edition type [run] : patch   Enter the full path of Run File System Context file : /apdata/erp/fs2/inst/apps/TEST_testapp/appl/admin/TEST_testapp.xml   Provide the values required for creation of the new APPL_TOP Context file.   Target System Fusion Middleware Home set to /apdata/erp/fs1/FMW_Home   Target System Web Oracle Home set to /apdata/erp/fs1/FMW_Home/webtier   Target System Appl TOP set to /apdata/erp/fs1/EBSapps/appl   Target System COMMON TOP set to /apdata/erp/fs1/EBSapps/comn   Target System Instance Top set to /apdata/erp/fs1/inst/apps/TEST_testapp   Target System Port Pool [0-99] : 21

  

During the prompts:

• Add a Node: no
• Run File System Context File: Provide the absolute path.
• Port Pool: Choose a value different from the run file system (e.g., if run uses 0, patch can use 10).

Step 8: Verify File System Roles

 

[appltest@testapp bin]$ source /apdata/erp/EBSapps.env patch   [appltest@testapp bin]$ echo $FILE_EDITION Patch

 

Step 9: Synchronize File Systems Using fs_clone

[appltest@testapp bin]$ source /apdata/erp/EBSapps.env run   [appltest@testapp scripts]$ adop phase=fs_clone force=yes

 

This step ensures both file systems are in sync.

 

Step 10: Re-enable ebs_logon Trigger

[oratest@testdb admin]$ sqlplus / as sysdba   SQL> ALTER TRIGGER system.ebs_logon enable;

 

Conclusion

Recreating the patch file system in Oracle EBS R12.2 is a meticulous process that ensures the integrity and availability of your application. By following these steps diligently, you can maintain a robust environment ready for online patching and minimal downtime.

 

 

 

Fixing adcfgclone.pl Failure in EBS R12.2 Due to Registered Oracle Homes

 

Error Message

While running adcfgclone.pl on the application tier run file system during a fresh EBS R12.2 clone, the following error occurred:

Below Oracle Homes are already registered in the inventory: /apdata/erp/fs2/FMW_Home/Oracle_EBS-app1 /apdata/erp/fs2/FMW_Home/webtier /apdata/erp/fs2/FMW_Home/oracle_common  Exiting Cloning...  Ensure that the above Oracle Homes are unregistered from the inventory "/apdata/oraInventory/ContentsXML/inventory.xml" and re-run adcfgclone.pl script

 

Root Cause

The error is self-explanatory: the listed Oracle Homes are already registered in the Oracle Inventory (inventory.xml), which conflicts with the clone process.

This often happens when:

• A previous clone attempt was incomplete.
• The file system was restored or copied from another instance without unregistering Oracle Homes.

 

Solution: Unregister the Oracle Homes

To resolve the issue, you need to unregister the listed Oracle Homes from the global inventory using runInstaller.

🔹 Step-by-Step Instructions

1. Log in to the application server as the OS user (e.g., appltest).
2. Navigate to the oui/bin directory under $FMW_HOME:

Login to application server    [appltest@testapp ]$ cd $FMW_HOME/oui/bin

 

In this example, $FMW_HOME is /apdata/erp/fs2/EBSapps/10.1.2

3.      Run the following commands to remove each of the registered homes from inventory:

[appltest@testapp ]$./runInstaller -silent -deinstall REMOVE_HOMES={"/apdata/erp/fs2/FMW_Home/Oracle_EBS-app1"}   [appltest@testapp ]$./runInstaller -silent -deinstall REMOVE_HOMES={"/apdata/erp/fs2/FMW_Home/webtier"}   [appltest@testapp ]$./runInstaller -silent -deinstall REMOVE_HOMES={"/apdata/erp/fs2/FMW_Home/oracle_common"}

 

Each command will unregister one Oracle Home from the central inventory without actually deleting the directory or binaries.

 

Final Step

After unregistering the Oracle Homes successfully, re-run the Application Tier clone:

[appltest@testapp ] $COMMON_TOP/clone/bin/adcfgclone.pl appsTier

 

This time, the script should proceed without encountering the registration error.