OracleFree worksheetPDF, Excel, Word exportOracle E-Business Suite

Oracle EBS Concurrent Program Load Planner Worksheet

Batch schedules in EBS grow by accretion: one more scheduled request here, another there. This worksheet lists them with runtime and frequency so you can see total load and how many concurrent processes it takes.

Download:
Concurrent programManager queueOwnerAvg runtime (min)Runs per dayBusy minutes per dayAvg busy processes
72
0.05
100
0.0694
144
0.1
120
0.0833
480
0.3333
180
0.125
Total busy minutes per day
1,096
Total average busy processes
0.7611
Processes for 70% utilization
2
Average load only. Peaks need more.
Processes with 3x peak factor
4
Rough allowance if work clusters into a third of the day.

Replace the sample rows with your own programs. Pull runtimes from FND_CONCURRENT_REQUESTS history. The averages assume load is spread across 24 hours, so use the peak factor row for batch windows.

Batch schedule review

Optionally send your schedule export and we will point out overlap and clustering.

Optional. The tool and every export work without this. No spam.

How to use it

Add one row per scheduled program, including the manager queue it runs in. Enter average runtime in minutes and runs per day. The sheet calculates busy minutes per day and the average number of processes that program keeps busy, which is busy minutes divided by 1,440. Totals show the whole schedule. The summary row gives a process count for 70% utilization, plus a version that allows for the work clustering into a shorter batch window.

  • Include recurring workflow and interface jobs, not only reports.
  • Group by manager queue to size specialized managers.
  • Export to Excel to share with functional owners.

Method

Average busy processes equals runtime times runs per day, divided by the minutes in a day. Because 24 hour averages hide peaks, the worksheet scales by a peak factor. If most batch work lands in an 8 hour window, the factor is 3. Dividing by a target utilization of 0.7 leaves room for bursts and for ad-hoc user requests. This is a first-pass sizing, and the queue wait calculator in this series refines it for a single queue.

Using the result

Compare the suggested process count with the sum of target processes across your managers. If the batch window needs more than you have, look first at whether jobs can be moved earlier or later, whether incompatibilities force serial execution, and whether runtimes can be tuned. Raising target processes without checking database CPU and memory only moves the bottleneck. Keep this sheet current, and re-run it after each new module or interface goes live.

  • Retire schedules that no one reads output from.
  • Spread top-of-the-hour jobs across minutes.
  • Review after every quarter-end.

Frequently Asked Questions

Where do I get the list of scheduled programs?

Query FND_CONCURRENT_REQUESTS for phase_code of P (pending) with a resubmit interval or a future start date, joined to FND_CONCURRENT_PROGRAMS_TL for names. The View Requests form also shows scheduled requests.

Why 70 percent utilization?

Queues lose responsiveness quickly above roughly 80 percent. Seventy percent leaves headroom for bursts and ad-hoc submissions. Change the value if your service-level goals differ.

Does this include user-submitted reports?

Only if you add them. Many sites keep a separate row for an estimated average of ad-hoc requests per day by manager to avoid undersizing the Standard Manager.

Can I export the worksheet?

Yes. Every worksheet exports to Excel, PDF and CSV from the page, so you can share it with application owners and attach it to a change request.

If you want your real schedule and runtimes pulled from EBS automatically and flagged for clustering and overlap, we can build that read-only over your own database.