How to Rebuild or Recreate Oracle E-Business Suite Concurrent Manager – Complete Oracle Apps DBA Troubleshooting Guide

📅 Last Updated: August 2026

This guide has been completely reviewed and updated for Oracle E-Business Suite 11i, R12.1, and R12.2. It covers Oracle Concurrent Processing architecture, Internal Concurrent Manager (ICM), Standard Manager, Service Manager (FNDSM), clone recovery, AutoConfig, FND_NODES cleanup, Concurrent Manager recreation, production troubleshooting, Oracle Apps DBA best practices, and real-world production case studies.

Oracle Concurrent Manager is one of the most critical components of Oracle E-Business Suite. It is responsible for processing background jobs, scheduled requests, reports, workflow activities, XML Publisher reports, payroll programs, financial processes, and many other business-critical operations.

When the Concurrent Manager becomes corrupted, fails to start, or is improperly cloned, users may be unable to submit concurrent requests, existing requests may remain in a pending state indefinitely, and essential business processes can come to a complete halt.

Although many administrators immediately attempt to restart the Concurrent Manager, production environments often require a deeper investigation involving Internal Concurrent Manager (ICM), FNDSM, FND_NODES, AutoConfig, clone cleanup, and Concurrent Processing configuration.

This guide explains how Oracle Concurrent Processing works, why Concurrent Manager corruption occurs, and the production-tested procedures used by experienced Oracle Apps DBAs to rebuild or recreate Concurrent Manager safely.

Quick Solution

Verify that the Internal Concurrent Manager (ICM), Service Manager (FNDSM), and Standard Manager are running correctly. Check FND_NODES, review Concurrent Manager log files, execute FND_CONC_CLONE.SETUP_CLEAN when recovering cloned environments, run AutoConfig, recreate Concurrent Manager components if necessary, and validate all application tier services before returning the system to production.

Typical Symptoms

Administrators typically encounter one or more of the following symptoms:

Concurrent Manager will not start.
Pending requests never begin processing.
Requests remain in Pending/Standby status.
Internal Concurrent Manager terminates unexpectedly.
Standard Manager is down.
FNDSM cannot be started.
Concurrent requests fail immediately.
Managers disappear after cloning.
Managers remain inactive after AutoConfig.
Application users cannot run reports.

Related Errors

Concurrent Manager not running
Internal Concurrent Manager terminated unexpectedly
Service Manager FNDSM failed to start
Pending requests remain inactive
Target node is unavailable
FND_NODES inconsistency detected
APP-FND errors during Concurrent Processing
AutoConfig configuration mismatch
Clone-related Concurrent Manager failure

What is Oracle Concurrent Manager?

Oracle Concurrent Manager is the background processing framework used by Oracle E-Business Suite to execute scheduled and asynchronous workloads.

Instead of running long-running jobs interactively, Oracle EBS submits requests to Concurrent Processing, allowing users to continue working while reports, interfaces, imports, exports, payroll calculations, workflow activities, and other processes execute in the background.

Each Concurrent Manager has a specific responsibility and works together under the control of the Internal Concurrent Manager.

Oracle Concurrent Processing Architecture

A simplified Concurrent Processing architecture is shown below:

User Request

      │

      ▼

Concurrent Request Tables

      │

      ▼

Internal Concurrent Manager (ICM)

      │

      ▼

Service Manager (FNDSM)

      │

      ▼

Standard Manager

      │

      ▼

Specialized Managers

      │

      ▼

Executable Program

      │

      ▼

Output / Log File

A failure anywhere in this processing chain can prevent concurrent requests from executing successfully.

Major Concurrent Manager Components

Internal Concurrent Manager (ICM)

The Internal Concurrent Manager is the master controller of Oracle Concurrent Processing. It starts, stops, monitors, and restarts all other Concurrent Managers.

Standard Manager

The Standard Manager executes most concurrent requests submitted by Oracle E-Business Suite users.

Service Manager (FNDSM)

FNDSM manages application tier services and enables communication between Concurrent Processing and application tier components.

Specialized Managers

Specialized Managers process workload for specific application modules such as Inventory, Workflow, Payroll, XML Publisher, and custom concurrent programs.

Business Impact

Concurrent Manager failures affect nearly every Oracle E-Business Suite module.

Business impact includes:

Financial reports cannot be generated.
Payroll processing stops.
Inventory interfaces fail.
Workflow notifications are delayed.
Order processing is interrupted.
Scheduled maintenance programs do not execute.
Nightly batch jobs fail.
Business users experience significant downtime.

Common Root Causes

Incomplete clone cleanup.
Incorrect FND_NODES entries.
Corrupted Concurrent Manager configuration.
Service Manager (FNDSM) not running.
Internal Concurrent Manager failure.
AutoConfig inconsistencies.
Pending Active Concurrent Managers.
Application tier hostname changes.
Corrupted context files.
Missing Concurrent Manager executables.
Shared filesystem inconsistencies.
Failed application patches.
Database connectivity problems.
Application tier service failures.

Where Should You Start?

Rather than immediately recreating Concurrent Manager components, first determine which part of the Concurrent Processing framework is failing.

Is the Internal Concurrent Manager running?
Is FNDSM active?
Is the Standard Manager available?
Were the issues introduced after cloning?
Was AutoConfig executed recently?
Are FND_NODES entries correct?
Were application tier hostnames changed?
Do Concurrent Manager log files contain startup errors?
Can requests be submitted but not processed?
Are only specific managers affected?

Answering these questions before making changes significantly reduces downtime and prevents unnecessary recreation of Concurrent Manager components.

Production Oracle Apps DBA Recommendation

Treat Concurrent Manager failures as infrastructure issues rather than isolated process failures. Verify ICM, FNDSM, FND_NODES, AutoConfig configuration, application tier services, and clone status before rebuilding or recreating Concurrent Manager components.

Step-by-Step Production Troubleshooting

When Oracle Concurrent Manager fails to start or process requests, the goal is to identify which component of the Concurrent Processing framework is failing. In most production environments, the problem is caused by configuration inconsistencies, clone-related issues, node registration problems, or middleware service failures rather than corruption of the Concurrent Manager itself.

Step 1 – Verify Concurrent Manager Status

Begin by determining whether the Internal Concurrent Manager (ICM) and other managers are running.

Navigate to:

System Administrator
↓

Concurrent
↓

Manager
↓

Administer

Verify:

Internal Concurrent Manager
Standard Manager
Conflict Resolution Manager
Service Manager (FNDSM)
Specialized Managers

If multiple managers are down, continue with infrastructure-level troubleshooting.

Step 2 – Verify Internal Concurrent Manager (ICM)

The Internal Concurrent Manager controls all other Concurrent Managers.

If the ICM is not running:

Review ICM log files.
Verify database connectivity.
Confirm application tier services are operational.
Check for recent configuration changes.

Without ICM, no Concurrent Manager can function correctly.

Step 3 – Verify Service Manager (FNDSM)

FNDSM manages communication between Concurrent Processing and the application tier.

Verify:

FNDSM process is running.
Hostname matches the registered node.
Application tier services are active.
No listener or networking issues exist.

If FNDSM is unavailable, Concurrent Managers may remain inactive even when the database is healthy.

Step 4 – Validate FND_NODES

Incorrect or duplicate entries in FND_NODES are one of the most common causes of Concurrent Manager failures after cloning or hostname changes.

Verify registered nodes:

SELECT node_name,
       support_cp,
       support_forms,
       support_web
FROM fnd_nodes;

Confirm that:

Only valid application nodes are registered.
Old hostnames have been removed.
The current node is enabled for Concurrent Processing.

Step 5 – Execute Clone Cleanup

If the environment was recently cloned, clean the existing Concurrent Processing configuration before recreating managers.

Run:

EXEC FND_CONC_CLONE.SETUP_CLEAN;
COMMIT;

This procedure removes obsolete clone information and prepares the environment for regeneration.

Step 6 – Run AutoConfig

After cleaning clone-related configuration, regenerate Oracle E-Business Suite configuration files.

Execute:

adautocfg.sh

Review the AutoConfig log carefully and resolve any template generation failures before proceeding.

Step 7 – Recreate FNDSM (If Required)

If the Service Manager is missing or incorrectly configured after cloning, recreate it using Oracle-supported procedures.

After recreation:

Run AutoConfig.
Restart application tier services.
Verify FNDSM registration.

Step 8 – Use CMCLEAN (When Appropriate)

If Concurrent Managers remain in Pending, Active, or inconsistent states after an abnormal shutdown, Oracle's CMCLEAN utility can be used to remove stale process information.

