- Host: Mitchell Glasscock and George Stedman
- Topic: Updates to Database Health Monitor v3.0
- Recording Date: October 23, 2025
- Listen on Spotify
Stedman SQL Podcast Season 2 Episode 27 Database Health Monitor Updates
Welcome to this week’s episode of the Stedman SQL Podcast, hosted by Mitchell Glasscock and George Stedman! In this episode, they explore the latest Database Health Monitor enhancements — explaining not only what’s been added, but why these updates matter for real-world SQL Server environments. From preventing TempDB version store bloat with a new Quick Scan check, to adding open transaction visibility and command-line automation for scheduled health reports, this episode dives deep into practical DBA tools built from direct user feedback. Mitchell and George also discuss improvements to index usage tracking, historic vs. real-time performance analysis, CPU and blocking drill-down reports, and a more accurate backup status view that filters copy-only backups. Plus, they preview the upcoming TempDB allocation chart, designed to help DBAs quickly see how space is being used over time. Whether you manage SQL Server daily or just want to better understand how Database Health Monitor can simplify your DBA workflow, this episode is packed with valuable insights and tips. Learn more and download Database Health Monitor at DatabaseHealth.com
Podcast Transcript
Mitchell Glasscock 00:15
Welcome to the Stedman Solutions Podcast this month. You’re going over all the Database Health Monitor features. As you may notice, we don’t have Steve here with us today, myself, Mitch and George, we’re going to be going over all the new features that we’ve added to Database Health Monitor and have recently released. So welcome George. So we kind of wanted to go over during this podcast, a bunch of the new features, but we also wanted to kind of go over the reasons that we’ve added these features, because a lot of times we run into things working with clients that are like, hey, this would be really helpful to add to Database Health Monitor so that we weren’t having to manually Look for certain things. So with that, can we pull up the screen share and we’ll just jump right into it. First off, we’ve added one new check to the quick scan. So let’s pull that up real quick. This is going to be quick scan check number 245, all the way down here at the bottom. What this is looking for is when version store is taking up 80% or more of the Temp DB space. What’s allocated and why this is important is because, as RCSI recommended, snapshot isolation becomes more prevalent. Some things that are going on the back end can cause version store to shoot up in how much space it’s taking without you noticing. And this can cause your Temp DB bloat, to bloat out and without noticing that, it can lock up your entire system. We’ve actually seen it recently. A client had an entire system lockup because their Temp DB bloated out, and they had to keep expanding to handle this. So this is an early warning system to patch that version store expansion, and then you can handle that for it gets to be a problem, I guess. Let’s kind of go into George. Do you know a ton about why RCSI can cause that version store expansion? Don’t know off the top of my head. So with RCSI, when you’re doing updates to a table, if those updates will take a snapshot of that table and save it in Temp DB, so that the table is readily accessible for other reads while that update is happening. So inserts, updates and deletes can make changes while reads can happen on without being interrupted. So our CSI is a great thing to have, but it can cause this sort of back end thing. So the issue comes where if you have an open transaction, it will create a bunch of these snapshots to be stored in Temp DB, and they won’t clear out until that open transaction closes. So the transaction opens, and then a read creates a snapshot. Sorry, I might have said that backwards earlier, but a transaction opens, read starts a snapshot, does its read, but it won’t clear that snapshot until the transaction is closed. So if you have a transaction that’s opened and either it was a manual open or something open and then failed to finish and it doesn’t close, all these reads are creating snapshots in the back end, and it’s going to cause that version store to bloat out, and Temp DB is just going to keep getting bigger and bigger and bigger. So with that, we also added another report to see open transactions, to help prevent stuff like that. This report just shows what open transactions are running in the background. It’ll show you where that’s coming from, whether it’s a program that you’re running against your SQL Server, the login name, all the interesting information about starts and then how long. So these transactions have been open for a minute and 15 now and then the last run command from that transaction. I started these transactions about an hour ago. You can actually see this is basically what I did, is just begin transaction, inserting into a table random values, and then I never closed that transaction, staying open on the back end. This transaction was the exact same as this, but a back end SQL Server demand was ran by SQL Server itself, and so it hides what the original query was. So when you’re looking at this, you just have to be aware that sometimes the original transactional query isn’t always what shows up. And then it’s also important to. Note, when you’re looking at open transactions, you might think that they’re active query they don’t show up in what is active all the time, only if that command is currently being run across SQL Server will it show up in what is active. So looking at both open transactions and what is active at the same time is pretty important for figuring out what’s going on there. Alrighty. So that goes over quick scan, the new Quick Scan, check 245, and that new opens Transaction Report. Let’s go into the new command line parameters that are added to database, health monitor.
George Stedman 05:34
Yeah, this was one of those that audit season came around, and a bunch of our clients were like, Okay, how do we reliably track this stuff? How do we get a saved report of all our health of our databases on a schedule? So we went in and we wrote a silent version of Database Health Monitor. I mean, there’s a few command flags out there already, but this is kind of running the whole thing without a GUI at all. So you can run multiple instance reports. You can run the pre built health report, and we’re still working on it, but we’re gonna have it so you can run the click scan report as well.
Mitchell Glasscock 06:14
So the big thing is, we do have like these reports that you can run manually every time, right? So, like, here I’m running one, but I don’t think I was part of this conversation, but we had a client come and ask us to be able to run these reports just on the back end, on a schedule, right? So that whenever they need them, they can just pull up the file and be ready with it, right?
George Stedman 06:39
Yep, exactly. So if you want to, are you ready to demo the command? So we have included in the patch notes, as is a link to the command line parameters, database health page on our on the website.
Mitchell Glasscock 06:55
If you’re also looking for that, you can follow this in the command line parameters, and it’ll take you straight to our help page for that.
George Stedman 07:01
And so pretty much, you can just run database, health monitor out of its program files, or you can run it from the link. Doesn’t really matter, as long as you run it with run the exe, essentially. And then there’s three parameters. There’s silent report, which specifies the Report Type, file location will tell you, or you put in, where you want it to be saved to, and then the instance name is. It has to be a currently configured instance inside the Database Health Monitor, because it pulls that the connection info from the same from those safe connections. So you can do multiple instances, and it will generate one big report for all the instances. Or you can add multiple reports, and it will generate one big report for all of them, and then it will name them accordingly when it saves out.
George Stedman 07:49
So you’ll run it, and then you’ll get a nice report that it’s a little simple because, you know, program programmatically generating Word documents isn’t the most elegant thing, but if you open it up, you got whole lot of fun info in there.
Mitchell Glasscock 08:13
So this basically the exact same as that health report that’s generated in Database Health Monitor.
George Stedman 08:21
It’s also a nice thing to add if, if any of the database administrators out there have, like, a morning checklist or something, you can have this kick off at 7am and then just part of your morning checklist is to review this, because it spits out all your deadlocks, all your blocking queries. It gives you a quick refresh of your CPU usage by hour. It’ll give you deadlocks by database. It gives you a nice simplified version of the heat maps. And then it’ll give you backup status, which isn’t working on that server right now, but it’ll give you CPU usage.
George Stedman 09:01
So you can see just kind of a quick health check if you if you’re looking for that. You can also see if you’re looking at this as part of your daily checklist or monthly checklist, or whatever. Database by size is a nice one, because it can show you like on this one, which I think due to us testing with the Temp DB READ COMMITTED isolation level Temp DB is huge compared to the rest of the database, which is a red flag, so you’d probably want to go deal with that.
Mitchell Glasscock 09:34
Yeah, yeah. It’s a nice like quick. If I just open this up every morning I looked at it, it’d be pretty easy to spot those anomalies every time. And it’s nice because you don’t have to keep flipping through reports if you know where every report is, that’s great, but you still have to click at them, and this is a nice way to just be able to run it, get it all in one place, do a quick review and move on to your next tab.
George Stedman 09:56
Yeah, I just thought of a quick note. I need to update on that. That is, I need to add the date so that you can keep running it, and it will just save it in that one folder, so that if you need to look at historic stuff, they’ll all be saved, but that will be added as well, and we’re still polishing it. So it’s pretty simple right now, but any user comments from DBAs, what would be great to have on there, what wouldn’t what shouldn’t be on there maybe any help to help figure out what is important to everyone. Is always appreciated on those reports.
Mitchell Glasscock 10:29
Yeah, it’s interesting, because a couple of these reports that we’ve added recently, I mean, even for our 3.0 release, our big one that we did just a while back and then this release, we have a lot of user interaction, not just our team members who use it with clients, but actual users. You guys out there that reach out to us and you run into something where you say, hey, it’s really nice to or it’d be really nice to have this feature. I love this report, but it’d be really nice to have this feature alongside it, because this is the exact example, and we’re like, oh, yeah, I would be great to add. Let’s work on that. So user requests are super helpful in figuring out what is the most useful features to add to, Database Health Monitor.
George Stedman 11:19
Yeah, because, I mean, we know what’s important for working with our clients, but you know, some DBAs have different priorities, or different environments with different like restraints that they need to they would need reports to help figure out, like, where to go, what to do and what’s wrong.
Mitchell Glasscock 11:38
Speaking of that, one of the features we recently added was the or we didn’t add, but a quest from a user were, was the Index report changes. So let’s go in here. We’ll just look at the DB health history and the index reports. Few of the index reports have seen some changes, because the background process that we’ve done to collect index information has changed a little bit recently. So in version three, we changed the method index information is saved to the DB, health history database, so how often these indexes are used is saved to the actual database so that you can see the historic usage over time. The good thing about this historic usage is it doesn’t refresh this information on every server restart, so you’re able to see say you have it running for an entire year, but you’ve restarted every single month. You’d only see the last month of data on there, but with the historic information, you’re able to see the entire time that the DB health history database has been collecting information for you there, so it’s giving you a more accurate representation of what’s happening historically.
George Stedman 13:03
That’s really important, because some clients have certain queries that run at specific times of the year, specific times of the month, and if you have a regular restart cadence, your index usage may not be 100% accurate, right?
Mitchell Glasscock 13:16
You might have a heavy, heavy query that’s ran at the end of the month, and you’re restarting at the beginning of every month, or whatever your schedule may be. So you may not even catch how important the index is, that that query are. And whoever’s looking at it may see, oh, I’ve never seen this index used when in reality, it’s doing a bunch of heavy lifting for a once a month or a quarterly query. The changes that we made to the most used, unused and the inefficient reports is that you’re able to switch between that historic and that real time, which will get you that data from the last restart. So if you’re using this in conjunction, you’re testing which indexes are going to be the best for your query, and you’re doing a bit of performance monitoring there, or bit of performance tweaking. I should say, switching to real time is going to give you a better view of what’s actually being used versus historic. If they’re kind of new, maybe you’re not getting or you’ve changed the index a little bit, maybe you’re not getting the most up to date information with that. So that comes from a user. It was a super cool request, one to be able to work with a user to figure out what works best for them, but also see why it works best for them, and how many use cases this can actually go into before we go any farther, can we clarify the definition of real time and historic?
George Stedman 14:43
So the historic is all time. Real Time is since the last reboot, correct? Yeah, yeah. Okay, yeah. So the historic is last few minutes, or anything. It’s since the last.
Mitchell Glasscock 14:59
Yeah. A couple enhancements. They’re not the most flashy things, but they are also from user quests. Is a bit more of that drill down functionality that we’ve been kind of just adding in the database, health monitor. We add these big overview reports all the time, but sometimes we forget that they correlate to other reports. So we added, a while back, we added the blocking by hour, and the blocking queries reports, and they’ve kind of just been in Database Health Monitor for a long time, but clicking on them hasn’t done a lot. But since then, we’ve added the ability to click on these, and it takes you to a historic blocking history and shows you what was blocking during that time, brings up your query and what was going on for better troubleshooting of what has been happening In the past.
George Stedman 16:00
And another note on those weekly heat maps is we adjusted the color scheme a little bit as well to properly reflect good versus bad behavior that you should be looking out for. So we changed it used to be baseline. If it was zero, it would just be white, but now it’s green, saying, okay, good to go, whereas the red is definitely, yeah, you don’t want 100% blocking, so it’s going to be red, and then it scales between orange and blue. And different colors kind of give you a quicker realization of where things went wrong when another drill down that was added was the CPU by database.
Mitchell Glasscock 16:36
So this report is another one. CPU by database has been in Database Health Monitor before. I’ve been a developer for Database Health Monitor, but the CPU by query was one that was added in the past year, and they’ve kind of just been there. They’re both correlate, but we’ve never connected them until now. So we know that the if we look at this database, health history database, is the one that’s using most of the CPU on the system. This isn’t a super accurate representation, since this is a test server, should different instances run on it, but this is using up 6.6% and if we click on that actually takes us into the DB health history CPU query report and shows us what queries are using up most of that CPU. So another one that’s easy for troubleshooting. You open that CPU by database report and you are wondering, oh, hey, what’s actually going on under the hood there? You’re able to drill down and figure that out quick. All right, last thing that we’ve added to this release backup status report. The backup status report, for the longest time would only show the most recent copy only backup. So if you have VM software like VM taking backups of the database, it adds in a copy only backup so that it doesn’t break the backup chain for SQL Server, and that’s all tracked in the back end of SQL Server backup information. But the backup status report would oftentimes show that those copy only backups. I don’t think this is a great database to show it on. Let me see if I can find a better one. While I’m talking here, it would show those copy only backups and not a proper back chain there. Nope, I don’t have any. But now you’re able to hide the copy only, and you’re able to see when that last truthful was, when the last differential was, and that last log giving you the more accurate backup chain to look at, instead of having a backup only or a copy only covering the right chain.
George Stedman 19:18
And that’s pretty important, because sometimes those copy backups that beam or like Amazon does or Azure, not to throw names out there, but sometimes those backups take way longer to restore small mistakes than normal SQL backups, because you pretty much restore the whole instance, the whole VM, the whole the whole thing, and then if you just made a small mistake, that’s a pretty major downtime to switch back to that where, if you have a proper backup chain with logs, diffs and fulls, you can restore smaller mistakes much quicker.
Mitchell Glasscock 20:01
Here and without having any downtime. So we added this. We added the hide copy onlys is looking at the backup status is a great way to ensure that your backups are happening properly, like if you have the old scripts in place, and you want to make sure that those jobs are all running correctly at the same time, the backup status reports a great way to view that. But if you have those VM backups happening, I mean, how often do you see them running, every 1530 minutes that the VMs doing a backup, and so it ends up just covering that true log chain, which you should be other than that. Think that’s all the changes that we had scheduled to go over for today’s podcast. Did we want to get into anything else? Oh, actually, we have one other features we’re working on. We do have a little feature, feature back to that version, store conversation. Because of that, we’ve added a new or working on adding a new Temp DB allocation chart. So what this does is it shows you how Temp DB is currently allocated and what is inside that. So you do have version, store, what we were talking about, our CSI and alter you have your internal objects and then your user objects. So this chart is a great way to see how that’s changing over time. Here’s one day. I mean, it’s very small because it’s my test environment, but here’s one day that I was playing around with RCSI and moving things around to see what happens. So you can see this is an abnormality, easy to see on the chart, but you should be seeing this in the next release, which should be shortly after this podcast comes out. Think that’s it.
George Stedman 21:55
Think that’s all we had.
Mitchell Glasscock 21:56
I think that’s all the features that we had. Again, we do appreciate everyone reaching out and providing feedback on Database Health Monitor. It’s super helpful, especially as the developers, to get some information from our users and figure out where to take this project next. Of course, you can always check out database health.com and seven solutions.com. For more info, then you can also check out our last podcast episodes, which are up on YouTube. Thank you everyone for watching.
Steve Stedman 22:42
Thanks for watching our video. I’m Steve, and I hope you’ve enjoyed this. Please click the thumbs up if you liked it. And if you want more information, more videos like this, click the subscribe button and hit the bell icon so that you can get notified of future videos that we create.