adop "fs_clone" Failures in Oracle EBS R12.2 — Common Causes and Fixes

If you've worked with Oracle E-Business Suite R12.2's online patching (ADOP) for any length of time, you've probably hit a failure during the fs_clone phase at least once. It's one of the most common places adop breaks — and one of the most confusing, because the error messages don't always point you to the real root cause.

This post walks through why fs_clone exists, what it actually does, and the most frequent reasons it fails, along with practical fixes.

1. What Is fs_clone and When Do You Run It?

In R12.2's dual file system architecture, you have two complete copies of the application tier — fs1 and fs2 — so patching can happen on the idle file system while the other stays live. adop phase=fs_clone is the step that synchronizes the patch file system with the run file system after a patching cycle completes, or before a new node (like a DMZ node) is added.

You typically run it:

• After completing a full adop cycle (prepare → apply → finalize → cleanup)
• Before cloning the application tier to a new node
• When the two file systems have drifted out of sync and need to be realigned

Important

Always complete cleanup_mode=full before running fs_clone. Skipping cleanup is the single most common cause of fs_clone failures.

 2. Common Cause #1: Skipped or Incomplete Cleanup

If a previous adop cycle wasn't fully cleaned up — meaning adop phase=cleanup cleanup_mode=full was never run, or it failed midway — the patch file system still has leftover state from the last cycle. Running fs_clone on top of that inconsistent state is asking for trouble.

Fix: Run a full cleanup cycle before attempting fs_clone again:

$ adop phase=cleanup cleanup_mode=full

$ adop phase=fs_clone

Check the cleanup log under $APPL_TOP/admin/<SID>/log to confirm it completed without errors before moving forward.

3. Common Cause #2: Filesystem Space Issues

fs_clone copies large volumes of data between file systems. If the destination file system (fs2, typically) doesn't have enough free space, the clone will fail partway through — often with a generic I/O or copy error that doesn't immediately say "disk full."

Fix:

• Check available space on both fs1 and fs2 before starting: df -h
• EBS R12.2 application tiers generally need significant headroom (tens of GB free) for clone operations — check Oracle's sizing guidance for your specific version
• Clear out old log files, temp patch directories, and stale .adop workspaces if space is tight

Tip

Don't just check the mount point — check the actual partition $APPL_TOP and $COMMON_TOP reside on. A full root partition can silently fail operations that look unrelated.

4. Common Cause #3: Locked or Running Application Services

fs_clone expects application services to be in the correct state. If services are still running on the file system being cloned from, or a previous adop session wasn't closed properly, the clone process can hang or fail with lock-related errors.

Fix:

• Confirm no adop session is currently active: adop -status
• Stop application services cleanly before retrying if instructed by the error log
• If a stale adop session is stuck, check ad_adop_sessions in the database and consult MOS before manually clearing session state — don't do this blindly on production

5. Common Cause #4: Database Connectivity or TNS Issues

Since fs_clone interacts with the AD schema to track patching state, a database connectivity hiccup mid-process — a dropped TNS connection, a database bounce, or a network blip — can leave the clone in a broken, partially-completed state.

Fix:

• Verify TNS connectivity from the apps tier before starting: tnsping <db_alias>
• Check the database alert log for any unexpected restarts during the clone window
• If the clone fails due to a DB issue, don't just rerun blindly — check the adop log first to see exactly which step failed before retrying

6. Common Cause #5: Out-of-Sync Context Files

If the run and patch context files have drifted — say, a manual edit was made to one but not the other, or AutoConfig wasn't run consistently — fs_clone can fail validation checks partway through.

Fix:

$ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE

$ sh adautocfg.sh

Run this on both file systems before attempting fs_clone again, and avoid manual context file edits outside of AutoConfig wherever possible.

Summary

Most fs_clone failures trace back to one of five things: incomplete cleanup, insufficient disk space, locked sessions or running services, database connectivity blips, or out-of-sync context files. Read the adop.log first, fix the root cause, and only then retry. Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.

