Recent Improvements to sp_PressureDetector
Video Summary
In this video, I’m Erik Darling from Darling Data, and we’re diving into some exciting updates to SP Pressure Detector. This improvement has been a long-requested feature by many of you, and after putting in the effort, it’s now available for everyone to use. The main enhancement allows logging results directly to tables, giving you detailed insights into when pressures occurred and what was happening at those times. With this capability, you can analyze historical data more effectively, making it easier to identify trends and issues within your SQL Server environment. Whether you’re a data professional or just want to support the work I do, there are multiple ways to contribute—financially through donations, engaging with my content by subscribing and asking questions during Office Hours episodes, or hiring me for consulting services to help optimize your SQL Server performance. Additionally, if you’re interested in training, I offer 75% off a comprehensive course that lasts a lifetime, providing valuable insights into SQL Server performance tuning.
Full Transcript
Erik Darling here with Darling Data. In this video, we’re going to talk about recent improvements to SP Pressure Detector. And this is an improvement that many people have asked me about and requested for a long time. And, you know, it was a lot of work, but well worth it because, you know, I love and care about you and I want you to have an easier time dealing with SQL Server stuff. So, the improvement, big improvement made to SP Pressure Detector, like a couple of the other store procedures we’ve talked about so far, is that we can log the results to tables. So, now you can figure, you can log all this stuff to tables and figure out exactly when your pressures happened and what was going on and how awful everything was.
If you like the work that I do with SQL Server and you like the stuff that I put up on YouTube, you can support it with money by clicking on it. I’ll see you in the link down in the video description. If you have no money for whatever reason, you’re a data professional with zero dollars, not even four dollars a month for a lowly consultant like myself. You can like, you can comment, you can subscribe and you can ask questions for free that I will answer on my Office Hours episodes.
If you have money, if you have like money money, and you want to hire me to consult and make your SQL Server, you know, less awful, I can do that. And I do all of these things, health checks, performance analysis, hands-on tuning of all varieties, dealing with SQL Server performance emergencies, and training your developers so that you have fewer SQL Server performance emergencies. You can also get training from me, 24, 25 or so hours of it, 75% off, that means about 150 US dollars.
And that lasts for life, that is no subscription required. So again, link to do all that stuff down in the video description. SQL Saturday, New York City, May 10th, 2025. Wow. Beautiful. Springtime in Times Square. What a great time to be alive in an office building for a Saturday. You can always just like, say you’re going and, I don’t know, go to a Mets game or something.
But with that out of the way, let’s talk about SP pressure detector stuff. Now, let me just make sure that everything from the last video in here is cleaned up. It’s not. Okay, let’s get rid of that. And so the main, again, the main improvement with SP pressure detector, like a couple of the other procedures, is the ability to log things to a table and retain that data for only as long as you care about it.
Much like the other procedures, there is some stuff that I do to prepare the results to do it. If you decide to log to a table, then I will validate things. I will make sure that all of the tables are created. I will make sure that whatever schema you want to put things in lives there. And then I will, I don’t know, create all the tables that we need.
And then down here where the queries start running, I will actually put stuff into those tables. I promise it is absolutely fantastic what happens. It is beyond compare how amazing what happens is. So let’s just go look at this thing in action, because that’s where, that’s what everyone cares about anyway, right?
So again, all my procedures have the help parameter. It gives a handy script introduction. Sometimes even some examples of how to run it. Not in this one, though. And then, of course, I say that on the one that doesn’t.
And then a handy reference to what all the parameters do. So this is all very good stuff in here. I’m going to run this with debug on and hopefully we won’t hit any errors.
It happened successfully. Now, the debug output, because we have that enable that’s going to return all sorts of stuff to us about what ended up where and all sorts of other things. But over the messages tab, we will see where we created all our tables.
We applied the retention policy. That should probably be seven days. I’ll fix that later.
And then you’ll see all of the pressure detector stuff that gets logged, right? So coming back over here, if we look at where or like rather what tables get created, it is all of the, it is all the results that you would expect to see from pressure detector. So wait stats, excuse me, file metrics, perfmon, memory counters, CPU information, queries consuming memory, queries consuming CPU, and any CPU, high CPU events.
So all sorts of stuff ends up in there. Just to give you a brief look at what that ends up looking like. If we hit refresh, we will have all these new tables.
And the wait stats table is usually the one that gets the most action. So if we just right click and say select top 1000 rows, we will get like all of the, basically the table of information that you would see when you run pressure detector, just in stored in a table. So you can, you know, again, you can put this in, well, there’s, I guess there’s two tables for sample time and collection time, but whatever.
These things happen. I don’t mess up the regular results, I think, if I did too much there, but we don’t have to talk about that. Dope.
So you get all this stuff back. And again, you can stick this into an Excel file. You can query it with DuckDB. You can do whatever you want. And you will be able to figure out what your highs and lows for SQL Server are. And that’s across all of these things, obviously, like anything that SP pressure detector would have logged when you hit F5 would end up in these tables over here.
So hopefully you find this very useful. Hopefully you will find this a beneficial improvement to the much beloved SP pressure detector. And you will be able to start figuring out your SQL Server problems a bit easier with this data.
These data’s, these datum. Anyway, that’s about it for this one. Not too much there.
The next thing we’re going to talk about is QuickieStore. So as always, I hope you enjoyed yourselves. I hope you learned something. I hope that you will use these scripts and take advantage of the table logging that these scripts now offer. And again, if you, to get this code, it’s all of my GitHub repo.
The link is in the video description. That’s also where you go to ask questions, get support, file bug reports, request improvements, yada, yada. Don’t send me emails.
I will just tell you to go to GitHub. So that’s, that’s how I roll. Anyway, thank you for watching.
Going Further
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.