The security_error_ring_buffer_recorded event and why you don’t need it

 

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.

Event Frequency

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.

Extended Events file - Group by this Columns
Extended Events file – Group by this Columns

 

Once the events are grouped, check the number of entries for the security_error_ring_buffer_recorded event.

XE Grouped Events
XE Grouped Events

 

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;
GO

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.

2 thoughts on “The security_error_ring_buffer_recorded event and why you don’t need it

    1. Eitan-

      As I said in my post, “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.”

      I don’t know of anyone who has used it to successfully troubleshoot an issue. However, if you’re concerned, you can create a separate event session that captures JUST that event, and remove it from system_health. You won’t add (or reduce) overhead on your system, but you will reduce the extraneous event from the system_health session so you have more useful data there, as well as more data overall.

      I’d also encourage you to see how many events you have in any given system_health file right now, and how many of them are the security_ring_buffer_recorded event.

      Hope that helps,

      Erin

Leave a Reply

Your email address will not be published. Required fields are marked *

Other articles

How was a plan forced?

If you use Automatic Plan Correction, and thus also Query Store, you may wonder how was a plan forced: manually or automatically with APC?  The

Explore

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.