Oracle Fusion Is Upgrading to OCI IAM

If you manage Oracle Fusion Applications — whether that's ERP, HCM, CX, or SCM — your identity and access management layer is getting a significant upgrade. Oracle is migrating all Fusion environments from the legacy identity service to Oracle Cloud Infrastructure Identity and Access Management (OCI IAM), and this change requires your attention before the scheduled downtime window.

1. What Is Actually Changing?

The identity service that handles authentication, sign-on policy, single sign-on (SSO), multifactor authentication (MFA), and user lifecycle management for your Fusion Applications environments is being replaced with OCI IAM — Oracle's modern, cloud-native identity platform.

This is not a minor configuration tweak. It is a one-time mandatory upgrade with downtime. Once complete, your Fusion environments will gain the latest capabilities for enterprise identity management, including improved MFA controls, federated SSO policies managed directly from the OCI Console, and fine-grained identity domain administration.

Important If your Fusion Applications environment family was provisioned after April 6, 2025, you are already running on OCI IAM. This upgrade does not apply to you.

2. Who Needs to Act — and When?

The urgency of your required actions depends on whether your Fusion environments are configured with federated SSO. Here is a quick overview:

No Federated SSO No pre-upgrade actions required. Oracle handles everything. Monitor the schedule from the OCI Console and verify user sign-in after the upgrade.

Federated SSO Enabled Action required at least 72 hours before each environment's downtime. Missing this deadline breaks SSO for all users after upgrade.

Fusion as Identity Provider Apps like Taleo, CPQ, or SelectMinds using Fusion as IdP require post-upgrade tasks to restore their sign-in flow.

3. How You Will Be Notified — Timeline

90 days before	Email notification sent if any of your environments have federated SSO configured.
30 days before	Email notification sent if none of your environments have federated SSO.
10+ days before	Recommended window to begin and complete pre-upgrade tasks, leaving time to troubleshoot.
72 hrs before	Hard deadline. Pre-upgrade tasks must be acknowledged for each scheduled environment, including production.
During upgrade	Environments are unavailable. Expected downtime is up to 3 hours or longer, depending on user count.
Post-upgrade	Email confirmation sent. Post-upgrade tasks required for environments with downstream SSO dependencies.

4. Pre-Upgrade Steps for Federated SSO Environments

Oracle automatically creates the required identity providers in your environment's associated identity domain once it is scheduled. You do not need to create them manually — but you must complete and test the configuration.

Warning Do not delete the Oracle-created identity providers from the identity domain. Doing so prevents you from completing the pre-upgrade tasks.

Step 1: Download the SAML metadata file — In the OCI Console, navigate to your Fusion environment family → Maintenance → Identity upgrade. Select your federated SSO environment, then choose Pre-upgrade actions and download the Metadata.xml file. Each file is unique to each environment — label them carefully if you have multiple.

Step 2: Configure a new service provider in your corporate IdP — Open the SAML metadata file and use its contents to create a new service provider in your corporate identity system (Azure AD, Okta, ADFS, etc.). This does not affect the existing service provider — your current SSO continues to work during this step. Download the SAML metadata from the new service provider once configured.

Step 3: Update and test identity providers in OCI IAM — Back in the OCI Console, import the SAML metadata from your corporate IdP into the OCI IAM identity provider. Then run the test sign-in flow — sign in to the identity domain first using a local administrator account (not the SSO button), then authenticate to your corporate IdP. A successful result shows "Your connection is successful."

Step 4: Acknowledge identity provider readiness — Only after all test sign-ins succeed, check the acknowledgment box in the Pre-upgrade actions panel and submit. The status changes to Completed. Do not add new identity providers in the Security Console after acknowledging — doing so resets your acknowledgment.

Tip Oracle estimates about one hour to complete and test pre-upgrade tasks per federated SSO environment, assuming administrator permissions are in place. Budget time to obtain Domain Administrator access to each Fusion identity domain before you start.

