I recently ran through a health audit for a customer, and in reviewing their system_health output I was reminded of the unnecessary security_error_ring_buffer_recorded event. That’s right: you don’t need it in your system_health session.
Jonathan and I have talked about this numerous times, but neither of us have ever written about it. In the case of our Remote DBA customers, we remove security_error_ring_buffer_recorded event from the system_health event session on all instances we access. I’m typically not someone that recommends altering what ships and runs by default by Microsoft, but in this case, I’m all for it. Aaron Bertrand recently blogged about options for improving the system_health session and included this same suggestion.
In Aaron’s post he refers to the security_error_ring_buffer_recorded event as “unactionable noise”, and frankly I can’t think of a better term for it. I’ve never used it to troubleshoot it any authentication/security issue, and I’m very confident that Microsoft isn’t using it in its current state either. In terms of the volume of that event, for the new client system that I looked at recently the five system_health files covered about four (4) hours of time. Of the 1,851,741 million events captured in that time frame, the security_error_ring_buffer_recorded event showed up 1,838,882 times. That’s 99.3% of the events…absolute noise.
To check how frequently security_error_ring_buffer_recorded event shows up in your system health, simply browse out to the Log folder for the SQL Server instance and open one of the system_health*.xel files in Management Studio. Then, right-click on the name column and select Group by this Column.
Once the events are grouped, check the number of entries for the security_error_ring_buffer_recorded event.
A Quick Fix
Assuming your frequency is just as high, remove the event it from the system_health session. The command is simple:
ALTER EVENT SESSION [system_health] ON SERVER
DROP EVENT sqlserver.security_error_ring_buffer_recorded;
You do not need to stop and re-start the event session; you can run this and it will immediately take effect. Once you make that change, take note of the time span your event sessions start to cover, and what events become more frequent. Hopefully this creates a more useful data collection that you can use when troubleshooting.