- Host: Steve Stedman / Mitchell Glasscock
- Topic: The upcoming release of Database Health Monitor v3.0 and the exciting updated features
- Recording Date: July 30, 2025
- Listen on Spotify!
- Download Database Health Monitor v3.0 here
Stedman SQL Podcast Season 2 Episode 23 Database Health Monitor v3.0
In this episode, we share the exciting upcoming release of Database Health Monitor 3.0, packed with powerful improvements to help you monitor and manage SQL Server more effectively. The new DB Assistant provides guidance and insights to simplify performance tuning. A new Job History Chart makes it easier to visualize SQL Agent job performance over time. Problem Indexes reports at both the instance and database level help you quickly identify indexing issues. The Backup Size report has been completely revamped to give clearer visibility into backup growth, while the new Database Backup Time Frames report shows when backups are running in your environment. We have also added a new Log Shipping instance report to help you monitor the health of your log shipping setup more efficiently. Alongside these new features, we are also introducing the Database Health Monitor Rewards Program. This program is our way of thanking the SQL Server community by offering exclusive benefits, early access to features, and special rewards for those who continue to support and use Database Health Monitor. Join us in this episode to learn how Database Health Monitor 3.0 can help improve your SQL Server monitoring and how you can take advantage of the new rewards program.
Podcast Transcript
Steve Stedman 00:15
Hey everyone, and welcome to the Stedman SQL Podcast. This is season two, Episode 23 and I’m your host, Steve Stedman, today I’m being joined by Mitchell Glasscock. Mitchell is one of the developers, well, the lead developer on the Database Health Monitor project, and we’re going to be talking about some of the new Database Health Monitor version three features that are about to be released. We’ve been working on for about six months, and we’ve got that release ready to go. We’ve been testing it for over a month now, and we think it’s in a position to start using it at this point, I’d like to welcome all of our listeners. We’ve got some, a lot of podcasts. I mean, we’ve what, 23 and a few dozen last year. So check out some of the older podcasts. And just a reminder, if you like this episode, please click the like button. And if you want more like this, hit the Subscribe. So at this point, I’d like to say, hey, Mitchell, welcome to the podcast. Let’s talk about Database Health Monitor.
Mitchell Glasscock 01:14
Sounds good. Thanks for having me on.
Steve Stedman 01:16
So let’s go ahead. I mean, so little bit of history here, I guess, before we jump into it. So I started creating Database Health Monitor about 13 years ago, something like that, and it was basically something I started building as a tool to help make some of those daily DBA tasks a little bit faster. And then you joined us, what about a year and a half ago now? Yeah, and you’re our first officially full time person that actually works on Database Health Monitor. So that’s great news. We’ve been able to make a lot of progress over the last year and a half because of that. So yeah, what we did a few months back is, instead of slowly trickling out some of these features, we decided to fork the code and start working on that 3.0 branch and version 3.0 Is, is ready now. So let’s talk about what we’ve got in version 3.0.
Mitchell Glasscock 02:11
Yeah, we definitely have a lot of big, exciting things that we’re looking forward to showing off. So, lets, jump into it. I think the first one we want to do is kind of this, this new panel here, once you launch Database Health Monitor and go into your server, you’re going to see this new panel. It’s, it’s the DB assistant.
Steve Stedman 02:28
What does that do?
Mitchell Glasscock 02:31
DB assistant is a, if I want to say, AI, I’m trying to guide myself away from that. But DB assistant is our homemade assistant that will analyze your SQL Server environment, and it will provide suggestions for you for changes that can help increase the performance of your SQL Server.
Steve Stedman 02:55
Yep, and this is something that we initially added about four months ago, and I think that was maybe the thing that really caused us to branch the code to really start working on this as a separate release, because we’ve got so many things in here. So do we want to start the analysis and take a quick look?
Mitchell Glasscock 03:13
Yeah, let’s show off how it works. So once you hit “Start Analysis”, it’ll start running some background checks. And we can see here it’s started to run these, and it’s found one that it thinks it needs to report back on. So if we look at this, the max server memory has been set. We read through it, max server memory is set to the default value, so that’s high. And then it’ll provide some options over here where we can set to 5% we can set it to 5% or 1734 megabytes.
Steve Stedman 03:55
Okay, so just a note on this, because you might be looking at this thinking, Oh, setting max server memory to 5% of the server memory seems a little bit weird. Well, this is because it is multi instance aware, and this is on our test server that we have like 16 or 17 different instances running. So what this recommendation is looking at is it’s looking at what is the total server memory, how much do we want to leave as a gap for the operating system and other things to be available there, and then taking the number of instances and dividing that remaining by those instances so they can all work evenly. Most people aren’t running 16 or 17 instances on the same SQL Server, like we are in this demo here. So it’s our test server. It just happens to be that way. Usually the recommendation is going to be here to use like 90 or 95% roughly, or 80 or 80 or 90% of the overall server max server memory setting.
Mitchell Glasscock 04:49
And it’ll explain that in its process to you as well.
Steve Stedman 04:53
Yep, there’s a lot of details there. So, what happens next?
Mitchell Glasscock 04:56
We can we click one of these and it will. Will apply the changes in the background, and it will just continue on as set the max server memory to 1734 megabytes for us.
Steve Stedman 05:15
Okay, so let’s continue scanning. What do we get? So there’s a lot of work going on here, and that’s why the scanning takes a little while, is go out and figure out what the next recommendation is. So the next thing it found was a really wide table. This is just one of those recommendations that maybe you shouldn’t have 120 columns in your in your tables, that you’re working on bad design practice, typically. But that’s just a recommendation. We from here. You could jump to the database by sizes report, but overall, it’s just, that’s just a recommendation. We don’t have any fix for it. We’re not going to say, like, drop 60 columns in order to make it smaller or anything like that. So let’s hit continue scanning and see what else we get. So it’s flipping through a bunch of checks there that it passed. Let’s scroll up and look at what actually passed.
Mitchell Glasscock 06:10
So we went through our wide tables, and we went through database mail failures. This was the first one that checked right after that, and it will tell you if you have any right, right? So it would stop there, and it would start providing recommendations on this side if it did find any so if you just run this returns, no failures found. It means that it’s everything’s all good as what it’s seeing.
Steve Stedman 06:34
Okay. And then eventually it stops when it finds a problem.
Mitchell Glasscock 06:40
So we find the user tables and system DBS. So we have a big list here of user tables that were found in some system databases.
Steve Stedman 06:52
Oh, the master database. That’s one of those that you shouldn’t be using the master database as a dumping ground for your own tables.
Mitchell Glasscock 07:00
Yeah, yeah. This is another one that we don’t provide any scripted recommendations for, just because we don’t want to be altering your environment. So this is one where you need to take the list, right?
Steve Stedman 07:11
Yeah, a drop all tables button might have been a bad idea. Okay, cool. So where, where else do we see the DB assistant? I mean, it’s here on the server overview panel. But where else do we see it in Database Health Monitor, right?
Mitchell Glasscock 07:26
So if we’re looking at a database overview, we’ll also have the DB assistant there with some special database level checks as well, so it will know if you’re running in a server overview, or if you’re running it in the database level as well.
Steve Stedman 07:41
Yeah, so when you do it here, it’s just going to find things about the current database, and if you click on a different database, it might find a completely different set of findings that it’s going to recommend.
Mitchell Glasscock 07:55
And then one other place there is the general overview, the DB assistant with a pop out, and it’s essentially the same that it’s running the server overview, just in a larger panel that you can pull off to the side and run other things concurrently while doing this. And then the last place that we have it, a lot of our instance reports also have the DB assistant link here, and this will start relevant DB assistant checks to run concurrently of the instance report that you’re running.
Steve Stedman 08:32
So because you’re on the job history report, it’s only going to show DB assistant findings related to jobs in some way, Agent jobs, all right, well, that’s got to be one of our bigger projects that we’ve taken on.
Mitchell Glasscock 08:47
Yes, it has been. We’re excited to see where it goes, and we are still expanding it. This will be one that we’re going to keep working on for a while, comprehensive checks.
Steve Stedman 08:58
Okay, great next then on the list, oh, great place for you. You happen to click on the job history report to show where the DB assistant was. Here this job history chart. That’s our next new item.
Mitchell Glasscock 09:10
So this is the new job history chart. We’ve overhauled the entire instance report, and so now you get to see a 24 hour view of the current jobs that are being ran on your SQL Server, as well as seeing yesterday. So here we can see we’re broken up into the 24 hour segments, and each of these job markers are a time that the job started and stopped. We can see do work two is a job that was running from 239 to 339. This is all segmented out in relevance to where it lands on the chart. Okay,
Steve Stedman 09:51
So the job history report. Why exactly did we build it this way? I don’t know. That’s kind of a loaded question, because I know the answer, but I think let me just go into the reason why we built it this way was because it’s really difficult in the way you kind of visualize things in the job history, in SQL Server Management Studio and stuff like that, to kind of see it on a timeline and see how things are actually working. And one of the common things that we’re trying to figure out when we’re scheduling jobs is, how do you schedule a job at a time that there’s low CPU? And one of the cool things that was added into this report across the top is a color coded heat map that shows the percentage of CPU being used, so you can look and see that. Well, maybe you’ve got too many jobs running at one specific hour. Now, this is our test server, so it’s kind of boring. It doesn’t have those kind of spikes on those kind of spikes on it. But if you had an hour that we’re, like, running at 90% CPU, well maybe that would be a bad time to be running additional jobs. Or maybe you could fix some of that by moving some of those jobs around. Anyway, we also have the filter jobs. Like, let’s say you’re looking at this and you’ve got like, 1000 jobs scheduled, and you want to filter it down just to look at a couple of them, you can use this like, this like deselect all and then go in and pick a couple of them and hit OK, and then the chart refreshes, just to show you a few specific jobs there. Anyway. This is one that, yeah, this is a big ad on the database health three zero implementation. And nice job putting that one together, Mitchell. All right, next, shall we move on to the problem indexes? So there’s a bunch of reports that we have around indexing, and most of them are kind of at the database level, but this was something that we added to go in and try and figure out, okay, at a instance level, across all of our databases. What are some of the indexing stuff that we want to know about? So what’s up with this one? Right?
Mitchell Glasscock 11:47
So this report is going to show you things that maybe aren’t obvious at first glance, if you’re looking at the other index reports, one of the things that we’ve encountered a few times now is disabled indexes. Management Studio does not have a good way of showing you that an index is currently disabled, and it just acts as if you’re looking at it in the viewer. It’s just acting like it’s there and it’s doing stuff. You may think that it’s doing something for your system, but it’s, in all reality, it may be disabled and not helping your system out at all. So looking at this, you can see the status of disabled ones.
Steve Stedman 12:26
So for instance, disabled indexes are kind of a really great way for a developer to do a quick check to say what would happen if this index wasn’t here. Instead of dropping the whole thing, you can just disable it and but as long as you put it back later. But what happens is a lot of people end up maybe disabling an index and then forgetting about it, and two, three years later, you notice in here that you’ve got some disabled indexes. Well, they’re just taking up space, but they’re not giving you any value, and they’re probably doing a disservice, because they make you think you have an index in there, because it’s not clear that it’s disabled, like Mitch said a few minutes ago, the other thing that we’ve added is the fill factor information.
Mitchell Glasscock 12:58
So this will show you again. Management Studio doesn’t immediately show you if a fill factor is set low, and so this will show you if a fill factor, fill factor zero shouldn’t be in there. If a fill factor is set below, we recommend 90 and above for our fill factors, but if it’s set below that, meaning it’s only going to half fill the index of information and data, then you can realize you can go back and fix these low fill factors.
Steve Stedman 13:32
Yep. So the fill factor is applied when an index is built or rebuilt, doesn’t apply when you’re doing a reorg on it, on it only when it’s being initially built or being rebuilt. And what that means is a fill factor of 50 means fill up every data page or 8k chunk, fill it half full or 50% full. And I don’t know that 50% full was ever a good idea, but it used to be that filling at 80 or 90% was a good idea, because any left room for more rows to be added. But in today’s world with not so many spinning disks anymore and more. SSDs, yeah, having tighter packed indexes seems to be a better thing. It saves you space. You get things done faster, and the page splits that you’re dealing with. I mean, you might end up with a table where you want to have 90% but oftentimes we recommend setting it to 99 50% is never good. 0% means 0% is the same as 100% I mean, fill it all the way up. So in this case, 50 is always a bad setting for fill factor. But if you’re at 85 or 90 or 82% Yeah, it’s not the end of the world, but you might save a few percentage percentages and speed things up a little bit by increasing that fill factor.
Mitchell Glasscock 14:44
And we also include the scripts to alter these to fill factor 99 and enable them or drop them, if that’s what you want to.
Steve Stedman 14:52
We don’t have a drop all tables button, we don’t have a drop all indexes button, because that’s something you should take and analyze. And figure out on your own before, before doing it.
Mitchell Glasscock 15:02
Alrighty, let’s go into these backup reports that have been reworked. So those familiar with Database Health Monitor may remember that backup size is kind of the database level backup report that we always go to. This one will show you, over time what the backups have changed in size. We’ve changed this though. We’ve altered this a bit to be have a bit more clarity with a bit more of explanation of what’s truly going on in this.
Steve Stedman 15:40
So with that, we have the blue line and the green line. Green line showing there because we have differentials and we have fulls. We don’t have any logs on this one, apparently, so we’re not seeing the little light blue line. That’s really handy to see how that differential is growing on a day to day basis, and maybe change how often your full backups are needed to be done.
Mitchell Glasscock 15:56
And now, in turn, with this, we’ve also added the backup timeframe report, which utilizes the same report that we showed on our job history, but this one’s set for a two week period, and this will show when your backups are being done. So here we’re looking at just differential backups. We haven’t seen a full backup for this DB health history database in the last two weeks.
Steve Stedman 16:22
Wow. So well, it’s our test server, and everyone’s always messing with the jobs, and there’s no reason to back that one up. But if you were seeing this on a production server, that would be a massive red flag. Two weeks without a full backup, most environments, that’s going to be an issue. Now to go into the log shipping report.
Steve Stedman 16:41
Oh, yeah, yeah. So log shipping is one of those things that’s been around forever, literally with SQL Server, and there are a lot of really good use cases where people are still using log shipping today. It may, I mean, some people may argue that replication or availability groups or other things are a better solution, but for a disaster recovery second site kind of thing, log shipping is a pretty good solution. So this report is set up for those customers that we’re working with that are using log shipping in order to be able to get more status as to what’s going on with the data that’s being log shipped. You don’t get real good log shipping reports in a SQL Server Management Studio. So this is there to show you what’s being shipped, how often it’s going and things like that. Unfortunately, on this test server, we’re looking at multi SQL, SQL 2022, we don’t have log shipping set up, so the report is really lame and boring, but it’s much more exciting in an environment that actually has log shipping going. So if you’re familiar with Database Health Monitor, you’ve probably seen the quick scan report over time and every release, I think we add a couple new checks here from something we’ve found or something we’ve learned along the way that has caused problems or bit us in some way that we don’t want to have it happen again. So the first check, and just like we said, we don’t have log shipping set up, we don’t have merge replication running on this server with any problems right now, but there’s check number 237 which you’re not able to see here right now. But just imagine that we had 237 which checks for merge replication conflicts. So if you had a merge replication environment running and you were you had conflicts that needed to be resolved that would show up in here as a quick scan item to let you know that that was something that needed your attention. I’ve seen a lot of environments that merge replication conflicts get overlooked.
Mitchell Glasscock 18:45
Important thing to take care of, alrighty, check 238, Ola scripts have been installed, but not running the OLA Hallengren scripts are something that we recommend and we use with many of our clients. But the same thing with Agent jobs, it’s pretty easy to set up a job but then not schedule it. So this is one we’ve used to ensure that our Ola scripts have been scheduled and are currently running on our servers.
Steve Stedman 19:12
Yep, that was one that bit me where we’d set it up, but somehow the job schedule got deleted and we thought a job was being run, and so that it never happens again to us. We’ve added this check into the quick scan report. Check 239, is on failing Database Health Monitor jobs that one, there’s a couple of jobs that we have for Database Health Monitor that I think there’s four or five of them now that report and check on different things and log it in the DB health history database, and occasionally we’ll find that maybe one of those fails for some reason. Usually it’s something that’s kind of intermittent, but it’s a way that we can better detect and find what might be failing in order to be able to help improve the process. Here, that alert caught us. And just yesterday, actually, Mitch, we were working on that we had one of our Database Health Monitor Jobs was failing in a SQL Server availability group environment where the job just needed it wasn’t doing the check right to say, Are you a secondary that and to skip some of the checks. So we had to go in and fix that, and this failing Database Health Monitor jobs caught that and was able to get it fixed prior to the release of Database Health Monitor version 3.0 check 240.
Mitchell Glasscock 20:27
This one’s disabled indexes. This goes hand in hand with our problem indexes report. So if you’re looking at just the quick scan, this will let you know if any index has been disabled, and it’s just another way for us to modify the clients that an index was disabled and never renamed.
Steve Stedman 20:44
The next one is missing primary keys. This is something that we added and found out there’s a whole lot of databases out there where people don’t use primary keys. Primary Keys is really a great way to identify each row in a table uniquely, and there’s a lot of benefit to having a primary key on your table. So primary keys check number 241, it’s one of those that you might look at it and say, Gee, it’s too hard to change that in my database. But if you’re or if you’re using off the shelf product, you’re probably not going to be changing that. But if you’re working at a place where you’re developing the database, you can catch tables without primary keys and get those primary keys added that can oftentimes make, help make a big improvement in performance with things like joins and whatnot.
Mitchell Glasscock 21:30
Alrighty. Check 242, SQL server error log inaccessible. So I would say this one was built around the premise of we’ve worked with clients in the past where we’ve had issues reaching the SQL server error log, either it’s too big and we are unable to open it, or there’s some other error going on in the background. So this is a quick way for that to be identifiable as a problem before we start trying to reach others.
Steve Stedman 21:57
I’m surprised at how many environments, for some reason, the SA user or an administrator user cannot get to the error log, so usually it takes some file permissions to get it figured out, or user permissions All right. So then check number 243, that was added data and log files on the same drive. It’s generally a bad practice to put your database files, your MDF or NDFs on the same drive as your log files or your LDF files. There’s different reasons for that. Half the reasons for not doing it are based around performance and IO related things. The other half are based around like reliability and being able to if you lose a drive, being able to restore as much as you can. If you have your data and your log files on the same drive, and you lose one of those drives, or if you lose that drive, then you lose everything. If you have your data and log files on different drives, there’s different possibilities for what you may be able to get back in the event of an emergency restore there. And I think that’s it on the quick scan report. Just continuing to add to that. Overall, we’ve got about 240 checks in there now, and it just continues to grow and grow. If you’re using this for the first time, and you click on the quick scan report, and you just think, wow, there’s a lot of stuff being found about my system here. You can always double click on one of those rows to jump to the help, link on it to find out more about it. But it’s one of those things that if you just chip away at it a little bit here and there, you can get it cleaned up and make your system more reliable over time. But keep in mind that there are different categories in the quick scan report, like performance and availability and things like that as that first column, and if you’re having performance issues, well maybe you need to focus on the performance items. If you’re concerned about security or general cleanup or things like that, maybe you focus on those things first. So and then the next thing that we had some changes on is the Performance Monitor, SQL Server Performance Monitor.
Steve Stedman 23:58
So to get there, what Mitch has done is he’s right clicked on the instance name in the tree view on the left and then gone to the SQL performance monitor. On the SQL performance monitor, he’s currently entering his username and password because it’s a separate application from Database Health Monitor itself. And he’ll come back in a moment with that connected. But what the SQL performance monitor was designed to do, and we got this from working with clients who had hired us to focus on specific performance issues. So when somebody says, We need help with a performance issue that’s going on right now, usually the first thing we’ll do is start up the performance monitor here, and it’s going to give us a bunch of information. First off, how many active connections do we have on the server? And right now it’s showing 74 up at the top there, and it’s pretty flat. One of the things that is a worrisome trend in that is if that number of connections is like continuing to grow and grow into the hundreds or 1000s, that means, usually that something’s bogged down. I mean, if you’re growing from 74 to 75 Yeah, not the end of the world. So the other thing that’s new and changed on this is the CPU and RAM chart down below there, so you can look and see, well, how much CPU is being used on this SQL Server. Currently, it looks like we’re running about 2% CPU utilization. So certainly not CPU bound here. And currently the RAM, if we’re looking over at the right side, we’re using about 1700 megabytes for this SQL Server instance, which is what we set on the max server memory setting earlier, because that was the recommendation based off the number of instances we had running on this server. So what else Mitch on?
Mitchell Glasscock 25:37
Here we have these two boxes. Here we have the missing indexes and the blocking queries, and these update every few seconds. And what this will do is queries are being ran on your server. It’s going to analyze, figure out what indexes are going to be best recommended based on the queries that are running while performance viewer is open, and as it stays open for longer, it’s going to shuffle these around and provide what it thinks is the most value. So past the CPU and the RAM chart up here, we have these two boxes down here, the missing indexes on the left and these blocking queries on the right. And while the Performance Monitor is open, these missing indexes, the these missing indexes are going to fill in what based on what queries are being ran while the Performance Monitor is active and running, and it’s going to order these based on what it thinks are going to be the most valuable indexes to add to your server. And then same thing with this blocking queries.
Steve Stedman 26:36
Well, just a couple notes on the missing indexes before you move to blocking queries. You notice as it updates, you’ve got the cost numbers there, and the cost number is relative to the value. When we say cost, that’s the cost of what would have been saved in execution plans had that index been there. And the other thing that’s different is most the other indexing reports that we have sort of show like since the SQL Server was restarted, what are the most valuable indexes. The difference with this is, this is right now. What’s running right now that would have been improved by having these indexes. And then the other thing with the missing indexes is we can click on one of those and it appears with the create script down below, if you want to go and add it or see more details on it.
Mitchell Glasscock 27:18
So and then same thing with missing indexes, this blocking queries is going to fill in as blocking queries come in, and we’ll show you what is the blocker and what is currently being blocked. We don’t have anything active on here, but it’s the same thing with the missing indexes. You’d be able to click on it and it will show you down below what that blocking query is.
Steve Stedman 27:39
And if you want more information or a demo on that one, go back to our podcast from a few episodes ago on blocking and deadlocks, and it’s got a really detailed demo of detecting blocking queries with that so that part hasn’t changed. The other thing too is if you go to the Reports menu, you can now pop up with the blocking query Reporter The Missing indexes. Well, blocking doesn’t show anything because there’s no blocking right now, but there’s the missing indexes where you can go get that. And oftentimes, when I’m working on making missing index recommendations, I’ll use this, I’ll go copy that out, and then work with the client to figure out which ones do we really want to add. Never just blindly take everything in the list as an index to add, go look at what’s already there, compare it to what’s suggested to be added, and then make sure it makes sense to add that as an index. Okay, as anything. I think that’s it on the performance viewer, then Right? And that brings us into the rewards page. So with Database Health Monitor, we wanted to come up with a way of saying thank you to everyone who’s using the product. And say, as you’re using the product, over time, you get more and more stuff. And this idea came to me after a hosting company that I was working with. They, every month that you were with them, they kind of increased your limits and increased your stuff that you were getting without increasing your cost. So this example here is showing someone who’s been in the using Database Health Monitor for three months, and they have three rewards available. The first reward that’s available, and these are all things that are absolutely free. The first reward is free access to our aggregating data. Course, this is one of the classes at Stedman SQL school that talks about aggregating data and the some of the over clause and stuff like that. It’s one of our short classes, but it’s, it’s a really detailed class, and to get it to use it, you would just hit the claim button. This has already been claimed, but you hit the claim button and you would get an email that says, here’s your free coupon code in order to get absolute free access to the Aggregating Data Course. Then next is the 20 minute configuration of Database Health Monitor tutorial with the Stedman team. So you’d click Claim on that, and you’d get an email with details on how to get you scheduled for a call with me or one of our team members help on how to get Database Health Monitor configured and running the best in your environment. And that’s something that we’ve seen that if we spend 20 minutes with you to help you get everything up and running in a quick tutorial on it, you’re going to be so much more successful with Database Health Monitor, because you’re going to learn a lot of those tips and tricks in order to be more effective on it. And then in month three, the daily or weekly monitoring email. That’s another add on to Database Health Monitor, where you’re going to get more value by being able to turn that on, where you get a weekly report, and you hit claim, you get an email telling you what to do, on how to go configure that and would work with you to get that set up.
So for everyone, you say, well, I’ve been a Database Health Monitor user for two or three years. Well, you’re not going to immediately get three years worth of rewards. Here. The reward timing all starts out at the time of the three the 3.0 release, or at the time that you first signed up. So if you signed up after the Database Health Monitor 3.0 release, so if 18 months from now, you’re you’ve been using Database Health Monitor that whole time, you should have all the rewards up to month 18 at that point. And if you forgot to claim one, no big deal. Just go back to month six at that point and claim that one. If that’s the one you missed. Basically, with Database Health Monitor, we just want to say thank you to everyone who’s using it and give you a little bit more value here over time, and there may be some surprises along the way in here, on things that you get for free as being a Database Health Monitor customer. So thank you. All right, Mitch, anything else we want to talk about on this 3.0 release?
Mitchell Glasscock 31:36
That wraps up everything that I was looking forward to talking about.
Steve Stedman 31:41
Oh, you know, there is one more thing. I mean, with any software product out there, there’s always bugs and crashing and stuff like that. So we have our internal crash reporting. If something doesn’t work as expected, we get a ticket that gets sent into our system, and we’ve been actively working for last few weeks to just squash all of those and figure them out in order to make Database Health Monitor be a more reliable than ever environment, so it’s as stable and works as well as it possibly can for you. So that’s one of those things that when you first use Database Health Monitor, and it asks you, do you want to send crash reports to the developer? It’s not going to send us any of your data. It’s going to just send us detail about what part of the program crashed, and if it does, and we’ll work to get those taken care of. So I think there is a huge amount of value here in this three zero release from the DB assistant, which is almost sort of an AI like analysis of your database, to the job history chart, to the problem indexes, to the backup size report and log shipping, instance reports, a number of additions into the Quick Scan checks and revamping of the performance monitor and the whole rewards program. So I guess at this point that wraps it up. I’d like to say thank you for listening. Thank you for tuning in. If you liked this episode, please click the like button or subscribe for future episodes, and please check out Database Health Monitor. Oh, part of it is with Database Health Monitor 3.0 you have a free 30 day trial that anyone can download it and check it out. So please do that and try it out. And Mitch, thanks for joining us on the podcast today. Always appreciate your information being here. Thanks for having me. Yep, and I’d like to say to everyone else, join us in our next episode where we talk about Lean DBA and things you can do to be more efficient as a DBA. All right, that wraps it up. Thanks for watching and have a great day.
Steve Stedman 33:54
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.