5. What Happens After the Upgrade?

Once Oracle completes the upgrade and notifies you by email, verify that your users can sign in to each Fusion environment. Then complete the following:

✔     Verify user sign-in works for both SSO and non-SSO flows.

✔     For OIC integrations using OAuth Authorization Code Credentials with a non-Fusion identity domain, reconfigure the OAuth security policy to use a Fusion identity domain instead.

✔     For Taleo, CPQ, or SelectMinds using Fusion as SSO IdP, download new SAML metadata and update identity provider configuration in those apps.

✔     Test SSO sign-in for all dependent applications before acknowledging post-upgrade task completion in the OCI Console.

✔     Replace Sign In/Sign Out Audit REST API usage with OCI Audit reports — the Fusion audit API is not available post-upgrade.

✔     Review and reapply any custom default password policies. Changes may not survive the upgrade — this is a known issue.

6. Key Things That Are Not Changing

Amid all the change, the following remain exactly the same:

•        Your Fusion Applications sign-in URL remains unchanged.

•        Existing federated SSO configuration is preserved — same identity providers continue to be used.

•        Password policies managed via the Fusion Security Console remain intact.

•        The Security Console is not removed — user management, password resets, and role assignments continue there.

•        Non-SSO (username/password) access for supplier portals and similar use cases continues to work.

•        There is no cost change or subscription change associated with the upgrade.

7. Scheduling, Cancellations, and Opt-Outs

The identity upgrade is scheduled separately from quarterly Fusion updates — it will not appear in the same month as your quarterly patch. Non-production environments are upgraded in the second week of the scheduled month; production environments go in the fourth week.

You cannot opt out of the upgrade. If your scheduled window conflicts with a critical business event, you can submit an Oracle Support Request to request rescheduling, but approval is not guaranteed. Act early if you foresee a conflict.

If Oracle cancels a scheduled upgrade for any reason, the acknowledgment of pre-upgrade tasks is reset. You will need to redo and re-acknowledge those tasks once a new date is confirmed.

8. Practical Recommendations

Check your schedule now

Log into the OCI Console → Environment families → Maintenance → Identity upgrade to see your current upgrade status and scheduled timeline for each environment.

Get admin access early

Ensure you have Domain Administrator access to each Fusion identity domain before starting pre-upgrade tasks. Password resets and role assignments can take time and may require coordination with other teams.

Map your dependencies

Identify all apps using Fusion as their SSO identity provider. Check the Integrated Applications section in the identity domain once your upgrade is scheduled in the Console.

Start 10 days early

Oracle recommends completing pre-upgrade tasks at least 10 days before the first environment's scheduled downtime — not just 72 hours — to allow adequate time for troubleshooting.

Don't touch SSO config after acknowledging

Once you've acknowledged pre-upgrade readiness for a Fusion environment, do not add or modify identity providers in the Security Console. Any such changes reset the acknowledgment and require you to complete and re-acknowledge all pre-upgrade tasks.

 

Summary This upgrade is mandatory for all Fusion Applications environments provisioned before April 6, 2025. Federated SSO customers must complete pre-upgrade tasks at least 72 hours (ideally 10 days) before each scheduled environment's downtime. The upgrade window is up to 3 hours. There is no cost impact, and most existing configurations are preserved.

 Resources

•        Oracle Docs: Identity Upgrade Overview — docs.oracle.com/en-us/iaas/Content/fusion-applications/identity-migration-overview.htm

•        Oracle Docs: IAM with Identity Domains — docs.oracle.com/iaas/Content/Identity/home.htm

•        Oracle Docs: Federating with Identity Providers —docs.oracle.com/iaas/Content/Identity/federating/federating_section.htm

•        Oracle Docs: Identity Upgrade Checklist — docs.oracle.com/en-us/iaas/Content/fusion-applications/identity-migration-checklist.htm

•        Oracle Support: Submit a Support Request for rescheduling — docs.oracle.com/iaas/Content/GSG/Tasks/contactingsupport.htm

 

