JD Edwards: How we solved an Oracle concurrency problem without a Diagnostic Pack
- Jean-Michel Alluguette – OP&S
- Dec 17, 2025
- 5 min read
In a JD Edwards environment, performance symptoms are often misleading.
A user says "JDE is slow", a batch takes longer, and we immediately think: CNC, network, application, server load…
Except that, in many cases, the cause is on Oracle's side: the database no longer "holds" concurrency.
In other words: sessions are mutually blocking each other . It's not necessarily a breakdown, it's an internal friction that causes response times to skyrocket.
In this feedback, I recount a real case: recurring slowness on JDE, a diagnosis that points to an Oracle lock/contention problem, and a resolution without a Diagnostic Pack .
Context: Regular slowdowns and user experience
The client uses JD Edwards on Oracle.
Users are noticing:
slowdowns that appear at certain times
a deterioration that seems “random”,
Sometimes screens "spin" without any explicit error.
From an operational standpoint, the problem is not straightforward:
the database does not fall
The CPU load may seem “acceptable”,
and the standard alerts don't trigger anything clear.
This is typically the kind of incident where we lose time because we don't have immediate evidence.
What we are trying to determine first
Before going too far, we need to answer 3 simple questions:
Is the bottleneck Oracle or somewhere else ?
If it's Oracle, is it a CPU/I/O issue or a concurrency/lock issue ?
If it's competition, who is blocking whom and why?
OP&S helps to quickly implement this logic.
Step 1 — Visualize the overall load: recognize a “concurrency” profile
First step: look at the Oracle load over a representative period (several days, not 30 minutes).
In OP&S, we observe:
recurring load peaks,
an increasing DB Time
but without a proportional increase in CPU or I/O.
This profile is often a sign of a concurrency problem:
the database spends time waiting (locks, latches, contention), rather than working (CPU) or reading/writing (I/O).
The advantage here is that we don't go into tuning "at random," we already know which direction to explore.
Step 2 — Reducing wait times: the “library cache lock” signature
Second step: analyze the wait events (Oracle waiting times).
In this case, one event stands out massively:
library cache lock
Without getting into unnecessary Oracle jargon, remember this:
The “library cache” is an area where Oracle manages shared objects (SQL, plans, compiled objects…).
When too many sessions are fighting over the same objects (or when a maintenance operation disrupts the mechanism), this can cause internal blockages.
User-side result: slowness, freezes, and above all a feeling of instability.
This signal is powerful:
This is not a classic “slow SQL” issue, but a structural concurrency problem.
Step 3 — Identify the sessions and the responsible SQL
Once the type of expectation has been identified, the next step is simple:
Who generates these locks? And on what?
OP&S allows you to trace back:
the most active sessions during periods of slowness,
the SQL_IDs involved,
the frequency of blockages,
and the context (time, batch, JDE process, etc.).
This is where many teams get lost without the right tools:
They see “library cache lock”, but cannot connect this to a concrete process.
In this case, the analysis highlights a link with operations related to statistics (collection / refresh), which created abnormal competition.
Step 4 — The crucial point: a problematic method of collecting statistics
Oracle statistics collection is essential… but it can be dangerous if it is:
incorrectly configured
triggered at the wrong time
or made with a method that causes high competition.
In this case, the diagnosis led to the identification of a known/documented problem on Oracle's side:
The method of collecting statistics triggered contention, and this resulted in mass “library cache locks”.
The trap: this problem can occur even if “everything seems normal” during the day.
All it takes is a batch window, a stats job, and you'll find yourself experiencing slowdowns on the JDE side.
Step 5 — Correction: Adjust the statistics strategy (without breaking the ERP)
The correction consisted of:
review the configuration of the statistics jobs.
adjust the collection method,
and synchronize these actions with the reality of JDE processing (batches, night windows, sensitive periods).
Objective: to maintain reliable statistics (therefore good execution plans), without causing contention .
Step 6 — Validation: measuring the disappearance of the restraint
After correction, OP&S allows for factual validation:
drop in occurrences of library cache lock ,
reduction of peak loads related to waiting times,
noticeable improvement in response times and batch sizes,
decrease in user complaints.
This is a key point: in performance, "we think it's better" is not enough. We need to measure .
Checklist: How to quickly diagnose a concurrency problem on Oracle (JDE specific)
1) Confirm that the problem originates from the database
Does DB Time increase without a corresponding increase in CPU/I/O?
Does the problem appear during recurring time slots (batch, specific times)?
2) Identify the dominant wait class
Concurrency / Locks?
Configuration?
I/O?
CPU?
3) Isolate the main expectation
Example: library cache lock
Look at frequency, periods, correlation with jobs.
4) Go back to sessions / SQL_ID
Which sessions consume the most and have the most waiting time?
Which SQL_IDs are correlated with the spikes?
Is this related to a JDE batch process or Oracle maintenance?
5) Check the “invisible” but critical operations
Statistics collection
Recompilations
Maintenance or internal jobs
Recent changes (patch, setting, migration)
Why are these incidents frequent on JDE?
JDE has characteristics that amplify competitive phenomena:
large batches concentrated over specific time windows,
Concurrent access to certain objects
periods of high activity (closings, monthly processing, etc.),
maintenance operations are often planned “alongside” the batches (stats, maintenance, etc.).
It's not "JDE's fault" or "Oracle's fault": it's a reality of exploitation, and we need tools to objectify it.
Conclusion
An Oracle concurrency problem can transform a stable JD Edwards environment into a “slow” environment without an outright failure.
In this REX, the analysis of waiting times highlighted a massive library cache lock phenomenon, linked to an unsuitable statistics strategy.
Once the correction was applied, the disappearance of the locks and the stabilization of performance were clearly measured.
The important point: all of this was done without a Diagnostic Pack , with a structured approach and factual metrics.
Are you managing a JDE environment with unexplained slowdowns?
An OP&S Proof of Concept (PoC) enables:
to analyze your actual waiting events,
to identify concurrency problems,
to have factual evidence to make lasting corrections.
About the author
Jean-Michel Alluguette is the founder of OP&S, a software dedicated to Oracle and ERP (JD Edwards / E-Business Suite) environments to manage performance, costs (FinOps) and security/licenses.
Do you want a factual analysis of your Oracle databases? → Request a free 1-month PoC.
Comments