Before using CMCLEAN:

Ensure all Concurrent Managers are stopped.
Back up the database.
Follow Oracle support recommendations.

Avoid running CMCLEAN while managers are actively processing requests.

Step 9 – Relink Concurrent Manager Executables

Following operating system upgrades or incomplete patching, Concurrent Manager executables may require relinking.

Typical command:

adrelink.sh force=y

Relink only when recommended by Oracle documentation or Oracle Support.

Step 10 – Restart Concurrent Processing

After completing validation and configuration steps, restart Concurrent Processing and verify that all managers start successfully.

Confirm:

ICM is running.
FNDSM is active.
Standard Manager is processing requests.
Specialized Managers start normally.
New requests complete successfully.

Real Production Case Study

After cloning an Oracle E-Business Suite R12.2 production environment to a test server, no Concurrent Managers would start.

ICM repeatedly failed during startup, while FNDSM reported that the registered application node could not be found.

Investigation revealed obsolete entries in FND_NODES from the production environment.

The Oracle Apps DBA executed FND_CONC_CLONE.SETUP_CLEAN, ran AutoConfig on both database and application tiers, restarted services, and verified node registration.

After the cleanup, all Concurrent Managers—including the Internal Concurrent Manager, Standard Manager, and specialized managers—started successfully, and concurrent requests processed normally.

Oracle Apps DBA Investigation Checklist

Verification	Status
Concurrent Manager Status Verified	☐
Internal Concurrent Manager Checked	☐
FNDSM Verified	☐
FND_NODES Reviewed	☐
Clone Cleanup Completed	☐
AutoConfig Executed	☐
FNDSM Recreated (If Required)	☐
CMCLEAN Used (If Applicable)	☐
Executables Relinked (If Required)	☐
Concurrent Managers Restarted	☐
Concurrent Requests Tested Successfully	☐

Oracle E-Business Suite Version Considerations

Although the Concurrent Processing framework performs the same core function across Oracle E-Business Suite releases, the underlying middleware architecture and administration tools differ between versions.

Oracle EBS Version	Architecture	Concurrent Manager Considerations
Oracle EBS 11i	Oracle Application Server, Forms Services	Verify Concurrent Managers, FNDSM, Apache, and node registration.
Oracle EBS R12.1	Oracle Application Server with AutoConfig	Validate AutoConfig, FND_NODES, clone cleanup, and manager configuration.
Oracle EBS R12.2	Oracle HTTP Server (OHS), Oracle WebLogic Server, Online Patching	Verify OHS, WebLogic, FNDSM, AutoConfig, dual file systems, and online patching configuration.

CPADMIN Utility (Supported Releases)

Recent Oracle E-Business Suite releases provide the CPADMIN utility for administering Concurrent Processing. Depending on the release and administrative task, CPADMIN can simplify the management of Concurrent Managers compared to older methods.

Typical administrative operations include:

Viewing Concurrent Manager status.
Starting or stopping managers.
Managing manager definitions.
Monitoring Concurrent Processing.

Always use the administration utility recommended for your Oracle EBS release and apply Oracle Support guidance before making production configuration changes.

Best Practices for Oracle Apps DBAs

Run AutoConfig after approved configuration changes.
Verify FND_NODES after every clone or hostname change.
Keep Internal Concurrent Manager healthy and monitor its log regularly.
Validate FNDSM after patching or cloning.
Monitor pending concurrent requests proactively.
Back up context files before major maintenance.
Avoid manual modifications to AutoConfig-managed configuration files.
Verify Concurrent Manager functionality after every patch cycle.
Maintain adequate database resources for concurrent processing.
Document all Concurrent Manager configuration changes.

Common Administrator Mistakes

Recreating Concurrent Managers before identifying the root cause.
Ignoring FND_NODES inconsistencies after cloning.
Skipping AutoConfig after configuration changes.
Using CMCLEAN while managers are still running.
Ignoring Internal Concurrent Manager log files.
Restarting services repeatedly without reviewing logs.
Failing to validate FNDSM after cloning.
Not testing concurrent requests after maintenance.
Overlooking application tier hostname mismatches.
Applying patches without validating Concurrent Processing.

Useful Oracle Apps DBA Commands

Check FND_NODES

