You Asked
I read the article, titled:
Event Monitor Process: Architecture and Known Issues (Doc ID 105067.1)
…
Notification implements a high-watermark scheme where when the backlog of notification events hit an in-memory limit the messages are, in the case of 9.2, spilled onto disk into the SYS.AQ_EVENT_TABLE_Q queue if a watermark has been set. In 9.2 the default value for the watermark is 0 which means that the no messages will spill onto disk and the entire shared pool could be used for notification events. In 10.1 onwards the procedures DBMS_AQADM.GET_WATERMARK and DBMS_AQADM.SET_WATERMARK are available to set the amount of memory available for notification events but the messages are no longer spilled onto disk. Instead the enqueueing process are subject to flow control until the backlog has been cleared by the emon process.
…
What does it mean for me as a developer? I’ve a 12.2 EE database under Linux(64 bit). I registered a notification callback procedure.
How can I know , when enqueuing a message to the queue, that my message will be approved by EMON, or it will be placed to the backlog?
And why should I know that? Does “until the backlog has been cleared by the emon process” mean that entire backlog will be lost without any further processing by EMON?
I noticed many times that there are messages in the queue and in the same time EMON’s job PLSQL_NTFN hangs in state “Waiting for messages in the queue”. And these messages seems to be never processed.
May be it is the case of clearing backlog? And where can I find an information (in server logs, in database objects) about clearing backlog and about MSGId’s of messages that had been cleared?
TIA,
Andrew.
and Connor said...
How can I know , when enqueuing a message to the queue, that my message will be approved by EMON, or it will be placed to the backlog?You don't know and don't need to know. This is simply a memory management issue. EMON is still responsible for sending notifcations to clients whether those notification messages were staged to disk or not.
When you say the EMON job "hangs" on "waiting for mesages", my understanding is that if you cannot find a client to send a notification to, then that message wont be processed and it will resume waiting on signals to send new notifications. So it is quite feasible for messages to be unprocessed *and* have EMON waiting on messages.
In terms of debugging, the MOS note you referenced contains some details on doing tracing on EMON to see if its hung, and also you can monitor V$EMON to make sure its "ticking over" from time to time.
https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/V-EMON.html#GUID-E9C0B5B5-B3CA-426D-85C6-7FC1304D9662 But if you ever suspect you have an issue with a background process (EMON or otherwise), an SR is always your best bet.
Is this answer out of date? If it is, please let us know via a Comment