Understanding “Wait for EMON Process Ntfns” in Oracle Database

 The Event Monitor process, commonly known as EMON, is primarily responsible for handling notifications inside the Oracle Database. One of its major use cases is supporting Database Change Notification (DCN), where applications subscribe to database objects and receive notifications whenever changes occur.

Applications often rely on these notifications to trigger downstream actions automatically. In most environments, this works seamlessly in the background. However, there are situations where EMON-related waits can become a serious performance concern.

What is EMON Doing Internally?

EMON works closely with Oracle Advanced Queuing (AQ). Whenever database changes occur on subscribed objects, notifications are placed into internal queues. EMON then processes these notifications and sends callbacks to the subscribed clients.

Since EMON is an Oracle background process, database administrators generally do not have direct operational control over it. Oracle automatically spawns and terminates these processes as needed.

You can read more about its internal working in Oracle documentation, but from a troubleshooting perspective, the important thing to understand is this:

• Notifications are queued internally.
• EMON dequeues and sends them to clients.
• If EMON cannot process notifications fast enough, queues begin to build up.

That is where problems usually start.

---

Understanding the Wait Event

In problematic scenarios, database sessions may begin showing the wait event:

WAIT FOR EMON PROCESS NTFNS

In severe cases, the database may even appear partially unresponsive.

One common observation during such incidents is elevated CPU consumption by EMON-related processes, although this is not always guaranteed.

The issue generally occurs when:

• Notification enqueue rate is faster than dequeue rate.
• Clients consuming notifications are slow or unreachable.
• Network connectivity issues delay callbacks.

When the notification buffer becomes full, Oracle enables flow control internally. At that point, EMON stops accepting additional notifications until pending ones are processed.

As a result, sessions performing DML operations on subscribed tables can get blocked waiting on:

Wait for EMON to process ntfns

---

Checking Notification Latency

Oracle provides the dynamic view below to monitor notification registration statistics:

SELECT * 
FROM v$subscr_registration_stats;

One limitation here is that Oracle does not maintain historical statistics for this view, so troubleshooting often needs to happen during the actual issue window.

---

Recommended Fixes

Oracle introduced fixes for this behavior in Oracle Database 12.1, but they require enabling specific hidden parameters.

Action 1: Enable Auto Unregistration

This parameter allows Oracle to automatically unregister unreachable clients after a timeout period.

conn / as sysdba

alter system set "_client_enable_auto_unregister" = TRUE 
scope=spfile sid='*';

---

Action 2: Configure EMON Timeout

This parameter controls the timeout value for EMON notification delivery in milliseconds.

Default values vary by version:

• 12.1 → 10 seconds
• 18c → 2 hours

The example below sets the timeout to 60 seconds.

alter system set "_emon_send_timeout" = 60000 
scope=spfile sid='*';

---

Important Note About Underscore Parameters

Both parameters mentioned above are hidden (underscore) parameters.

Although Oracle Support documents recommend them in specific scenarios, hidden parameters should always be handled carefully in production environments. It is strongly recommended to validate changes with Oracle Support before implementation.

---

Verifying Parameter Changes

You can verify whether the parameters are active using the following query:

set line 100

col Parameter for a50
col "Session Value" for a20
col "Instance Value" for a20

SELECT a.ksppinm "Parameter",
       b.ksppstvl "Session Value",
       c.ksppstvl "Instance Value"
FROM x$ksppi a,
     x$ksppcv b,
     x$ksppsv c
WHERE a.indx = b.indx
AND   a.indx = c.indx
AND   a.ksppinm IN (
'_client_enable_auto_unregister',
'_emon_send_timeout'
);
/

---

Additional Recommendation

Some Oracle documents also suggest configuring the following parameter inside sqlnet.ora:

SQLNET.SEND_TIMEOUT=10

This can help in cases where notification delivery is impacted by network delays.

---

Identifying Running EMON Processes

At the operating system level:

ps -ef | grep -i e00

Inside the database:

SELECT * FROM v$emon;

---

Common Causes of This Wait Event

To summarize, the wait event typically occurs because of one or more of the following reasons:

1. Notification enqueue rate is higher than dequeue rate.
2. Subscribed clients are unreachable or slow.
3. EMON timeout values are excessively high.
4. Network connectivity issues between database and application servers.
5. Large backlogs of pending notifications.

---

References

• Users Blocked and Waiting on 'Wait for EMON to Process Ntfns' When Using DCN (Doc ID 1257264.1)
• Sessions Hang on Wait Event "WAIT FOR EMON PROCESS NTFNS" (Doc ID 1287435.1)

---

Suggested Blog Title Alternatives

• Troubleshooting “Wait for EMON Process Ntfns” in Oracle Database
• Understanding EMON Wait Events in Oracle
• How to Resolve “Wait for EMON Process Ntfns” Issues in Oracle
• EMON Process Internals and Performance Troubleshooting in Oracle
• Oracle Database EMON Wait Event Explained