EDBPC utility in Oracle E-Business Suite R12.2

Checking Your EBS Database Parameters the Right Way (Don’t Skip This)

If you’ve been managing Oracle E-Business Suite for any length of time, you already know that database initialization parameters can silently ruin your day. Wrong value, missing parameter, outdated setting from three upgrades ago — and suddenly you’re chasing a performance issue or an apply failure that makes no obvious sense.

Oracle actually ships a utility specifically for this. It’s called the EBS Database Parameter Checker (EDBPC), and if you’re not running it regularly, you probably should be.

What EDBPC Actually Does

It’s a Perl script. Simple concept — it reads your current database initialization parameters and compares them against Oracle’s own recommended list (documented in MOS article KA1002). Then it spits out a report telling you what’s missing, what’s wrong, and what needs fixing.

No drama. No automatic changes. It just tells you where you stand.

This matters because Oracle updates its parameter recommendations over time — especially after major database releases. What was fine on 19c at go-live might be missing a recommended setting after a few RUs. EDBPC catches that drift before it catches you.

Applicable to: EBS R12.2 with Oracle Database 19c and later, running on a single PDB in a CDB — whether single instance or RAC.

Before You Run It — A Few Things Worth Knowing

First, always grab the latest version. The patch number is 36625551 on My Oracle Support. Older versions of EDBPC don’t check newer parameters, so running an outdated copy gives you a false sense of confidence. Not ideal.

Second — yes, it’s safe to run against production. The utility uses no DML and runs no ALTER commands on its own. It generates scripts for you to review and run yourself. That’s the right approach.

Third, don’t treat this as a one-time thing. Run it as part of your regular maintenance cycle — before upgrades, after applying RUs, or just quarterly as a sanity check.

Running It — Straightforward

Once you’ve downloaded and unzipped the patch, you’ll have three files:

•        EDBPC.pl — the main script

•        inputFile.txt — the recommended parameter list it checks against

•        README.txt — worth a quick read

Log in as the DB Oracle home owner, source your PDB environment file, then run it. You have two options:

Non-interactive (pass the context file directly):

$ perl EDBPC.pl -dbcontextfile=<full path to DB context file>

Interactive (it will prompt you):

$ perl EDBPC.pl

Either way, it creates a zip file when it finishes — named with a timestamp and hostname so you can keep track of runs over time.

What You Get in the Output

Extract the zip and you’ll find four files:

File	Description
EDBPC_Report.html	Main validation report — open this first
alter_sql_cdb.sql	ALTER statements for CDB-level parameters that failed
alter_sql_pdb.sql	ALTER statements for PDB-level parameters that failed
EDBPC.log	Run log — use if anything looks off

The HTML report is genuinely readable. It lists each parameter that failed validation with a recommended corrective action alongside it.

One thing to be careful about: review the ALTER scripts before running them. They’re generated based on what the utility found, but you still need to understand what’s being changed — especially on production. Test on a non-prod instance first, always.

Bottom Line

EDBPC isn’t glamorous. It’s a Perl script that checks a text file against your database. But in practice, it saves you from the kind of subtle, slow-burn issues that come from parameter drift over years of upgrades and patching.

Run it. Keep the latest version. Make it part of your maintenance routine.

Reference: MOS KA1180 for the latest version of this article, MOS KA1002 for the full recommended parameter list.

Setting Up a DMZ in Oracle E-Business Suite

What is a DMZ and Why Does EBS Need One?

A DMZ (Demilitarized Zone) is a secure buffer network positioned between the public internet and your internal corporate network. In Oracle E-Business Suite (EBS), implementing a DMZ allows you to safely expose selected web-facing services—such as iProcurement or supplier portals—to external users, without granting them direct access to your internal application or database servers.

Without a DMZ, enabling external access would require exposing the entire EBS environment to the internet, which significantly increases security risks. By introducing a DMZ:

