TRACE_EVTNOTIF is recorded when event notifications are configured, once per firing of an event that has a notification attached. Event notifications are the Service Broker-based mechanism that turns trace events and DDL events into messages on a queue, letting you react asynchronously to things happening in the engine.
The wait’s volume therefore mirrors the firing rate of whatever events you subscribed to.
Is It a Problem?
Not mechanically; the notification machinery is cheap per event. The exposure is in event choice: subscribing to high-frequency events multiplies everything downstream. AUDIT_SCHEMA_OBJECT_ACCESS_EVENT is the canonical example, it fires on object access checks, which busy systems perform constantly, and a notification on it turns each into a Broker message.
If this wait carries real time, your notification subscriptions include something chatty, and the queue processing behind them is working proportionally hard.
Common Causes
- Event notifications configured on frequent events (audit and access events especially).
- DDL notifications on churn-heavy environments.
- Broker queue readers keeping pace with the resulting message stream.
What To Do
- Inventory subscriptions:
sys.event_notificationsandsys.server_event_notificationsshow what fires messages. - Subscribe narrowly; per-event costs are small but multiplied by frequency.
- For heavyweight auditing needs, SQL Server Audit or targeted Extended Events sessions usually beat notifications on chatty events.
How To See It
Rank waits with Get-WaitStatistics; its rate tracks your subscribed events firing.
Part of the SQL Server Wait Types Library.
Related deep dive: ASYNC_NETWORK_IO Wait Type.
Leave a Reply