Few Oracle errors create as much confusion—and quiet risk—as ORA-4036. It often appears suddenly in the alert log, sometimes without immediate application impact, yet it signals a serious memory pressure condition inside the database.
This blog combines real-world incident experience with a complete technical explanation to give you the most practical, DBA-focused guide to:
- PGA_AGGREGATE_LIMIT
- ORA-4036
- Background processes (like MMON) consuming PGA
- Immediate mitigation and long-term prevention
If you manage production Oracle databases, this is an error you must fully understand, not just silence.
The DBA Reality: ORA-4036 Usually Starts Quietly
ORA-4036 often arrives like this:
“ORA-4036 occurred, but no application was affected.”
That sentence is misleading.
ORA-4036 is not a harmless warning—it’s an early indicator that Oracle is running out of PGA memory and is attempting (or failing) to protect itself. When ignored, the next stage is slow queries, aborted sessions, or even instance instability.
What Is PGA and Why Does It Matter?
The Program Global Area (PGA) is private memory allocated to each server process. It is used for:
- Sort operations (
ORDER BY,GROUP BY) - Hash joins
- Bitmap merges
- PL/SQL variables
- Cursor execution memory
- Parallel query execution
Unlike the SGA, PGA is not shared—and that’s why it can grow dangerously fast under concurrency.
Understanding PGA_AGGREGATE_LIMIT
PGA_AGGREGATE_LIMIT is a hard upper limit on total PGA usage across the entire instance.
SHOW PARAMETER pga_aggregate_limit;
When Oracle detects that total PGA usage is approaching this limit, it tries to protect the instance by raising:
ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT
Oracle then attempts to:
- Abort calls from sessions using the most untunable PGA
- Terminate sessions if memory pressure continues
But this protection has important exceptions.
The Critical Twist: Why Some ORA-4036 Errors Cannot Be Prevented
You may see this alert log message:
“PGA_AGGREGATE_LIMIT has been exceeded but some processes using the most PGA memory are not eligible to receive ORA-4036 interrupts.”
This means:
- The PGA limit has already been exceeded
- Oracle identified top PGA consumers
- Those processes cannot be interrupted safely
Which Processes Are Ineligible?
Oracle will not interrupt:
- Background processes (MMON, DBWn, LGWR, SMON, PMON)
- SYS-owned internal operations
- Certain parallel execution coordinators
- Database Resource Manager (DBRM) internals
Killing these could destabilize the instance—so Oracle logs the warning and continues running under pressure.
This is far more dangerous than a normal ORA-4036.
Real-World Case: When MMON Becomes the Top PGA Consumer
In a real incident, everything initially looked healthy:
- Enterprise Manager showed green
- No user complaints
- No visible workload spike
But a deeper check revealed the truth.
Checking PGA Status
SELECT name, value
FROM v$pgastat
WHERE name = 'total PGA allocated';
Result:
👉 Over 90% of PGA_AGGREGATE_LIMIT was already consumed
This meant the database was constantly one heavy sort away from failure.
Finding the Real Culprit
Next step: identify who was holding the PGA.
SELECT s.sid, s.serial#, s.username,
p.pga_alloc_mem/1024/1024 AS pga_mb,
s.program
FROM v$process p
JOIN v$session s ON p.addr = s.paddr
ORDER BY p.pga_alloc_mem DESC;
The surprise?
👉 MMON slave processes (M000–M004) were each holding large amounts of PGA.
MMON is responsible for:
- AWR snapshot generation
- Statistics collection
- Automatic database maintenance
Because MMON is a background process, Oracle cannot interrupt it—even when it causes PGA exhaustion.
Confirming via Alert Log and DBRM Trace
The alert log usually points to a DBRM trace file:
PGA LIMIT: pid XXX is a top contributor
PGA LIMIT: pid XXX is ineligible for ORA-4036 interrupt
By mapping the PID to OS processes, the culprit is often confirmed as MMON or its slave processes.
At this point, it becomes clear:
👉 This is not a user SQL issue—it’s an internal Oracle memory problem.
Root Cause: Known PGA Leaks and XML Operations
In Oracle 19c environments, known defects exist where:
- Internal queries using XMLFOREST
- Consume excessive, unreleased PGA
- Are executed by background processes (including MMON)
This explains why:
- PGA usage stays high
- The issue does not resolve naturally
- Oracle cannot auto-correct it
Why This Situation Is Dangerous
Ignoring this condition can lead to:
- ORA-4036 for business sessions
- Random session termination
- Severe performance degradation
- OS memory pressure and swapping
- Instance eviction (RAC)
- Database crash in extreme cases
This is not an alert you postpone.
Immediate Actions During an Incident
1️⃣ Confirm PGA Pressure
SELECT * FROM v$pgastat;
2️⃣ Identify Top PGA Consumers
SELECT program, pga_alloc_mem/1024/1024 AS pga_mb
FROM v$process
ORDER BY pga_alloc_mem DESC;
3️⃣ Stop Non-Critical Workloads
Pause batch jobs, reports, or ETL if possible.
The Only Safe Short-Term Fix
You have two choices:
Option 1: Increase PGA_AGGREGATE_LIMIT (Recommended)
ALTER SYSTEM SET pga_aggregate_limit = 40G SCOPE=BOTH;
✔ Prevents ORA-4036
✔ Keeps safety controls
❌ Does not fix the root cause
Option 2: Set PGA_AGGREGATE_LIMIT = 0
ALTER SYSTEM SET pga_aggregate_limit = 0;
⚠ Removes hard protection
⚠ Risky in on-prem systems
⚠ Less predictable behavior
In production, Option 1 is almost always safer.
Long-Term Fixes and Best Practices
Right-Size PGA Correctly
Typical guideline:
PGA_AGGREGATE_TARGET→ working memoryPGA_AGGREGATE_LIMIT→ 2–3× target (or OS-based calculation)
Monitor PGA Trends
Use:
SELECT * FROM dba_hist_pgastat
WHERE name = 'total PGA allocated';
This helps detect slow PGA leaks over time.
Tune SQL and Control Parallelism
- Fix inefficient joins and sorts
- Limit parallel queries
- Avoid uncontrolled reporting workloads
Use Resource Manager (DBRM)
DBRM can:
- Limit PGA per consumer group
- Prevent one workload from starving others
Ironically, DBRM is also where Oracle logs this warning—making it even more important.
Key Lessons for DBAs
✔ ORA-4036 is not always caused by user SQL
✔ Background processes can exhaust PGA
✔ Oracle cannot interrupt everything
✔ Alert logs often warn before disaster
✔ PGA_AGGREGATE_LIMIT must be designed, not guessed
Final Thoughts
The message:
“Processes are not eligible to receive ORA-4036 interrupts”
is Oracle’s way of saying:
👉 “I see the memory problem, but I cannot protect you from it.”
DBAs who understand this behavior can act before outages occur, not after.
If you treat ORA-4036 as just another log message, you’ll eventually face it as an incident.