• External users connect only to the web tier hosted in the DMZ, not to internal application servers.
• Critical components such as the database and concurrent managers remain securely protected behind internal firewalls.
• Even if the DMZ layer is compromised, the internal network and core systems remain isolated and secure.

Architecture Overview

The three-tier DMZ layout for Oracle EBS R12.2 looks like this:

 

Internet / External Users

→

DMZ Node (Web Tier)

→

Internal App + DB Tier

 

In this guide, the example nodes are:

•        Primary Apps Node: appsserver.test.com

•        DMZ Apps Node:     dmzserver.test.com

Prerequisites

Note :- Complete all three prerequisites on every node before starting the setup steps below. Skipping any of these is a common source of errors during cloning.

1.  Add host entries in all three /etc/hosts files — on the Primary DB node, Primary App node, and the DMZ node — so each node can resolve the others by hostname.

2.  Ensure the APPS and Oracle OS user and group IDs are identical across all nodes. Mismatched IDs cause permission errors when copying file systems.

3.  Enable password less SSH between the application tier nodes.

Step-by-Step Setup

STEP 1    Clean Up and Sync the File System (adop cycle)

Start on the Primary Apps Node. Run a complete adop cleanup cycle to ensure both file systems are in a consistent, clean state before cloning anything across to the DMZ.

$ . /u01/R12_2/APPFS/EBSapps.env run $ adop phase=prepare $ adop phase=finalize $ adop phase=cleanup cleanup_mode=full $ adop phase=fs_clone

 

Note :- Do not skip this step. A dirty or inconsistent file system is the most common reason adcfgclone fails during DMZ setup.

STEP 2    Switch Profile Hierarchy Type to SERVRESP

 

DMZ configuration in EBS R12.2 requires profile options to be managed at the Server-Response (SERVRESP) level. This allows different profile values — like different URLs — to be set per node, which is essential for routing internal vs. external traffic correctly.

 

Run the following SQL script on the Primary Node:

$ . /u01/R12_2/APPFS/EBSapps.env run $ sqlplus apps/'apps_password' \   @$FND_TOP/patch/115/sql/txkChangeProfH.sql SERVRESP

You will see confirmation messages for each profile option being updated, for example:

Profile APPS_WEB_AGENT hierarchy type changed to SERVRESP Profile APPS_FRAMEWORK_AGENT hierarchy type changed to SERVRESP Profile APPS_SERVLET_AGENT hierarchy type changed to SERVRESP Profile ICX_FORMS_LAUNCHER hierarchy type changed to SERVRESP

 

STEP 3    Run Preclone on Both File Systems

 

Run adpreclone.pl on both the run and patch file systems on the Primary Apps Node. This prepares the file system metadata for cloning.

Run File System:

$ . /u01/R12_2/APPFS/EBSapps.env run $ cd $ADMIN_SCRIPTS_HOME $ perl adpreclone.pl appsTier

 Patch File System:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ cd $ADMIN_SCRIPTS_HOME $ perl adpreclone.pl appsTier

 

STEP 4    Back Up the Run File System and Copy It to the DMZ Node

 

Create a compressed archive of the run file system on the Primary App Node, then transfer it to the DMZ server using scp.

 On the Primary Node — create and copy the backup:

$ cd /u01/R12_2/APPFS/fs1 $ tar -cvzf appnode1backup.tar.gz EBSapps/ $ scp appsbackup.tar.gz \   applmgr@dmzserver.test.com:/u01/R12_2/APPFS/fs1

 On the DMZ Node — extract the backup:

$ cd /u01/R12_2/APPFS/fs1/ $ tar -xvf appsbackup.tar.gz

STEP 5    Run adcfgclone on the DMZ Node to Register It as a New Node

 

This is the core configuration step. First, start the Patch FS Admin Server on the Primary Node:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ $INST_TOP/admin/scripts/adadminsrvctl.sh start forcepatchfs

 Then, on the DMZ Node, run adcfgclone:

