OracleFree calculatorPDF, Excel, Word exportOracle JD Edwards EnterpriseOneDiscrete Manufacturing

JDE UBE Batch Window Calculator

A UBE that fits the window in test often overruns in production because volume grows and parallel copies fight over the same tables. This calculator turns row counts and measured throughput into an elapsed-time estimate you can compare with the window.

Your numbers

rows

Rows the UBE reads or writes in one run, for example F4211 or F0911 rows in the selection.

rows/sec

Measured from a prior run: rows divided by elapsed seconds for one UBE process.

4 slots

Number of copies split by data selection and run side by side on the job queue.

%

Lock waits and database contention. Measure it; 0 means perfect scaling.

hours

Your results

Estimated elapsed time
1 hrs
Serial time divided by slots, inflated by contention.
Margin against window
7 hrs
Negative means the job overruns the window.
Single-process runtime
3 hrs
Elapsed time if run as one process.
Window used
10.8%
Slots needed with zero contention
1
A lower bound; real runs need more.

Planning estimate. Measure real throughput in a representative run before committing a batch schedule.

Save results:

Elapsed hours vs parallel slots

Sweeps Parallel processes (queue slots) from 1 to 16, holding your other inputs fixed.

Batch schedule review

Optional: send your submitted-job export and get a short written review of window risks.

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

How to use it

Pull the row count and elapsed time from a prior run in Work With Submitted Jobs or the job log, and enter rows per second for a single process. Then set the number of parallel copies you plan to run and a contention percentage. Watch the chart: elapsed time falls quickly at first, then flattens or even rises once contention outweighs the added slots.

The formula

Single-process time is records divided by throughput. With N slots the ideal time is that value divided by N, and the model multiplies it by one plus the penalty percent times N minus one. It is a simple linear contention model, not a benchmark. Its job is to show diminishing returns so you stop adding slots when they no longer help.

  • Split by data selection ranges that do not overlap.
  • Check queue limits on the job queue definition.
  • Allow for report output and print time after the run.

Common mistakes

Teams often size from average rows per second while the nightly peak hits cold caches and heavier joins. Others split copies on a range that skews to one copy, so the slowest slice sets the elapsed time. Use the worst-slice row count, not the total divided by slots, when you know the distribution is uneven.

Frequently Asked Questions

Where do I get rows per second?

Divide the rows processed by the elapsed seconds in the job log of a comparable run. Use a run with similar selection and data volume, and note whether it ran alone or alongside other jobs.

Why does adding slots stop helping?

Parallel copies compete for the same database locks, indexes and enterprise server resources. Once that contention grows faster than the work is divided, elapsed time stops dropping and can increase.

Does it model the job queue itself?

No. It assumes the slots you enter are available simultaneously. Check the job queue's maximum concurrent jobs and the server's CPU headroom separately.

Is the contention figure realistic?

The default is only a starting guess. Run the same UBE with two and four copies, compare elapsed times, and back out your own percentage.

If batch runtimes are growing, Netray can help analyze submitted-job history and tune the schedule alongside your JDE team.