SELECT node_name,
       support_cp,
       support_forms,
       support_web
FROM fnd_nodes;

Clone Cleanup

EXEC FND_CONC_CLONE.SETUP_CLEAN;
COMMIT;

Run AutoConfig

adautocfg.sh

Relink Application Executables

adrelink.sh force=y

Check Concurrent Manager Processes (Linux)

ps -ef | grep FNDLIBR

ps -ef | grep FNDSM

Troubleshooting Flowchart

Concurrent Manager Down

          │

          ▼

Verify ICM

          │

          ▼

Verify FNDSM

          │

          ▼

Review FND_NODES

          │

          ▼

Clone Cleanup

          │

          ▼

Run AutoConfig

          │

          ▼

Recreate FNDSM (If Required)

          │

          ▼

Relink Executables (If Required)

          │

          ▼

Restart Concurrent Managers

          │

          ▼

Test Concurrent Requests

          │

          ▼

Concurrent Processing Operational

Frequently Asked Questions (FAQ)

Can I recreate Concurrent Manager without affecting the database?

Yes. Recreating Concurrent Manager components typically affects the application tier configuration and Concurrent Processing framework rather than the Oracle Database itself. Always perform backups and follow Oracle-supported procedures before making changes.

What causes Concurrent Manager failures after cloning?

The most common causes include obsolete FND_NODES entries, incorrect hostnames, incomplete clone cleanup, missing FNDSM registration, and configuration inconsistencies that require AutoConfig.

Should I run `FND_CONC_CLONE.SETUP_CLEAN` on every cloned environment?

Yes. Oracle recommends cleaning clone-related Concurrent Processing configuration before regenerating the environment with AutoConfig to prevent node registration and manager startup issues.

When should CMCLEAN be used?

CMCLEAN should only be used after abnormal Concurrent Manager shutdowns or when stale process information prevents managers from starting. Ensure all Concurrent Managers are stopped and follow Oracle Support guidance before using the utility.

Can AutoConfig solve Concurrent Manager startup problems?

Yes. If startup failures are caused by inconsistent or outdated configuration files, AutoConfig can regenerate the correct configuration and restore normal Concurrent Processing.

About the Author

Rana Abdul Wahid is an Oracle Database and Oracle E-Business Suite Consultant with more than 15 years of experience in Oracle Database Administration, Oracle E-Business Suite Application DBA, Oracle Cloud Infrastructure (OCI), Oracle RAC, Oracle Data Guard, RMAN Backup & Recovery, Linux/Unix Administration, MySQL, Microsoft SQL Server, PostgreSQL, and enterprise infrastructure management.

His expertise includes Oracle E-Business Suite administration, Concurrent Processing, Oracle Forms, Oracle WebLogic Server, Oracle HTTP Server (OHS), AutoConfig, Oracle RAC, performance tuning, backup and recovery, and enterprise production support. He regularly publishes practical solutions based on real-world Oracle Apps DBA experience.

Learn more about the author →

Conclusion

Oracle Concurrent Manager is the backbone of background processing in Oracle E-Business Suite. When it fails, essential business operations—including reporting, financial processing, workflow, payroll, and scheduled batch jobs—can be interrupted across the entire application.

Most Concurrent Manager failures are not caused by corruption of the managers themselves but by issues such as incorrect FND_NODES registration, incomplete clone cleanup, Service Manager (FNDSM) failures, AutoConfig inconsistencies, or application tier configuration problems. A structured troubleshooting approach that verifies the Internal Concurrent Manager, node configuration, middleware services, and Concurrent Processing environment enables Oracle Apps DBAs to restore functionality quickly and safely.

Final Oracle Apps DBA Recommendation

Before rebuilding or recreating Concurrent Manager components, always identify the underlying cause. Validate FND_NODES, execute FND_CONC_CLONE.SETUP_CLEAN for cloned environments, run AutoConfig, review ICM and FNDSM logs, and test concurrent requests thoroughly after maintenance. Following Oracle-supported procedures minimizes downtime and ensures a stable Concurrent Processing environment.

Found this guide helpful? Visit the Oracle Error Codes Guide for more production-tested Oracle Database, Oracle E-Business Suite, Oracle Forms, Linux, and middleware troubleshooting articles designed for Oracle DBAs and Oracle Apps DBAs.

Oracle Database Error Solutions & DBA Knowledge Base