$ cd /u01/R12_2/APPFS/fs1/EBSapps/comn/clone/bin $ perl adcfgclone.pl appsTier dualfs

 

When prompted, respond as follows:

•        Enter APPS password and WebLogic AdminServer password when asked.

•        Answer yes to 'Do you want to add a node?'

•        Confirm the hostname as: dmzserver

•        Accept default paths for all file system directories.

•        Keep same port values as the source system: y

•        When asked to start application services: answer n (do not start yet)

 

Note :- adcfgclone script will display all target directory paths for confirmation before proceeding. Verify the DMZ hostname and paths are correct before continuing.

STEP 6    Stop Primary Patch Admin Server, Run AutoConfig, and Start Services

 

On the Primary Node — stop the patch FS admin server:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ $INST_TOP/admin/scripts/adadminsrvctl.sh stop

 On the DMZ Node — sync context file, run AutoConfig, start services:

$ . /u01/R12_2/APPFS/EBSapps.env run $ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh $ sh adstrtal.sh apps/apps

 Upload the patch context file from DMZ node:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ $ADJVAPRG oracle.apps.ad.autoconfig.oam.CtxSynchronizer \    action=upload contextfile=$CONTEXT_FILE \   logfile=/tmp/patchctxupload.log

 On the Primary Node — sync context and run AutoConfig:

$ . /u01/R12_2/APPFS/EBSapps.env run $ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh

 

Finally, bounce the services on the Primary Node to complete the configuration sync.

STEP 7    Set Profile Options to Mark the DMZ Node as External

 

Log in to EBS using the internal URL as SYSADMIN. Navigate to System Administrator > Profile > System.

Node Trust Level:

Query for the profile option Node Trust Level. At the server level, set it to External for the DMZ server (dmzserver.test.com). Leave the site-level value as Normal.

 Responsibility Trust Level:

For each responsibility you want to expose externally, set the Responsibility Trust Level profile option to External at the responsibility level. Common externally accessible responsibilities include:

 

Product	Responsibility	Additional Profile
iSupplier Portal	iSupplier Portal	POS: External URL, POS: Internal URL
Oracle Sourcing	Sourcing Supplier	PON: External Applications Framework Agent
Oracle iProcurement	Self Registered Employee Default Responsibility	ICX_FORMS_LAUNCHER

 

Note:- Only expose responsibilities that are explicitly needed for external access. Exposing unnecessary responsibilities increases your attack surface.

Managing Services Across All Nodes

Once the DMZ is configured, use these commands from the Primary Node to manage services on all nodes simultaneously:

Start all nodes (including DMZ):

$ sh adstrtal.sh apps/apps_password -mode=allnodes

Stop all nodes:

$ sh adstpall.sh apps/apps_password -mode=allnodes

Firewall Ports to Open

Ensure the following ports are open between your DMZ and internal network zones:

Port	Protocol	Purpose
1571	TCP	Oracle DB listener (DMZ to DB tier)
22	TCP	SSH between app tier nodes
7051 / 7052	TCP	WebLogic Admin Server (HTTP/HTTPS)
8001 / 4443	TCP	OHS Web Entry Point (HTTP/HTTPS)
6701 / 6702	TCP	WebLogic Node Manager

Summary

You have now configured a DMZ for Oracle EBS R12.2. The DMZ node acts as a secure external web entry point. Your internal application and database tiers remain safely behind the firewall. External users access only the responsibilities you have explicitly marked as External via the Node Trust Level and Responsibility Trust Level profile options.

 

Key reference documents:

•        MOS KA1036 — Oracle E-Business Suite R12 Configuration in a DMZ

https://support.oracle.com/ic/builder/rt/customer_portal/live/webApps/customer-portal/?kmContentId=11172164

•        MOS KB503850 — External Access URLs Redirecting to Internal Servers

https://support.oracle.com/ic/builder/rt/customer_portal/live/webApps/customer-portal/?kmContentId=2135366

Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.