- Hosts: Steve Stedman / George Stedman
- Topic: If I had 30 minutes to audit your SQL Server : The first steps and common questions and pitfalls
- Listen on Spotify
- Download Database Health Monitor
If I Had 30 Minutes To Audit Your SQL Server Stedman SQL Podcast Sn 3 Ep 18
If you had just 30 minutes to evaluate the health of a SQL Server, where would you start?
In this episode, Steve Stedman and George Stedman walk through their real-world SQL Server health check process, sharing the most important things to investigate first: database corruption, backups, DBCC CHECKDB, blocking, deadlocks, wait statistics, high CPU usage, missing indexes, and configuration problems.
Learn how to quickly identify performance bottlenecks, uncover hidden risks, and troubleshoot SQL Server issues before they turn into major outages. We’ll also demonstrate practical diagnostic queries and show how Database Health Monitor can simplify the entire process.
Podcast Transcript:
Steve (00:16)
Welcome to the Stedman Sequel Podcast. This is season three, episode number eighteen, and I’m your host, Steve Stedman. Today I’m joined by one of the Stedman Solutions team, George Stedman. Hey George, welcome to another podcast.
George (00:32)
Hey, thanks for thanks for having me.
Steve (00:35)
Yeah, thanks for coming. This is the eighteenth episode of season three, or our fifty eighth episode since starting the podcast. Thanks to all the viewers for joining.
So, if we had 30 minutes to audit your SQL Server, what would you check if you only had 30 minutes to determine the health of an unfamiliar SQL Server? After performing hundreds of SQL Server health checks across organizations of all sizes, we’ve learned that a small number of metrics consistently reveal the biggest risks. In this section, we’ll walk through the exact checklist that we use when we’re evaluating a new server from backups to
And integrity checks to weight statistics, index health, query store, blocking, TempDB, and configuration settings. Rather than focusing on the obscure edge cases, we’ll concentrate on the issues that most often impact performance, reliability, and maintainability. You’ll see how to quickly separate symptoms from root causes, prioritize findings, and identify the changes that deliver the greatest return of your time. Whether you’re responsible for one SQL server or hundreds, you’ll leave with practical audit processes that you can immediately apply in your own environments. Now on to the main session.
So where do we go first, George?
George (01:53)
Well, a lot of our clients bring us in for performance checks, but we generally find that we wanna make sure that the system’s clean and healthy before starting. And if we do change anything, we want to make sure there’s a good fallback point.
George (02:07)
So let me share my screen. So the big ones is we want to make sure there’s no corruption, we want to make sure there’s valid backups, and we want to make sure that the backups are recent. So we have this quick query that we can run. And this one shows the last backups, the last known good checkDB, which sometimes we actually see where it’s never or null, just usually a big red flag. But I would say on most of our clients, we’ll run a quick check DB right away and it comes back clean and we kind of just like sigh and wipe the sweat off our brow a little bit and then we continue on.
Steve (02:56)
So one of the reasons that we do this, I think, is we really want to look at like what are the things that can completely kill the system. And when we think about killing the system, it also relates to like ending your job or a game over scenario, which we often talk about as like a resume generating event, meaning the only way you’re gonna get paid next week is if you get a new resume. Get your resume updated and go get a new job. So there’s a lot of systems we’ve worked on where the first time we’ve touched them they’ve been quite unstable. And really what we’re trying to do here is to figure out how we can know or how we can do what we can to make sure that that system is as stable as possible so that whatever happens, we’re good to keep working on it. And we don’t leave it any worse off than we found it.
George (03:42)
Really good point. So once we get the baseline tackled, we kind of go to what why did we get called here? Typically that can be boiled down into three main reasons that kind of overlap with each other, but they kind of have different starting points depending on how the issue is described and those are going to be they say that their SQL server is slow. They usually complain that there’s a lot of blocking and stuff is once again slow because or locked up or they gotta restart the SQL Server or kill processes all the time to get stuff fixed. and then the third one is they are tired of just upgrading the hardware to get their SQL Server running properly again. a lot of teams without DBA will just increase the resources because I see SQL Server is using up all the disk’s full, the CPU’s maxed out, the memory’s full. We can just throw more at it and it should put away the issue for a bit.
Steve (04:42)
And one of the problems we run into with that is that is licensing, of course, because I mean SQL server licensing is not cheap. And if you have a business practice that says when something’s slow, let’s just go get a bigger server with more CPU, more cores, things like that, well, suddenly it’s not just the cost of that computer or that virtual machine, it’s the cost of the SQL Server licensing that really starts adding up too. So figuring out how to deal with these main chief complaints of it being slow, something’s blocking, or running out of resources, we can help a whole lot with getting a system running much smoother over time.
George (05:22)
Yeah, and we have our own in-house tool for quickly diagnosing this stuff, but we put together a few queries to help anyone who watches this podcast who goes to our day of data presentation to or sees it online to get this information without going through any hoops of downloading a monitoring.
So the first one we have is our SQL Server is slow query. This is a mix of it’s nine different queries, and it looks for weights, weights right now, uh, what’s active right now, what databases are using CPU, I/O memory, then it goes current CPU by query, uh queries running longer than 30 seconds right now, and it’s a lot of right now checks because there’s no monitoring in place. For a lot of stuff that happens in SQL Server. so we kind of have to run this when the issue’s happening. And that can cause the query to take a long time, or you know, it there’s a lot of things that can happen. So we’ll run this real quick, I say real quick, but I think this is one of the ones that takes on our test system earlier, it took about a minute and thirty seconds.
Steve (06:37)
So this is going out and running all nine of those.
George (06:40)
Yes.
Steve (06:41)
In order to be able to help us pinpoint exactly what’s going on this SQL server. sort of sort of like when you go to the doctor and they start doing tests or checking vitals and things like that until something stands out as that’s a problem. And okay, so we got results. Is there anything here that jumps out as whoa, that’s a problem?
George (07:02)
let’s see. I mean there’s a lot of weights, fifty-five percent of all weights there. We got locks. Something is blocking SQL. Well, that’s probably one of our blocking tests.
Steve (07:17)
Yeah, we should also point out while we’re here that this is our test server and it has some really truly horrible blocking deadlocks and those kind of queries running on it. So which may be more like a realistic server than you think?
George (07:45)
But the cool one is down here, I believe this is the CPU by query. This is a really cool query that we’ve been we’ve used and has been extremely helpful for diagnosing performance issues on a lot of clients. and it tells you the overall CPU and logical reads and time that the query uses. And if it’s running right now or the query plan is..
Steve (08:07)
Wait, is that three million logical reads? Am I looking at that cross eyed or is that really three million?
George (08:15)
Yeah, that is three million logical reads.
Steve (08:19)
Wow.
George (08:20)
In our audit demo sales database I spun up and has been running jobs for the last three weeks. So uh the cool thing is it keeps does have the query plan, so you can click on it and go and take a look and see what’s going on. and we can see that a lot of it is a clustered index scan, which means it is. But we’ve seen this is a pretty simple one ’cause it is our test database. but we’ve seen some really crazy execution plans. Let’s see if we can find one of the other ones.
Steve (08:52)
What I like about this query you’ve got here is that it doesn’t just show you here’s the problem query, but it gives you the plan that’s actually being run. So we can go and understand why that’s why that’s a problem.
George (09:02)
Mm-hmm. And this one says it’s missing an index, which is just normal SQL Server query plan viewer, which you can do on any query by doing what is it, control.
Steve (09:13)
Yep, or turn on an actual execution plan on the menu button or sor the toolbar button.
George (09:20)
And then we can scroll down and there’s just some more kind of hints or clues to figure out where your performance issues are coming from, but we do see that the average this table is definitely one of the problem queries and it seems to be missing a few indexes. Yeah, it’s the last check is the missing index check.
Steve (09:46)
So is it fair to say what we’re looking at here is a test database that probably could add a half dozen indexes and it might make all the difference in the world and how..
George (09:58)
Yeah, for sure. I don’t think I put any indexes on this to begin with. Yeah.
Steve (10:03)
I think too, I mean a lot of people look at this and you may say, Well, that’s not realistic. Well, the fact is, this is very realistic. On a lot of systems that we work on, we find out that, yeah, maybe somebody set up the tables ten years ago and they’ve never added indexes that have been needed over.
George (10:22)
Or the other thing we see a lot of is it seems like the DBA is the last person they add to the team. Or they haven’t added the DBA to the team yet. So it’s just normal app developers or website developers building out the database as needed.
Steve (10:41)
Yeah, that’s not to bash on the app developers in any way because it’s usually not their job to figure that out. That’s the that’s the DBA that a lot of places don’t necessarily have. So
George (10:51)
Yeah. Yeah, these queries we’ll provide alongside the podcast and we’ll have a link on our Database Health site this one’s really long because it gets goes and gets a lot of information. So then our next chief complaint is the blocking complaint. It’s the something is blocking everything complaint. I’m gonna kick off some blocking real quick on my second screen here. Start blocking. All right, and then we’re gonna run this.
Steve (11:24)
Blocking is one of those things that with our customers that have some of the busiest databases, there can be a lot of blocking going on. And figuring out where it is a big part of our job. And not just where it is, but once we find it, how do you address it?
George (11:42)
So this goes through, it’s got five queries in it. Uh it’s got the block, it’s got a blocking tree query, which goes and finds all the blocking and then gives you the like what’s blocking what. It is kind of wide, but and then it’s got the SQL text for each query as well. We have the open transactions. Which is usually where you’re gonna find your blocking is an open transaction that’s holding something open and everything’s waiting on that transaction to close. That’s really common, especially in development environments or environments where you have a lot of users with SQL access, is they’ll leave a transaction open and then it slowly impacts the production app or the demo or testing app or whatever.
Steve (12:27)
Yep. And one of the things with that is, I mean, it might be somebody says, no, I didn’t leave a transaction open. I never used a open or begin transaction command, right? But uh I ran into a couple days ago where I was running a procedure and it ran for a really long time and I had to abort that procedure halfway through and it turned in turned out that it left a transaction open in management studio and by simply just committing or rolling that one back, uh it was able to get around the issue. So those kind of things happen.
George (12:58)
Yeah. I mean this query’s still running ’cause I think the last check takes a bit. Because this one is looking for live data and you can’t just grab a snippet of live data, you gotta record over time.
Steve (13:14)
Yeah. So then with what we’re looking at down below here, George, I mean, what would you look at as like a starting place with the results we have so far? I mean, is there something that you can see here that you can point the finger at and say, Ooh, that’s the that’s the culprit that we need to go fix?
George (13:34)
It would probably be this direct directly blocking column.
Steve (13:37)
Okay, so if we’re looking at that first one there that’s currently blocking four, with it’s the head blocker that’s session one fourteen, what do we know about that? What can we, how can we go chase that?
George (13:50)
Yeah, so we can go over here. we can see what is running it, and it looks like it’s a program called audit demo window A went to launch. and it’s a uh it’s a demo it’s a PowerShell SQL command let that opens a transaction and then just stays open. Um it does a begin transaction, it goes to update the inventory and then it never does anything else.
Steve (14:23)
Yep. So the went to lunch, a little bit of background story on that one. About what, I don’t know, fifteen years ago I was working in a company. We had five or six of us in one section of the office. We could all talk to each other and see each other. And my boss was sitting right behind me at the time and he starts running around saying that the site’s down, everything’s broken, we got to fix it, you know? And so being the database guy, I jump in and I start looking at well, what’s going on? And I looked and said, “well, gee, uh, there’s one session that’s open that is an open transaction just like this. And gee, the login name on that one was Todd.” Started looking around the room and Todd’s over there eating his lunch. He’s sitting at his desk, but he’s still eating his lunch. And it turned out that he had opened a debugger and was halfway into debugging through a transaction when he decided it was time to eat lunch. And I was able to terminate a session, but I yelled at him across the room as well. and we were able to get the whole server unjammed just by clearing up this one lock session that was left open in a transaction while that developer uh was eating his lunch.
George (15:39)
So yeah, realistic. These things happen. Human error is probably one of the easiest blockers to solve. The harder blockers are the ones that are business tasks blocking business tasks, which we can normally solve with rescheduling the jobs a little bit so that they’re not running at the same time.
Steve (16:02)
Or we can solve them by speeding up the jobs. Sometimes that’s changing a query or adding an index. Or if you’re on a modern version of SQL Server, we can turn on turn on what?
George (16:15)
Read committed isolation level or snapshot.
Steve (16:18)
Yeah, Read committed snapshot isolation or RCSI. Yep. So here’s the shameless plug. If you don’t know what RCSI is, we’re not going to spend a whole bunch of time explaining it to you. But go back and find in our podcast. the podcast where Derek and I talk about RCSI and the whole podcast episode is about RCSI and reducing blocking with that. All right, shameless plug is over.
George (16:42)
All right, so um this one also does uh it’s got a blocking by hour little thing it pulls up. Uh I think that just grabs, yeah, so you can see like well all the blocking kinda started oh right now, I think. No, this this one’s not super oh wait down sorry, scrolled down, I was confused. All the blocking starts from seven AM to oh, six PM. So during business hours.
Steve (17:22)
yeah, I was gonna ask, what are the theoretical business hours of this uh fake business you have running on our dev server? Yeah.
George (17:30)
Yeah, it appears that it’s seven to six.
Steve (17:34)
Look at that. Okay. Good findings.
George (17:37)
Scrolling down to the final deadlock check reveals numerous deadlocks, many of which occurred today. We can also view the deadlock graph.
Steve (17:55)
You can blame me for those deadlocks because that’s my test script that’s running on there that simulates deadlocks that we use when we’re testing Database Health Monitor.
George (18:04)
Yeah. And that’s the great thing about having a nice big dev environment. We do have queries to simulate a dev environment. I have I can pull it down real quick. We have I have this little PowerShell applet that lets you test the queries I have included. It also just has kind of a bunch of different test things. Do not run it on production environments. Please put it on a d test or dev box. If you if you wanna run any of this, ’cause you can make a mess of your SQL server really quickly. And then I guess that brings us to our last chief complaint, which is the we are running out of resources. We don’t want to upgrade again.
Steve (18:50)
Wait, every time I upgrade the server gets twice as expensive, George. I’ve upgraded four times, it’s really expensive now.
George (18:59)
We can always throw more money at it, right?
Steve (19:02)
That’s a good short term solution.
George (19:05)
It is a short-term solution. this one runs really quick. it’ll go through, it grabs, let’s see, where’s the um it grabs storage, it grabs processor, memory, and it grabs contention. So we can see here our storage looks pretty good for a dev box. There’s not huge disks, but none of them are really full yet. We see here we have a lot of percent growth. Wait, that’s oh this one has percent growth on it, which is not a good recommendation to have.
Steve (19:46)
So the reason percent growth is not a good recommendation is when you start with a really small database, 10% of 10 megabytes is one megabyte. And that’s not bad. That’s not great. But if you get up to like half a terabyte database and you’re growing at 10%, well that’s a really long growth event for that file to expand. It’s maybe better to expand in smaller chunks when it gets really big. So we generally recommend people don’t use percent growth on their data files. Little side note there.
George (20:16)
Yeah. And then we can also see this one, it’s got a it says the log is bigger than the data, which is n another kind of red flag that someone’s not maintaining something.
and then yeah, tiny, lots of VLFs, log bigger than the data. So this has a lot of checks to kinda give you the red flags that maybe something configuration wise should be fixed to help normalize your storage.
Steve (20:42)
Yeah, and these are just hints, something to go take a look at. They’re not always going to be a problem, like log being bigger than the data. Sometimes that’s appropriate on your database, but if you’ve got a good size database and the log is bigger than the data, well, maybe that’s not a good thing.
George (20:59)
If we can scroll down, we have let’s see, what’s this one doing?
Steve (21:04)
Virtual log files?
George (21:07)
Yeah. Yeah, lots of VLFs on our archive demo. But five hundred and sixteen VLFs, but only one is active. Probably shrink or remove some of those. It’s my guess, then also gives you recovery model. So just another spot to check your backup retention or backup policies.
Steve (21:34)
Yeah. I love it when someone’s got full recovery model and they’ve never run a backup and they’ve got a log file that’s like a hundred times the size of their data file because it has every transaction lo saved in there for the last twelve years, you know.
George (21:52)
And then down here we have, let’s see, this is just another this is per file. and then the start and growth. Oh, I think this is latency? Yeah, IO latency by drive.
Then we can here see here we have ten schedulers, 10 logic. So this is down to CPU now. Oh, this is CPU. Okay. SQL CPU percent. We can see how much for CPU is being used. Well, it’s not really over time if it’s all right now. But this is over the last ten twenty seven.
Steve (22:27)
Yeah, this one is overtime.
George (22:29)
It is. Sorry, I just I keep seeing I forget the little scroll bars on the side. this will go through and give you historical CPU usage. So you can kind of scroll through and see where it’s maybe your hotspots are.
Steve (22:45)
Okay.
George (22:45)
then we scroll down and we can see signal weight, weight percent,
Steve (22:51)
So the signal WAIT versus the resource wait, that’s a kind of a cool one because that’s telling you that like ninety-four percent of the wait time is waiting on a specific resource like CPU or IO or something like that. And that’s where we can kind of dig into the figure out, okay, well what is it actually waiting on?
George (23:13)
Yeah. And then this one, I love these little ones that have the findings.
Still the nineteen nineties default of five cost threshold for parallelism. Small queries go parallel. It’s a fun one.
Steve (23:29)
Yeah.
George (23:31)
Yeah, this is just one of those, it’s looking at your SQL server settings to see what maybe should be changed to maybe improve performance. Stuff that gets left on default settings, or it’s been left on a default setting for an older version of SQL in case you maybe upgraded in place. Some of those settings sometimes get carried over. But yeah, this there’s a lot of little queries here. They don’t always point to the issue, but it’s a lot of little hints and clues to figure out where to look next. But yeah, that’s the last of our chief complaints. Um, like I said, we will include these queries. We’ll have a link in the description, I think, to all of them on our website.
Steve (24:20)
Okay, so at this point we are not counting commercials and startup time. We are twenty-six minutes into the recording on this podcast. And it was titled What We Can Do in Thirty Minutes. you beat that by about four and a half minutes, George. So not bad there. We got through a lot of stuff. So what’s next?
George (24:41)
So the queries are great, but as you might have noticed from this video, or if you’re listening, it’s kind of harder to see what’s going on. But there’s a lot of different data, and you kind of got to interpret it yourself. a lot of stuff to look at. So we have ah two products that really help us streamline this. We have database health monitor, and then inside of database health monitor is our SQL performance monitor. These really help us do this checklist in even less than 30 minutes in reality. we can get usually a lot of the configuration settings reported on within 10 minutes, and then performance can take well, you can find performance findings almost instantly, but actually fixing them usually requires a lot of communication with the client we’re working with and getting everything working within the business’s logic. Two big checks we have in Database Health Monitor. If we want to quickly go over those to kind of mirror what is going on with those four queries I put out there. We have our quick scan report. This is kind of our initial. We run this instantly on every server. This pulls all of that information we had in that query, but also a whole lot more, everywhere from high to low urgency. And we can see, we have well, I guess high to low, and critical. can see, oh, those databases that have never been backed up, and one called corruption challenge one have never had DBC checkDB run on them. Um and it usually get.
Steve (26:36)
So the reason that that corruption challenge one it has had Check T V run on it, but it’s never been run successfully because it is full of corruption.
George (26:46)
Yes. And same with audit demo corrupt. Um
Steve (26:50)
Yep. Okay.
George (26:53)
And Database Health Monitor just it’ll also give you a whole what this means. It’ll tell you exactly what it gives you advice instead of having to know have the knowledge to do it. So if you’re maybe not a DBA or you don’t have SQL expertise like we do, um it and you’re just maybe a sysadmin and you don’t have that DBA yet, you can quickly kind of get a recommendation on a better place to start than if maybe just Googling it.
Steve (27:25)
Yeah. All right.
George (27:28)
And that leads us. So that’s the quick check to like find configuration checks and whatnot. we have the SQL performance monitor. We’ll point that at the server real quick.
Steve (27:39)
Yeah, so the SQL Performance Monitor, which George is loading right now, apparently on the other screen, tool that I built specifically for there is something wrong right now, and we need to figure out what that thing is that’s wrong right now so we can fix the performance or fix the issue. We’ve used this dozens, if not hundreds, of times, where a client calls us up and says, Help, everything is having a problem right now. First thing we do is we fire up the performance viewer, and we can learn pretty quick. What’s going on?
George (28:12)
This is big because the queries I included only do like a I think they do like a 30 second snapshot of what’s happening right now. this will continually monitor over time. and will give you wait stats, it’ll give you your long-running queries, it’ll give you block blocking queries in real time, and it’ll give you your missing indexes in in long real time as well.
Steve (28:38)
Yep. There’s been times with the performance viewer where a client has said the whole system is totally bogged down now and jammed up. And it takes about two minutes in clicking around in here to figure out, okay, here’s the problem. And here’s what we’re gonna do to fix it. And that high CPU tab there, that’s one George added not long ago. that is one of my favorites. there’s no high CPU on this data server, unfortunately. So it’s not very interesting on this one, but we can find like which ones are chewing up your CPU if you have a hundred percent CPU utilization, things like that. Blocking queries, long running queries. there’s an ICP one there.
George (29:20)
Yeah, on our audit demo sales, it’s using a lot of CPU.
Steve (29:25) Did you just click something on the other screen to get that one to run? You did, didn’t you?
George (29:29)
I may have hit the CPU pressure button in our demo.
Steve (29:34)
Perfect. Okay. It by the way, this demo app is a PowerShell script. Is that gonna be distributed with the sample code as well?
George (29:42)
Yep, it will be. And all it needs to run is just a SQL Server. It needs your SQL Server and just a basic or it needs a sysadmin login for your just to create the databases and then it can run load and do a couple other fun testing tools.
Steve (30:01)
Okay, so on any of those high CPU ones there, can you right click on them and get the plan? and by the way, notice the green spike up top, the CPU just jumped up to a hundred nearly a hundred percent.
George (30:12)
Yes. It looks like some of these we can’t get the execution plan.
Steve (30:17)
It depends on what point of the query it’s through. So if we can go view the execution plan in one of them, and this is our version of our of a plan viewer, that we can find real quickly what’s going on in here and where the problem is. Look at that. Line two. 80.2% of the entire cost of the plan is that one line.
George (30:37)
Yeah. And this is another one of those things that we made just because we were sick and tired of the horizontal weird horizontal vertical panning of the built-in SQL execution plan. It was like playing hide and seek.
Steve (30:57)
If you’re used to working with the normal SQL server execution plans and the user interface for that, there is a whole lot of stuff in there that is left out that is in the XML for the plan, but never gets shown anywhere in the display. And we try and show a little bit more of that in here to give you a better idea of what’s going on with your problem query.
George (31:16)
That’s just the quick lowdown on our tools we use to diagnose those same issues that we see in pretty much the every time a client calls us, it’s one of those three issues. And I would say about 50% of the time with new clients, we find those red flags that we talked about at the very beginning. which is the it looks like the they’re doing full backups maybe weekly. They’re not doing a whole I let me go kill some of this stuff that’s stopping.
Steve (31:52)
uh Your long your high CPU and long running queries.
George (31:58)
Yeah, there we go. Yeah, we see a lot of clients that maybe they back up weekly or monthly or have never backed up. They don’t run Check DB because they just they’ve it’s not something they’re aware of. as non DBAs. But yeah, the we built these in-house tools. They’re not in-house, I guess they’re purchasable. They we have a trial that you guys can go and use, but we built those tools to kind of quickly automate a lot of this so that we don’t have to manually run these queries on every site.
Steve (32:34)
Well, yeah, if you look at where we’re at right now, just on our recording clock from when we started, I said we were about twenty six and a half minutes to get through running all the scripts originally. And now we’re at thirty five minutes, so another nine minutes on top of that to show how to do it in database health monitor. you can do it either way. one of them you got the scripts, it’s there for you. The other one you can download database health monitor and give it a try. But just two different ways to get through the same tasks in figuring out what is wrong with your SQL Server when it’s having problems.
George (33:04)
But yeah, that brings us the end of this. So we will have all these demos. We’ll have the demo, all the demo queries, the audit or the audit queries you can run anywhere. I think for the most part, they I mean run up read through them first. If you don’t want to trust a query from a person on the internet. but they should be able to be run on any your SQL servers. Some of them take a bit of time. So, you know, take caution running them on a live system unless like the blocking one might be nice if you’re running into blocking. You can run that. but definitely don’t run my audit demo launcher with all the SQL pressure. Don’t run that on a live system.
Steve (33:54)
yeah, so that one’s basically like a denial of service attack on the server. It’s basically just slamming it with a whole lot of work to simulate a bunch of really bad queries for us to use in performance tuning training.
George (34:07)
Yes, it is. But we will include that and all the queries and the queries that that application runs as well. That will all be included. We’ll have a link that we that has all of it together in a zip. You can go find Database Health Monitor at DatabaseHealth.com. And then yeah, do you have anything else for us, Steve?
Steve (34:30)
So, Database Health Monitor, if you want to try that out, it’s a free 30-day trial, absolutely no cost whatsoever to try that out. You need a little bit more trial, feel free to reach out to us. We can extend it to 60 days if you really need it. If you need any help, I mean, we’re here. This is what we do. This is our job all day, every day, performance tuning and taking care of SQL servers. So, reach out, we’re there to help, you can contact us. You can go to the Steadmansolutions.com website and reach out there.
Or you can email [email protected] or [email protected] directly contact us too.
George (35:05)
we also have [email protected] that will go to whoever is listening.
Steve (35:11)
Yeah, if I’m on if I’m on vacation, somebody else will get the contact one. So yeah, great, great demo, George. So if I had 30 minutes to audit your SQL server, this is what we would check. And two different ways of doing it. yeah, go back, follow through the steps, give it a try in your own environment.
Anything else, George?
George (35:33)
I have nothing other than keep this is one of those things to keep your database healthy. I would definitely try a couple the at least the danger query, make sure that you have backups and that there’s n that you have DBCC running. But yeah, happy monitoring.
Steve (35:51)
So one of the things here to keep in mind is that if you’re getting into this and you’re just thinking that what we’ve just covered might be over your head or not something you have time for, we can do a full server assessment or a mini assessment like we’ve outlined in this in this episode. You can just reach out to us. The mini assessment is pretty cost effective. The full server assessment will get your server running in tip top shape. reach out to us at steadmansolutions.com. We’re there to help.
And George, thank you for being on the podcast. Always good to see you. And thanks
George (36:21)
Yeah. Thank you.
Steve (36:23)
everyone for listening. Please subscribe, like, and keep those databases healthy. Have a great day.