Understanding the Concurrent Manager Architecture
The Concurrent Manager is the backbone of batch processing in Oracle EBS. Every financial report, every subledger transfer, every mass transaction process runs through it. When the concurrent manager is healthy, these processes run predictably and efficiently. When it’s not, everything slows down.
Common Performance Issues
Long Queue Wait Times
The most visible symptom of concurrent manager performance issues is long queue wait times. Users submit requests and wait 30, 45, or 60+ minutes before execution even begins.
Root cause: Almost always insufficient concurrent processing capacity relative to demand. The default configuration provides a fixed number of target processes that doesn’t account for growth in transaction volume or user population.
Stuck Requests
Requests that remain in “Running” status far beyond their expected execution time—or indefinitely—are a sign of resource contention, database lock issues, or application bugs.
Root cause: Often caused by conflicting concurrent programs competing for the same database resources, or by programs that don’t properly release locks when they encounter errors.
Throughput Degradation Over Time
A gradual decline in concurrent manager throughput—processes that used to take 10 minutes now take 30—indicates underlying database performance issues or environmental drift.
Root cause: Stale optimizer statistics, table fragmentation, index degradation, or increasing data volumes without corresponding infrastructure scaling.
Tuning Strategies
1. Right-Size Your Manager Configuration
Review your concurrent manager configuration against actual demand patterns:
- Specialized managers: Create dedicated managers for different workload types (financial reporting, subledger processing, custom programs).
- Target process counts: Set target processes based on measured peak demand, not default values.
- Work shifts: Implement close-specific work shifts that increase capacity during close periods.
2. Optimize the Top Resource Consumers
Identify the concurrent programs that consume the most resources using the concurrent request history:
Focus on the top 10 programs by execution time and frequency. Even modest improvements to these programs yield significant aggregate benefit.
3. Implement Scheduling Discipline
Prevent resource contention by establishing scheduling rules:
- Incompatibility rules: Define which programs should not run simultaneously.
- Scheduling windows: Assign processing windows for different workload types.
- Priority management: Ensure critical close programs have appropriate priority.
4. Database-Level Optimization
The concurrent manager’s performance is ultimately bounded by database performance:
- Statistics collection: Automate optimizer statistics collection on a schedule aligned with your processing patterns.
- Index maintenance: Regularly rebuild fragmented indexes on high-volume financial tables.
- Purge strategy: Implement a concurrent request purge policy to prevent history tables from impacting performance.
Monitoring Framework
Implement these monitoring metrics for ongoing concurrent manager health:
- Average wait time by manager: Track trends weekly.
- Throughput by hour: Identify peak demand patterns.
- Failure rate by program: Catch emerging issues early.
- Resource utilization: CPU, memory, and I/O during peak processing.
Capacity Planning
Don’t wait for performance problems to scale your concurrent manager. Plan capacity based on:
- Transaction volume growth rates
- New module implementations
- Seasonal processing patterns (year-end, quarter-end)
- Planned organizational changes (new entities, acquisitions)