- Host: Steve Stedman / Mitchell Glasscock
- Recording Date: December 4, 2025
- Topic: A year recap of the features added to Database Health Monitor
- Listen on Spotify!
Stedman SQL Podcast Season 2 Episode 29 Database Health Monitor Recap 2025
Database Health Monitor: All the Exciting Features Added in 2025! Join Steve Stedman and lead developer Mitchell Glasscock as they recap an incredible year of updates to Database Health Monitor, the ultimate SQL Server monitoring tool. From December’s Structure Change Log (track who changed what in your databases) and Disk Space Forecast Report, to sortable timeline charts, TempDB allocation insights, enhanced drill-downs, the major Version 3 release with DB Assistant, revamped Performance Monitor, CPU by Query drill-downs, deadlock tracking, email alerting, and more—this episode covers every major enhancement that makes troubleshooting faster and proactive monitoring easier. Whether you’re dealing with blocking, deadlocks, open transactions, index issues, or just want better visibility across your SQL Servers, these real-world features (built from client feedback) will transform your DBA workflow .Download Database Health Monitor today (30-day free trial) at http://DatabaseHealth.com and start using these tools on your servers!
Podcast Transcript
Steve Stedman 00:18
Hey everyone and welcome to this episode of The Stedman SQL Podcast. This is season two, Episode 29 and it’s December of 2025 I’m your host, Steve Stedman, and joining me today is Mitchell Glasscock. Mitchell is the lead developer on the Database Health Monitor project, and he also helps with supporting our clients. Welcome Mitch. And welcome all of our listeners. It’s been a big year on the podcast. We have 29 episodes that’s been a lot going on. So this week, our topic is we’re going to talk about the Database Health Monitor features that were added in this whole year. I think a little bit of background there with Database Health Monitor, something I’ve been working on for 14 or 15 years now, something like that. I forget exactly then Mitch has been working on it for a couple years, and I think that it has really evolved with Mitch and then another developer, George working on it, and we’ve been able to get a lot more completed in the last year or two than we have for the few years before that. So we’ve had a lot of growth in the feature set that’s included in Database Health Monitor. All right, so on to this episode on the Database Health Monitor, features that were added in 2025 now we’re going to take a little bit of a backwards approach, starting with the ones that were just added in December, and then walk back through the year on things we added there. So I guess at this point, Mitchell, if we want to share your screen, we can take a look at some of the new features that were added in the version 3.1244, release in December. And the first one, do you want to tell us about the structure change log?
Mitchell Glasscock 02:13
So let’s go into that one. Steve, I know this one was kind of it was your idea to implement, and we kind of work together on this one. So I kind of want to ask, before we get into it, I’ll pull it up. But what was kind of your motivation for adding this one to do with the Health Monitor?
Steve Stedman 02:32
So this started with one of our clients that we were working with that was looking for a way to be able to track who changed what and when on their database. A number of clients we work with have different audits that they go through and things like that. And it’s just one of those things that being able to report and show what was changed on a database, specifically on the structure. And then I started thinking, well, two or three years ago, I worked with a client that was using something similar to this, and I went out and tried to find the script that the other client was using that I think was open source, and I couldn’t find it anywhere. So it’s not, I mean, it’s one of those things that I decided, well, I’m just going to implement it. So I implemented the way to track all the changes, which uses a database trigger, and can you can turn it on to track specific databases. And then, Mitchell, of course, you went in and added all the user interface to be able to display it and see what’s happening with it. So it was kind of a joint effort there, but it was because of a specific customer request that they wanted a way to be able to track what was changing in their database. So when you first start this up, this list is of course, going to be empty, and as long as you’re running the latest version of Database Health Monitor, what you need to do is to turn on the structure tracking. And if you click the button there, we can see that there are four user databases on this SQL Server, and that it’s been turned on for all four of them.
Now, when you first do this, it’s not turned on for anything by default, so we just install some features and things to track it, and there’s no triggers added to your database, until you go into this screen and click the check boxes to turn these four on. So you go in, you turn those four on, you hit alter triggers, and then at that point, it’s going to track any database changes going forward. Now, it’s not going to prevent any of them from happening, but it’s going to catch them, track them, and then display it in a way that we can go in and see over time, who did what and when, and if we look, gosh, I almost need my glasses for this one, just because of the size of my screen resolution. We’re recording that here. But if we look, we can see on this, there we go, on the SQL Server. There are some changes that have been made. And if you see the login name is SA there. This is our test SQL Server 2025, environment we just set up. So I’m logged in as the SA user, so all these things that were tracked here were tracked were done by me as part of installing and updating Database Health Monitor or running our testing scripts. So if you make that database column a little bit wider Mitch, we can see that the database blocking test is showing up quite a bit in there, and then database health history is showing up as well. And if, if we look, we can look at the timing and see that exactly when these changes happened, what server it was done on, what database it was done on, and who did it, and what kind of an object was it? A table, an index procedure, and then from there, we can double click on one of them to go in and actually see the SQL that was run for a create table like right there. That’s creating a test table that just has some int identity and a unique identifier in it. And that was part of my test script, was adding and dropping tables and things like that. The one thing that we don’t log with this is we don’t log alter index with rebuild or reorgs.
So we hope everyone’s rebuilding and reorganizing their indexes appropriately. We didn’t look at that as a structure change, because that’s just a normal maintenance thing. But if you’re adding or dropping or changing an index, that’ll show up here. If you’re adding dropping or changing tables, procedures, logins, any of that kind of stuff, will be tracked here. So and it’s just a way to be able to see what’s happening with your database. If you turn it on and you don’t like using it for whatever reason, you just go back into that setup structure tracking, and you can uncheck the databases and turn off the monitoring for a given database. It’s that quick and that easy. So that’s one customer request, and it’s a handy one to be able to track, to know who’s doing what on your server if you’re in a production environment, this is great to know who might have changed that production environment. But let’s say you’re in a dev or test environment and you want to know what changes have happened that you need to roll out to roll out to your production system. This is a great tool for tracking and monitoring that. Okay, next in our December release was the disk space forecast report, and that one was all you Mitch, so I’ll let you I’ll let you take that one.
Mitchell Glasscock 07:18
Sounds good. So one of the things that we do pretty frequently with clients, this one was kind of a personal project of mine. We do a lot of stuff with backups and backup strategies, and a lot of that involves figuring out how much space we’ll need on disks, how long we’re going to keep backups around, so retention periods and whatnot, and figuring out, how long can we keep a full backup around? How long do they need kind of stuff? And we could go, I mean, we have podcasts in the past that cover backup strategies. That’s a whole other topic. But the reason why we made this disk space report is to be able to forecast how much space is going to be used, not just by backups over time, but everything that’s going into these disks. So what this does? It takes the past you set your retention period, and the disk space is logged for as long as we have that retention period. And then it takes that average slope, and it forecasts how long we’re going to be using that disk, or how long until that disk is going to be full space. So we can look here and we see that we have 18 gigabytes free on the E drive, and we are estimated to run out of space if we keep this trend up. 2026 March, 1, 2026, so we have about 87 days until that one runs out.
Steve Stedman 08:50
Yeah, so that’s looking at our server that I’ve called Modern SQL, which is where we’re running our three instances of SQL Server, 2025, and I think if this was a production system, and we saw that, it was going to run out in 80 to run out in 87 days, might be a little bit concerned, and want to start talking to the client about, let’s get some more disk added here. But this was a VM that I specifically tried to build out as small as I could for running SQL Server 2025 and I assumed we would have to add space to it. So I’m not too worried about this one. We’ll, figure out how to get the space added in plenty of time. But it also, it’s one of those things that the more history we have here for the disk space over time, the better it’s going to be able to forecast the future. I mean, this one here, this new SQL Server I built, is only a week or two old, where if you’ve got six months worth of data, we’re gonna have a lot more accurate forecast of how long it’s going to last. And we, I looked at a server the other day with this, and it looked like looked like it was like somewhere around 2045 is the year was when we run out of disk space on that one. So that was a good piece of mind to know that we don’t have to be talking about more disk space there yet.
And then we had a couple other just small features that were added. One was a way to terminate sessions on the open track. Transactions report. And that open transactions report was added a release or two ago, and it was one of those things that like, literally the day after we released that report, I found problems on a client site because somebody had left a transaction open, and then I went to management studio and I terminated that. But here we can see what transactions are open, and you’ve got the option to just go in, get details on it by what we can view here and just kill one of those sessions. Now this has three SQL Server Oh yeah, go ahead and terminate that one. This has three SQL Server Agent jobs that are running and they’re opening transactions and leaving them open, and specifically jamming up this test server to simulate something bad done by someone who left a transaction open or a long running transaction. So normally, in a healthy environment, you’re not going to see open transactions staying on this list for very long or even every time you’re using the server. That was a nice one. Thanks for adding that. Mitch then the sortable timeline charts you want to show us that one,
Mitchell Glasscock 11:05
yeah. Let me jump to another server, yeah, that modern SQL that I set up with 2025 is sort of a almost clean, pristine and empty server for the most part right now, other than some tests, test stuff I put on it,
so the timeline charts are everything that utilizes this new timeline chart. We have it in a couple different places, but the most prominent one is going to be the job history instance report. And this is a great way to visualize your job history in SQL Server, because it’s a little bit difficult to know how often it is if you’re just looking at SQL Servers Job Manager, because you’re just getting a text based so we decided to create a more visual based way to audit how often jobs are going off. But what we’ve done is these headers in the job history report, and sorry, also the backup history report, which can be found in the database level. You can click on any of these headers, and it will sort these jobs based on when they fired off. So anything that has a section inside of that, this would be the hour it’s going to put it up at the top so you can see, if we want to see what jobs are running at 3am we can see that these jobs, everything from replication agents, check and up, are firing off at that 3am time slot.
Steve Stedman 12:38
Okay, yeah, that’s great. I know when we first did this report, before we had that sorting feature, what I would do is I would visually scan down through like the 3am column to figure out what was running at 3am and yeah, this adds some functionality there to make that task a little bit quicker.
Mitchell Glasscock 12:54
And especially when you’re running like 20, 3040, jobs on a SQL Server. It makes sorting this and looking at.
Steve Stedman 13:01
Okay, great. Well, that kind of wraps up the big features that were in December. Why don’t we take a look at some of those from October? Let’s, let’s just show the Temp DB allocation history report. If we’ve got a good database that’s or a good server that’s going to show some interesting data there. The problem is, with Temp DB is that this report is really valuable on production servers that have real workload, but here, being a test server doesn’t get quite as interesting as a real production server. You want to tell us about this one.
Mitchell Glasscock 13:35
So we created this two months ago, and this kind of goes hand in hand with the open transactions and Temp DB report, because we’ve started to run into RCSI becoming more prevalent, we’ve started to run into more Temp DB balancing with clients. It needs a bit more focus as that becomes more in use. Option for SQL versions popular now,
Steve Stedman 14:00
Just to jump in on that for RCSI, that would be READ COMMITTED SNAPSHOT ISOLATION level. And if you’re not familiar with that, we did a podcast earlier in the year, and hopefully, when we get this edited, we’ll have a little display here of what that podcast link is. But there was another podcast earlier in the year that talks all about RCSI in order to use it to prevent blocking. But the side effect is there’s a lot more load on Temp DB. So back to you Mitch.
Mitchell Glasscock 14:25
Right, and I don’t want to say RCSI is a bad feature. In fact, we prefer it 99% of the time and recommend it for pretty much every but with it comes a downside of if you leave an open transaction running, and then you try and run other things against that open transaction, or the same database or table that that transaction is running against, you can cause some soup, some extreme bloating in Temp DB, in the version store, specifically where we’ve seen Temp DB explode. Clients haven’t noticed it in the past, or it’s caused. Used it to fill out an entire drive. So this allocation is to help better balance Temp DB and figure out what is going on, whether it’s an open transaction and RCSI causing it, or possible large queries that are using user objects and temporary tables and whatnot. So it’s a bit of a balancing game.
Steve Stedman 15:21
And what we ran into when you use the term blowing up Temp DB? Well, we had one client we were working with that actually had a four terabyte Temp DB on a system where all the other databases weren’t even anywhere near four terabytes so and that was because of RCSI and an open transaction. And we did a bit of digging in to find out why it was so big. And we were able to find out that it was the version store. And had we had this chart at the time that occurred, I would have just looked at the chart and seen, oh, gee, the whole chart is all green, which is the version store, therefore we know it’s RCSI related.
Now that kind of leads us into the open transactions instance report that we already looked at when we looked at, how do we kill sessions. But if you were having that kind of issue, typically, what you’re going to see, if RCSI is bloating Temp DB is that this is going to be an up into the right chart, which, when you’re looking at sales numbers is a great thing, but when you’re looking at Temp DB size is a really bad thing. That gets bigger and bigger and bigger over time, and you’re going to see open transactions that are typically going to show up in that open Transaction Report, indicating that we’ve got some something there that’s keeping that version store around rather than letting it clean up over time. Well, I think given the time we have here and the number of features we have to talk through, don’t think we have the time to show everything on the list on screen begin. We’ve shown all of those on other episodes, but what I was thinking is we just talked through some of the different ones, if that works. So the other thing we’ve really been focused on is the concept of drill down everywhere. And we don’t have it everywhere yet, but we’re getting closer and closer every update we do. And what that means is on every report, every screen and Database Health Monitor, a way to be able to click and drill down and get more information.
Example was the blocking by hour. For a long time, we’ve had that report there, but we had to go elsewhere to view the blocking details in that release. We were able to add in that was, I guess, the October release. We were able to drill down and view what queries were blocking in that in that hour. And that was a really handy thing to do there. So that brings us to August 2025 that was the big version three release, and we had a lot of features in here. But the one thing that really changed in version three was the licensing. And I want to take a minute to talk about that. And then how about if you dive into the DB assistant after I cover licensing. Mitch, so when Database Health Monitor started, I started 1415, years ago. It was a beta. It was totally free. Everyone could use it. All I wanted was feedback. And then that sort of evolved into, well, you get it free if you do something, but you can still buy it. And you could, by subscribing to my mailing list, you could get one free session, and that really wasn’t sustainable, because what we found was that there was a lot of work that needed to be done, and that’s why I had to hire Mitchell, and I don’t mean that like a bad thing, but that’s why we got to hire Mitchell and George, who both of them work on this, and there’s expense with that. So what we decided when we did the August version three release was that going forward, we would no longer be doing a free version. Now that’s almost true. We’ve if you try it out, you can download and use database, health monitor, free for 30 days, 30 day trial. When that 30 days expires, you either need to stop using it or pay the licensing fee for it. We have probably the absolute lowest licensing fees for any kind of a monitoring tool like this per year. I mean, I think it’s like $399 and you can get up to 10 servers, or maybe that’s 20 servers, I think, to monitor per year, and that’s just way less than any of the competition out there. So we’ve tried to keep it really cost effective, but also we do have to charge and make it in a way that we can pay to maintain the product, basically. The other thing is that for our customers, our managed service customers, or our regular mentoring customers, Database Health Monitor is free for them. It’s always free for them, because those are our regular customers, and we just don’t want to nickel and dime them with a bunch of fees. But for the people out there who are just using database, health monitor and maybe are not a regular customer of ours, yeah, you got to pay at this point. We can’t. We got to the point where we can’t give it away for free anymore. So how about DB assistant? What’s that? Mitch, that was in the version three release.
Mitchell Glasscock 19:57
I guess getting into it version 3.0 is kind of. Just a pivotal change for Database Health Monitor, not just in the licensing, but we just, we started digging in, really, at the beginning of 2025, and we, we started moving into this DB assistant. We’ve, we’ve always had, I almost want to compare it to our quick scan report. We’ve, we’ve always had our quick scan report that is a great way to see what items you need to look at in your SQL Server and fix just to buckle down and create a more bulletproof SQL Server. But the DB assistant is kind of a hand in hand with that quick scan report, and it’s it will actively run checks on your SQL Server to see if you’ve been keeping up with that improvement, or it will help you find areas of improvement on your SQL Server, whether that’s configuration settings or we have, like the long running open transactions that will catch that for you there. So anytime you open up Database Health Monitor, it’s super easy just to hit scan now with the DB assistant, and it’ll give you a ton of feedback on what’s going on in your SQL server at this moment.
Steve Stedman 21:22
Along with options for many of them to go and fix them. Now, if it says something like slow IO, it might not give you a way to go get faster drives, but if it’s something like a parameter or setting that’s not set correctly, it’s going to tell you about it and then give you the option to just say, fix it and get it set correctly right so.
Mitchell Glasscock 21:40
And then, alongside that, we have, I mean, we’ve done two years of podcasts now and tons of videos on recommendations for SQL Server. And from that, we’ve made a DB assistant will record, recommend videos that you can watch that revolve around these configurations that we recommend through it.
Steve Stedman 22:03
The other thing that we did in the version three was we completely revamped the Performance Monitor. The Performance Monitor is a tool you can get to in Database Health Monitor by right clicking on your instance and opening the Performance Monitor. And it’s a tool that’s designed so if you’re having a problem right now and you want to come up with understanding like what’s going on with blocking or what’s going on with missing indexes, or what’s going on with sessions. It runs and it focuses on all those things. These were all things that could be done in Database Health Monitor and four or five different charts, but it puts them all into one, and really, it’s designed in a way to be able to help you find what you can do to fix a pain point with performance right now. But there’s also a time capture mode on it where you can start it up and say, run this for a certain amount of time, say, 30 minutes, and then email me when the report is done. So I don’t have to actually be there watching it the whole time. I can just start it and then get a report 30 minutes later. So that was a that was a big change in version three, and then we already showed the job history timeline chart when we looked at the sorting on it, so we don’t need to go into detail on that, but that was new. This year, we added a problem indexes report. Now this is one of those things that there’s a lot of things you can do out there to really mess up your indexes, or really confuse what might be happening with your indexes, like the way to have an index but to have it disabled so it’s not actually being used, or to have indexes that are done poorly or bad fill factor, things like that. So that indexes report is designed in order to be able to show you and go point out some of those that may need attention.
Mitchell Glasscock 23:39
Another instance, report the CPU by query report. This one is really good, hand in hand with the CPU by hour. If you’re just looking at the by hour view, you might not know exactly what’s eating up all that CPU in in your server. So through the CPU, we have the CPU by database report. But by clicking on one of those databases, it will take you to in that report, it will take you to the CPU by query report, which will show you what queries in that database are eating up all that CPU, so you can figure out what needs to be performance tuned in that area.
Steve Stedman 24:15
Yep. So one of the common things I’ll look at with that now is if a server is high CPU, which is a common thing we deal with, is I’ll go look at what database has the most CPU. And usually there’s one database that has more than 50% of the CPU, and then all the other ones are taking the other 50% or less. So I’ll go drill down on that one database that’s got the most CPU, speaking of drill down or click everywhere that we talked about earlier, and it’ll jump right to the CPU by query report and show which queries in that database are really being the biggest CPU hogs. And sometimes we look at that and think, yeah, that’s going to be as easy as adding in an index. And other times it’s going to be like, Oh my gosh, that’s going to rewrite 2000 lines of storage. Procedures in order to be able to fix it. But it really comes down to giving the giving you the tools you need to find those problem areas so that if you are overloaded on CPU, you can make the decision of, well, do I can I fix that somehow, or do I just need to add more processing power to the SQL Server?
So another thing that we added in the version three release was the rewards program. And this is basically you get stuff. That’s it. You get stuff for free, for from us over time by being a longer term customer. So paying customers now unlock exclusive features over time to thank you for supporting for supporting us. Now the rewards program is not available for free, trial customers, only, paying customers, and you get things like a free some of our classes you get for free, and some of them you get a free, what is it? Half hour of consulting to help make sure you have Database Health Monitors set up, right, and things like that. And to get to that, you just go into the Rewards Program tab in Database Health Monitor, and from there, you just claim it. And if it is one of the free classes, you just get coupon codes to join and be in the class for free. If it’s if it’s a free 30 minute consult, you get the scheduling link to be able to go in and schedule and get it on our calendars, and then we help you with that, and there’s other things coming. We’ll have more. That’s just the first few rewards there. And it’s intended that if you’ve been using the product for two or three or four years, you’ll have a lot more rewards available than someone who just started using it today. Now, because the licensing and version three all started out fresh with the rewards program. Everyone started fresh as of, I think, August, when we when we got this out. So at that point, rewards just start collecting and building up over time for people. So you can go in and check those and check them often. Let’s see. That brings us back to our it was a big gap from April to August when we were working on the version three release. And that brings back to some of the stuff that was in the April release, like SQL Server, email alerting. That was a feature that you added Mitch. Do you want to talk about that?
Mitchell Glasscock 27:12
Yeah, we can get into that. It’s another one of the kind of side by side feature to Database Health Monitor, open it up, and you can start configuring these email alerts, which will run as an agent job on your SQL Server, and it runs checks against your server to ensure that nothing’s going wrong. So you can set all of the configuration values different thresholds for it, and then it will send an email to whatever email address you specify in case anything goes wrong.
Steve Stedman 27:45
So what kind of things would I want to be alerted on with this email system, or could I be alerted on?
Mitchell Glasscock 27:51
Currently, we have a few alerts built in, so stuff like blocking job failures. We also have like security X amount of logins that fail on your SQL Server, it will send an email alert to.
Steve Stedman 28:06
Then a couple of other that were added in that April 2025, release was the TDE status instance report, which, with more and more of our clients being in finance and healthcare and places that they need encryption on their database, we really needed a report that we could check on and give status of what has been TDE encrypted, and is it all good? Then we also have the table use report that came out of a client asking, When was the last time a table was actually queried or used? And the question came up of, how can we identify tables that aren’t really being used, and that’s what the table use report is for. Then that takes us back to February, and February was a lot of deadlock stuff. We added deadlock tracking. Instance level reports for deadlocks by hour, deadlocks by database, database level reports for deadlocks by hour, deadlocks by object and full deadlock history. And then a deadlocks advisor is a screen that shows you the graphical breakdown with the winner and the victim queries. And from there, you can make the decision of how to go and fix and deal with deadlocks. I think prior to adding this, you could get deadlock information, but you had to turn on things like deadlock graph in writing to the log, or you could go and query the extended events to get it. But what this does, it just runs and captures those so you can look at it over time to see, are our deadlocks improving or are they getting worse. And I think I don’t even remember what else that February release had, other than maybe some bug fixes and all about deadlock tracking.
Mitchell Glasscock 29:48
I kind of look at those, or I don’t look at those side by side, but it kind of goes hand in hand with the blocking report. But can you kind of give a breakdown, just a quick overview of the difference between what deadlock. Blocking versus blocking is and why we have two different reports looking at each of those?
Steve Stedman 30:04
Oh, yeah, for sure. And this is one of those that I should have given when we first started talking about it. I usually do, because there’s a lot of confusion out there over this, and things can happen on SQL Server that jam up queries. And there’s different, different ways that queries can be jammed up, and I think of it like being in traffic. So if you’re trying to get on the highway, and you’re on the on ramp and there’s 30 cars in front of you that’s just slowing you down because you’re blocked by those 30 cars in front of you, and especially if you’re on one of those on ramps that has a stoplight on it that slows down your you getting on the highway. Now that’s sort of the equivalent to what happens in SQL Server with blocking. Where, with blocking, something is holding up some resource, a table index, whatever it may be that’s preventing you from preventing another query from running, like preventing you from getting on the highway if the on ramp is all jammed up.
Now, the flip side of that is deadlocks. Deadlocks are different. So I think of deadlocks more as a way of two people trying to pull into the same parking lot or the same parking spot. And Mitchell, if you’re an aggressive driver and I’m a crazy aggressive driver, and we’re both trying to get into the same parking spot, well somebody’s got to give up, because there’s no way we can get both of our cars in that same parking stall. And what SQL Server does is it detects those kind of, that type of a conflict, and it decides that, well, one of them is going to be the winner and one of them is going to be the victim, and it terminates the victim query. Now the what usually happens with deadlocks is that it’s the order of tables that are being accessed. So if I have a query that’s accessing table A and then Table B, and you have a query that’s accessing Table B and then Table A in the opposite order inside of a transaction, if I take a lock on one table and you get a lock on another, and then we both try and modify the opposite table, that’s a deadlock. And that’s where SQL Server is put in a position where, because one is blocking the other, there is no way that will ever clear, and it chooses to terminate one of them, whereas with blocking, which we’ve been had monitoring Database Health Monitor for many years on that that tracks what queries are just being slowed down because of other stuff happening on the server, Like the on ramp example. Now with blocking, it might be that the blocking is so bad that some of them are jammed up for minutes to hours, but the basically, the difference there is that with deadlocks, it’s something that one of the queries is going to be terminated and whatever that query was intended to be doing is going to be killed and ended, whereas with blocking, it’s going to slow things down, or maybe slow things down to the point it looks like things are permanently jammed. But with blocking, it will eventually clear. If you have enough time and enough CPU, it might be that you’re throwing so much load at it, though, that the backlog gets so great that it may never clear, right?
Mitchell Glasscock 32:56
And it’s two different kind of approaches to fixing that. When we see them right? It’s when we look at blocking versus when we look at deadlocks. It’s the reason why we have the two different reports is because we have to take a different approach to fixing whatever the issue is at that point.
Steve Stedman 33:14
So with blocking, generally, we’re taking a look at, how do we take that thing that’s blocking and speed it up or make it block less. For instance, adding an index might speed something up so it doesn’t block as long. Or turning on RCSI READ COMMITTED snapshot isolation level may make it so a query does not block as much. Read query does not block as much as it used to. But with deadlocking, it’s a different approach, where you have to typically go in and look at the logic that’s happening inside of a transaction, and figure out, how can you change the order of access of tables around a little bit? And if you look at a deadlock and you say, well, that’s the way the business logic has to happen, and there’s no way around changing that order, well, you’re stuck. You’re you cannot get around those deadlocks if you can’t fix one side or the other to access the tables in a different order, so sometimes that means you’ve got to do a little bit more work up front to go and figure out what’s going to happen and then make your transaction a little bit smaller or tighter. But yeah, deadlocks are definitely a different beast than dealing with blocking or locking. All right? Well, that brings us back to our January 2025 release, which was big revitalization of schema drift and bundling that with Database Health Monitor. So anyone who’s using or installed Database Health Monitor has access to schema drift to be able to go and compare two databases and see what kind of structure differences there are between those databases.
Mitchell Glasscock 34:38
And that’s another one of the side by side tools that comes along with Database Health Monitor. We have the email alert system, the performance monitor, and then schema drift, which are all kind of just the ecosystem of Database Health Monitor that we’ve rolled out within, yep.
Steve Stedman 34:53
The difference with schema drift is it is available as a standalone download outside of Database Health Monitor. If you want where the others, you have to have Database Health Monitor to be using them. So, yep, okay. Well, then the other thing that was in the January release was the SQL Server health summary report, one big report that will you basically right click on the instance in SQL Server, and you say, give me the overall health report. And it goes and runs like 20 different reports and brings it all back and puts it in a Word document or PDF, so that you can then save that off or use it over time in a way that you’re pulling all that information and not having to go browse 20 different reports to get it.
Mitchell Glasscock 35:35
And then I think one other thing I don’t believe that we’ve brought up or talked about, but we’ve added this year is the command line parameters, which are a similar functionality. Instead of running the health report yourself, you can automate through command line parameters that we’ve added it to Database Health Monitor to pull these instance reports as well.
Steve Stedman 35:57
And Good point, good point. And that was also done for a request from a client for auditing purposes. So the other one that was added was related links on the top of all the different reports on database or instance level. And this, I don’t know, as far as features go, this might be one of my favorites, because it saves so much time if you go and you look at the deadlocks report instead of having to go back and click the instance report to look at blocking. It gives you a suggested related link, so you just flip from blocking to deadlocks, to what is active, to things like that. And it’s just a way to navigate and get around the system a lot quicker the Related Links. I mean, it’s not a gigantic I don’t know it’s a great feature, but it’s not one of those like massive Earth breaking kind of things, but it just saves so much time using it. I’ll tell you that, all right. And then with that related links, I think Mitch mentioned this earlier, there’s a lot of YouTube videos that are linked to on the related links, to give you more information about a specific topic. So I think overall, that’s kind of a review of the features that were added in Database Health Monitor in 2025 it started as a pretty great monitoring tool, and now it’s even better, and we hope to evolve it again over the next year with more and more features and functionality. But whether you’re out there fighting fires or proactively tuning your SQL Server, these features were built based on real feedback from 1000s of DBAs, maybe not 1000s. Hundreds of them gave us feedback. Lots of them gave us feedback, and a lot of them have come from things that we run into as well working with clients specifically where they said, What if we could have this, or what if we could have that? So if you haven’t tried Database Health Monitor, why not? I mean, it’s free to try for 30 days. You can download it at database, health.com, and you get access to all the features, I guess, except for the rewards program, because that requires payment. But you get access to all the features for that 30 days. And if you want to continue using it, it’s one of the cheapest price wise monitoring tools out there, but not the cheapest. Quality wise, we have high quality product that we use every day with all of our clients, and it makes a big difference. So here’s two healthier SQL servers in 2026 because of what you’re doing with Database Health Monitor. Anything else to add on Database Health Monitor?
Mitchell Glasscock 38:16
I just want to say thank you to everyone that’s provided feedback in this last year, it’s been a huge all the improvements that we’ve made to Database Health Monitor, and it’s really helped to shape the future of Database Health Monitor. So give it a try. We definitely listen to all that feedback, and we really appreciate it.
Steve Stedman 38:36
And as we come down to the year end and episode 29 of season two, I want to thank all of you, all of our listeners, for listening and giving us feedback along the way as well. Mitch, thank you for joining me on this episode, as well as many other episodes you’ve been on this year. And just please stick around for our 2026, episodes. We’re going to go look at some more interesting things related to SQL Server and databases in the next year. All right, thanks for listening. Have a great day.
Steve Stedman 39:21
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.