- Host: Steve Stedman / Shannon Lindsay
- Topic: Top 10 Most Common Wait Types
- Recording Date: April 30, 2025
- Listen on Spotify!
Stedman SQL Podcast Season 2 Episode 16 Wait Types
In this episode, we dive into the top 10 most common SQL Server wait types. You’ll learn what each wait type means, how it impacts performance, and what you can do to resolve the issues. From CXPACKET to PAGEIOLATCH, we make complex wait stats easier to understand and troubleshoot.
Need expert help managing SQL Server? Visit https://stedmansolutions.com/managed-services/
Download Database Health Monitor at http://DatabaseHealth.com
Podcast Transcript
Steve Stedman 00:15
Hi and welcome to the Stedman SQL Podcast. Your go-to source for SQL Server insights. I’m Steve Stedman, founder of Stedman solutions, and your podcast host today.
Shannon Lindsay 00:28
and I’m Shannon Lindsay here to keep things fun and ask the questions that you’re thinking today, we’re going to dive into the top 10 SQL Server wait types, what they mean, why they matter and how to tackle them.
Steve Stedman 00:43
But before we jump into that, this is season two, Episode 16, and yeah. And I guess the one thing I want to point out, if you’re liking what you’re seeing here and you want to see more, remember to click that like button. Or if you’re watching on YouTube, click the bell, so you get notified when there’s new content. So if your SQL Server is running slow, wait types are like clues to solve the mystery. Stick with us to learn how to use these to boost your performance. So wait types tell us where SQL Server is spending time waiting, pointing out performance bottlenecks.
Shannon Lindsay 01:17
So like a traffic jam. Wait types show, show where the holdup is.
Steve Stedman 01:22
Yes, but think of it like a traffic jam, where everybody that’s stuck in traffic is logging what they’re waiting on, like the person, let’s say there’s a traffic jam caused by a fender bender up front. The two cars up front would be logging a wait type of maybe a car crash, and then the people behind would be logging a wait type of perhaps stuck in traffic. And you know, to fix the issue, in that case, you have to deal with the car crash, wait type, fender bender, wait type before you can clear up those who are waiting on stuck in traffic. And as soon as you clean that one up, then everyone who’s stuck in traffic will just start to flow through. So with this, I mean, one of the things is there’s different dynamic management views and things like that in SQL Server to track wait types, but we’ve built Database Health Monitor, and one of the very first features I put into Database Health Monitor, when I started building it 14 years ago, was tracking wait types. And what we do is we keep track of those waits. So when somebody says, hey, yesterday, at 230 the SQL Server was slow. Can you tell me why it was slow? We can go back and look at the historic reporting and see, oh, yeah, here’s the query that was slow, and this is what it was waiting on. So at this point, grab a coffee and let’s get started. You can visit Stedmansolutions.com for free resources, including Database Health Monitor. So What are SQL Server wait types? That’s one of those things that a lot of times we start talking about waits or wait types, and people don’t always know what that means. So wait types are events where SQL Server is stuck, paused or waiting on something, and it could be waiting for resources like CPU, Memory, Disk locks, blocking things like that. And what SQL Server does when those things are encountered is that, just like the car accident example, and the traffic we used, it logs and tracks those things so you can go and see what your query is specifically waiting on. They’re like a diagnostic tool. High wait times means there’s something slowing the system down. And you can monitor this with DMVs or dynamic management views like this sys.dm_os_wait_stats. You can use extended events and my favorite Database Health Monitor to track all of this.
Shannon Lindsay 03:41
So Steve, for someone who’s new to this, is this like when my computer freezes and I’m waiting for it to kind of catch back up?
Steve Stedman 03:49
Exactly. But the difference here is in SQL Server. SQL server logs why it is stuck and why it’s waiting, and we track those with Database Health Monitor so we can pinpoint exactly why it’s freezing and fix it. So in the example of your computer being frozen, you don’t always know what it’s waiting on. Is it waiting on the network or waiting on memory or waiting on who knows what, but SQL server logs all of these things. So a real world example of this working with a client whose server was crawling due to high page, io, latch, underscore, sh, wait, types, and that’s an indication that there were disk issues. And we were able to go in and figure out the problem is slow disk, and we were able to rearrange some files and figure out with the disk issue, and we’re able to get the problem fixed once we understood what the symptoms were. But from the user’s perspective, all they saw was that the SQL Server was slow. But from looking at the wait types, we could track it down to figure out specifically why it was slow. So let’s just dive into the 10. Maybe not the 10, but 10 of the common SQL Server wait types. And we’re going to go through what each one of these are and how they impact things.
So the first one CXPACKET, and I want to prefix this with not just CXPACKET, but there’s also some other CX wait types that are in newer versions of SQL Server, like back in SQL Server, 2008 all you had was CXPACKET, but now we have CX consumer and some other ones related to this. And these are specifically tied to parallel query execution, meaning a thread is waiting on others to finish in a parallel plan. So it’s common in systems where you have high parallelism, and it can indicate a lot of different things, from uneven data distribution to being indexes being out of whack to max degree of parallelism setting not being set correctly. And basically, with this, it’s one of those that there’s a lot of clues there. And some people look at CXPACKET and they think, Oh, I can get rid of CXPACKET. And what they do is they just go set their max degree of parallelism to one, and then there’s no parallelism, which means you’re not using all the cores on your system. So CXPACKET and the other CX waits are generally a good thing unless they’re happening in excess.
Shannon Lindsay 06:17
So, it’s like a team where one person’s kind of not holding their wait and they’re holding everybody else up.
Steve Stedman 06:26
Right now, think of it this way, if you have a query that is being run on a single core or single processor, all that work being done, there’s no parallelism happening there. But if you have a query that’s being split and run across eight or 10 or 12 different cores at the same time, what’s going to happen is some of those cores are going to run faster to get through the work that they’ve been assigned to do, and others are going to finish up later. So let’s say five of those 10 cores are done doing what they need to do. Well, they’re stuck, waiting there now, waiting on CXPACKET while the other five finish what they’re doing with CXPACKET. The one big recommendation I have is to track it and see how this trends over time with CXPACKET. If it’s the overall overwhelming wait on your SQL Server, then maybe you’ve got something misconfigured, but if your CXPACKET waits are coming in at like 30 or 40% of the overall load on your SQL Server, well I’m not too worried about it at that point. It’s just understanding how many cores you have, what your max degree of parallelism settings are, and how your queries are being run. Now there’s some other settings you can adjust around, things like the cost threshold for parallelism, and that will adjust how many, how big a query has to be before it will be run parallel. And that can impact CXPACKET as well.
So CXPACKET is one of those. It takes a little bit to understand it. It could be fragmented, indexes, out of date, statistics, or just a bad query plan. Next, let’s take a look at the PAGEIOLATCH_SH and anytime you see a wait type that has an underscore sh on it, it generally implies it’s a shared wait, where, if there’s an underscore ex, it means it’s an exclusive wait. So shared waits generally happen when reads are happening or when queries are being run. Exclusive usually happens when there is something that’s being changed so the PAGEIOLATCH_SH. This happens when SQL Server is waiting to read data pages from disk into memory. And this points out that there is slow IO or insufficient memory. Now, an old saying we used to have is you can fix a whole lot of IO issues with just adding a whole lot of memory, because what happens in that case is that if your memory is big enough to hold all of your database, well, it doesn’t have to go to disk all the time to read things, but if you don’t have enough memory, then it’s going to disk more often in order to be able to bring in the data that’s needed for your queries. So one of the things you can do with this is you can optimize your disk performance. If you have any kind of tiered storage, you can figure out, well, what are the areas, what are the files that are having the slow performance, and can you move those to faster storage? Sometimes it’s moving them to a different disk. We saw this related to Temp DB recently, where they had the one drive they had Temp DB on, or it was a virtual drive, but the one virtual drive that Temp DB on was on didn’t have enough IO allowed to it in order to provide everything that needed the Temp DB needed. So we were able to take Temp DB and move half of it off to a different disk, thus doubling the amount of IO capacity we had there. And that optimized the disk performance enough that it made a huge impact on the overall system.
Shannon Lindsay: 10:22
So it’s like waiting for a slow elevator?
Steve Stedman: 10:30
Yes, exactly. And the way you can fix that is. Just by being in the right place, meaning you don’t need the elevator. You’re already on the floor, you’re going to and that’s the equivalent of adding memory, or by adding more elevators, which is sort of the equivalent of adding more disks, or figuring out how to make those elevators run faster, which is the equivalent to optimizing that disk performance. Or another way is to take half the people who need to use that elevator and put them somewhere else so they don’t need to use the elevator. And that’s like moving data files around. So yeah, I like that elevator example, all right. So now I know when I mentioned that last one on the PAGEIOLATCH_SH for shared. Now we’re going to talk about an exclusive lock.
And here we’re going to look at LCK_M_X, where the x implies that’s exclusive, and the M implies that there’s data being modified, and the lock it’s trying to get a lock in order to modify data.
Now this occurs when a process waits for a lock to modify data, blocking others. Now imagine Shannon if you’re trying to update a row in a table, and I’m trying to update that row in the table at exactly the same time, and then, to make it worse, we’ve got 75 other people out there trying to update that same row in the table, or even the same table close to it, depending on how locking occurs there, and what’s going to happen is the first person in is going To get their exclusive lock, and let’s say that’s you updating the table, and then I’m going to try and update it, and I’m going to be stuck waiting trying to get my exclusive lock to change that table until you’re done doing your update. Now, how long is that lock held? Well, it’s held for the duration of a transaction. So if you’re in a transaction that’s looping and maybe running for five minutes. That’s a bad move to begin with, but if you were, you’re going to hold that lock until the transaction is rolled back or committed at the end. So really, the LCK_M_X, is real common, and it usually indicates blocking. IT issues often from long running transactions. Now the way one of the solutions around this is to figure out, how do you optimize your transactions, and how do you make those transactions smaller? How do you make them faster? Sometimes it’s as simple as adding an index in order to speed up the finding of the data that’s being changed. Sometimes it’s way more complex than that. One of the things with SQL server you can look at is READ COMMITTED Snapshot isolation level. Now we’ve worked with a lot of clients recently who’ve had a lot of blocking on LCK_M_ X or IX, and in those cases, we moved a couple of them to READ COMMITTED snapshot isolation level. And what that does is it keeps a version store in Temp DB, and it makes it so that people changing the database will be blocking each other, but people reading the database will not be blocked by any of those any of those blocks that way.
Shannon Lindsay 12:56
This one’s kind of funny, because we had just talked about Steve that, you know, both of us needed to renew our licenses. And this wait type sounds a lot like the line at the DMV where everybody is just kind of waiting for one person.
Steve Stedman 13:09
Absolutely. And I think that. I don’t know what it’s like in other states, but in Washington State, the Department of Motor Vehicles licensing is not, not very well known for getting things done quickly. And yeah, the wait type there would just simply be slow, slow people. But that that’s a tough one, because if, with the locking on, doing updates, well, depending on your environment, you may need to be doing a lot of updates. And there’s a lot of different ways that you can deal with this one. But it’s usually pretty good performance tuning expedition into dealing with this, this wait type.
So next we have the right log wait type. And this is the transaction log that it refers to it. So if you see WRITELOG wait type, it refers to waits while writing to the transaction log, often due to slow disk or log contention. And what this does is it slows down transactions, especially in high write environments. So when you have a transaction in SQL Server, it doesn’t actually close or finish its commit until the log has been written to because if it’s not written to the log, and somebody turns off the SQL Server, well your data would be lost. And once you’ve done a commit, you know it’s not going to be lost. So if you’re doing a huge update that’s writing to the transaction log, and that transaction log is slow or just overloaded because a lot of people are also doing updates and writing to it, it’s slow. It basically just slows down everything. If you had a SQL Server that didn’t do any inserts, updates or deletes, and all it did was select, you would probably not see any write log wait types, but that’s not the real world.
So the way you can deal with the WRITELOG wait type is to figure out, well, what’s causing all of this? Is this because of bad disk performance? Is this because you’ve got some transaction that’s doing a giant change of data that may not all need to be changed so frequently? Or is this due to something like the log file growth settings. I mean, we see oftentimes people have percent growth turned on, and you have some small query that needs, like another megabyte in the transaction log, but it ends up growing the transaction log by 500 gigs, or something like that. That slows things down. So just understanding what’s happening with it and knowing that the wait type is there will give you more clues on how to go figure out why it’s happening.
Shannon Lindsay 15:45
So like a slow cashier that’s not very quick at processing the payments or scanning the groceries?
Steve Stedman 15:53
Oh yeah, exactly. So let’s say you’ve gone into the grocery store, you ran through real quick, you got everything you needed, and you got stuck waiting in line to get out of the grocery store for 15 minutes because the cashier was being cashier was being so slow, and you can’t leave until you pay, obviously. So, yeah, that’s kind of like we’d call that the slow cashier wait type, which would be kind of equivalent to the WRITELOG, absolutely. Okay.
Next is one that’s a bit of a misnomer, and it’s the ASYNC_NETWORK_IO wait type. And you would think from a name like ASYNC_NETWORK_IO that it would imply that the problem is you’ve got slow network IO. And that’s the first thing everybody assumes. But it’s not the case. It’s like in the book Series of Unfortunate Events where they referred to the incredibly deadly Viper that happened to not be incredibly deadly at all. So the ASYNC_NETWORK_IO wait type is very rarely ever associated with a network issue. It can be on a rare occasion, but usually it’s not. So usually the way this happens is that SQL Server is waiting for the client to consume data. Now let’s say you’ve got a program that’s running client side, and your program runs a query, and then it loops over the result set, and it’s really slow in processing that result set and displaying on the screen. What’s happening at that point, it’s and let’s say it’s slow, not because of the database speed, but because of something in the application. What’s happening at that point is, all SQL server sees is that there’s this network connection open where it’s sending data to the client. And it, from SQL Server’s perspective, it can’t tell that it’s the client that’s slow, or if it’s the network that’s slow. So if the client’s really slow, all SQL server sees is that the network is slow at taking that data that it’s sending out. So the way to look at the and you know, honestly, on this one in my career, I’ve maybe seen once or twice that ASYNC_NETWORK_IO was actually caused by a network issue, and that was back in the old days when networks were a lot slower. But the way you deal with this one is by optimizing client apps to process the data faster, or in the rare occasion, than its actual network issue is to increase the network bandwidth.
So an example of this would be Microsoft Access, not a big fan of Access, just on some of the crazy things it does with SQL server load and waits and blocking. But Microsoft Access, if you open up a SQL Server table in Microsoft Access, it will hold that connection open until you page down to see the next page of data, and then it will pull the data in from SQL server at that point. So simply by running Microsoft Access, connecting to a SQL Server and having a table open, you will get crazy amounts of async, async network IO. I would hope that Microsoft would fix that one day and access, but just like access, it could happen in any client application that’s turning through, usually looping over a whole lot of data.
Shannon Lindsay 19:01
This reminds me of like you send a really long email and you’re just sitting there waiting for somebody to read it.
Steve Stedman 19:07
And if you’re anything like me, the longer the email usually the more I delay on actually getting around to responding to it. So yeah, ASYNC_NETWORK_IO kind of yeah, a bad name for it. But from SQL Server’s perspective, all it sees is that it’s slow. Whoever’s retrieving the data is slow, and usually it’s a slow client application doing it, not the network.
Next one is the PREEMPTIVE_OLEDBOPS, and this specifically relates to external operations like Link server queries or SSIs tasks or things that link outside of the actual main SQL server process, and it’s waiting for something to respond, and it indicates that there’s a delay in those external components. So for instance. So if you have a link server, which is simply a pointer to another SQL Server, you send a query across that link server connection to run, and if it takes five minutes to run on the other side before you get results back, you might be getting PREEMPTIVE_OLEDBOPS waiting for that query to be run on the other SQL Server. And the fact is, this SQL server you’re on is reporting that that’s the wait type, but it indicates the problem is on the other end, or it could be, I mean, the other end, meaning that the query you sent to the other end is causing it as well. So one way to work on this is, well, I guess, no, let me give another example. Another example would be a link server to something that is not a fast connection. One environment I worked on, they had a link server between United States and New Zealand, and running any queries across that link server were slow, just because the connection was so slow and just the amount of time it took to transfer the data there, so then that would have logged a bunch of PREEMPTIVE_OLEDBOPS. So one way to deal with this is to optimize your link server queries or optimize link server connections and reduce the reliance on those external operations.
Shannon Lindsay 21:18
So, it’s this one’s kind of like waiting for a delivery from another company?
Steve Stedman 21:23
Exactly, and like the delivery no matter once that other company has started their process of delivering it, generally, you’re not going to be able to change that, no matter how much we may be screaming at our company that we need it today. It’s going to get here when it gets here. And yeah, the preemptive Ola DB ops are kind of like saying, go figure out what’s going on that other end, on whatever thing it’s waiting on at that point, not on the current SQL Server. Okay, next we’re on to IO_COMPLETION. And this is a wait type where SQL Server. It’s kind of an obvious one. Unlike the ASYNC_NETWORK_IO, this one is what it says it is. It’s waiting on IO operations like log file reads or non data page reads different things like that. And generally, when we see IO_COMPLETION, it’s suggesting that there is something slow going on in the disk subsystem, for instance, a slow drive, or maybe a failing hard drive, maybe something failing in a rate array, or maybe someone just went too cheap on the disks that they provisioned in the cloud, things like that. And you can reduce this by upgrading disk hardware or optimizing IO heavy operations, like an example of this, oh, gosh, we had one client five or six years ago. They were doing an update statement where it was something simple, like update, Set Active equal one, where something and that was updating like 50,000 rows every 10 minutes, or something ridiculous like that. And we changed the query to say, update that table set active equal to true, or to one where it’s not already one. And we were able to reduce the amount of IO on that one by I mean, we took it to less than 1% of what it was before, therefore less IO less IO_COMPLETION issues. So yeah, that was optimizing the IO heavy operations, and it made a huge impact on that system.
Shannon Lindsay 23:38
Yeah, that feels like a really big file waiting to download.
Steve Stedman 23:44
Yeah, yeah. Think of it like a big, I don’t know, like a big spreadsheet, and if that’s downloading every two minutes, it’s going to be really slow. But if you could, say, just download those things that have changed, it might be a whole lot faster. And that’s kind of the equivalent of optimizing the IO heavy operations. Okay.
Next we have LCK_M_S, which is a shared lock. And a shared lock means that a query is being run and it’s stuck waiting to get that shared lock because somebody else is changing something. So Shannon, let’s take the example, if you just updated a table and you change 10,000 rows, but I’m trying to select from that table, and your update on those 10,000 rows hasn’t quite finished yet. Well, in a standard READ COMMITTED environment, I’m not going to be able to see those rows until your query finishes. And there’s a lot of different ways to deal with this. One, I mean, generally, it indicates there’s a lot of locking in a busy database. But one would be, if you’re updating those 10,000 rows to change how you’re doing it, instead of updating 10,000 maybe you update 1000 1000 of them. At a time in a loop that goes through 10 times. In that case, there’s less blocking, and then my query that’s trying to select can get through faster. So you can also fix, I mean, tuning the queries to figure out, how do you make that update run faster, getting the right indexes and considering different isolation levels, for instance, READ COMMITTED Snapshot isolation level is one of those that we’ve used with clients recently, and we’ve had some massive success with it. And what happens with RCSi is a lot of your read locks simply go away because they’re not blocked by anybody changing data, because you’re able to use the version store and to be able to bring back the data, rather than waiting for that 10,000 rows that Shannon’s updating to finish.
So next we’ll look at SOS_SCHEDULER_YIELD. And this is one of those where a lot of people see SOS and they think this is like an Emergency SOS call, you know. But what SOS stands for is the SQL operating system at this point. Not SOS like save me. And the SOS_SCHEDULER is the SQL operating scheduler, and that’s what figures out what queries are actually going to be assigned to a CPU or a core right now for work to be done on them. So if you have, let’s say you have 50 cores on your SQL Server, and you’ve got, I don’t know, two or three queries running, they’re probably not going to have a lot of SOS_SCHEDULER_YIELDs because you’ve got way more CPU than you need to run those few queries. But take the example of maybe you’ve got four CPUs or four cores on your SQL Server, and you’ve got 100 or more queries all being run at the same time. Well, what’s going to happen is the SQL operating system scheduler is going to give each of those queries that’s being run a little bit of CPU time and then take it away and give it to some other query, and then take it away from them and give it to a different query, and basically pass that CPU around so that you can that all the queries can be serviced a little bit, rather than letting one query just blast its way through and use all the CPU. What the yield means is that the scheduler has had to take an unfinished task that’s being run out of the schedule and put it back in the queue and say, Well, come back in a moment. The moment might be a few milliseconds, but come back in a moment and finish your query, because I have to take you off of this this CPU in order to let another query run. So when we see SOS_SCHEDULER_YIELD, it usually suggests that the server is overloaded and with a lot of CPU intensive queries. And this comes down to a number of different ways to fix it. One way is to optimize queries. Figure out, how can you make that query be less CPU intensive? How can it do less work? You can add more CPUs, or you can reduce the workload.
Shannon Lindsay 28:06
Sounds like everybody at a gym trying to fight for the one treadmill that’s still working?
Steve Stedman 28:10
Yeah, absolutely. And imagine if you’re at the gym and there is that one treadmill, and there’s 10 people that are trying to share it, and you jump on the treadmill and you get to use it for 30 milliseconds, and then I jump on and I get to use it for 30 milliseconds, and then it just kind of goes through that queue that way. Yeah, that’s exactly what the SOS_SCHEDULER_YIELD is indicating is that it’s bumping the person off of that treadmill or C or CPU core, in this case, in order to let someone else use it for a moment. Okay, got to be approaching 10 here sometime onto our page, latch underscore up. And this is a wait type that implies that it’s waiting for memory based latches, oftentimes in Temp DB or in the buffer pool. Now what that means is that probably something related to Temp DB load. Here. It’s common in servers that have a really high Temp DB workload and with high contention in Temp DB. So the way you reduce this one, well, you can figure out what queries are, are getting that wait type and then figure out, how can you reduce the amount of Temp DB usage they’re doing? Gosh, I looked at a server the other day where they had Temp DB was configured to be 48 gigs in size, and they had one query that was trying to get 52 gigs of Temp DB space. We were able to increase Temp DB, give it more data files, but also overall, make it a much larger Temp DB environment. And then we did, and then we can do some work to optimize the queries as well, and we were able to reduce the wait type because of that.
Shannon Lindsay 29:53
It’s almost like you’ve got, you know, your chef and your sous chefs, and everybody’s in this really busy kitchen, but they. All want the same pan.
Steve Stedman 30:00
absolutely and no matter what your dish, what dish you’re cooking, if you need that same frying pan, you’re gonna get stuck having to wait on that.
Shannon Lindsay 30:07
Which of these wait types do you think you see the most often?
Steve Stedman 30:11
Well, it depends a lot on the environment. And a lot of the time, though, we see CXPACKET, quite a bit. We see PAGE_IO_LATCH, they’re pretty common. We see a lot of the locks where your lock looking for an exclusive lock when somebody’s doing too many updates. And the thing is, we just use Database Health Monitor to spot the trends and figure out how to fix them fast. And with that, one of the things I really like to focus on here is to monitor this regularly. If you’ve got a SQL server where nobody’s ever looked at waits and it’s like 10 years of code running there, yeah, you’ve probably got some work to do. But if you’re monitoring this all the time, you can see things like, if you made a code change on Tuesday, and then 10 minutes after that code change, you start seeing wait spike. Well, you know, it could be related to that code change. We use Database Health Monitor to track this. We use DMVs to track it as well. And my approach is usually to go find the top two or three queries, look at what wait types they’re getting, and then from there, figure out how to reduce those and just kind of chip away at it. You don’t need to look at 1000 queries. Just go look at the worst performing ones, and usually fixing two or three of them can have a pretty big impact on your system. So with this, you don’t just treat the symptoms you want. To dig into the query plans, hardware and configuration issues. And what I mean by that is, let’s say you’re looking for the SOS_SCHEDULER_YIELD wait type which indicates maybe you need more CPU. Well, if you just start throwing more CPU into your server, that can get really expensive, especially on the SQL server licensing. So finding the root cause of why that’s happening and figuring out how to fix it can make a big difference in the overall cost. And the thing is, test your fixes. Don’t go make 30 changes and then expect to see what the impact was make one change at a time, measure the impact, confirm that what you did actually improved things, and then, if it didn’t, undo it and try something different.
Shannon Lindsay 32:10
So you’re kind of testing it like Sherlock Holmes you’re looking for, find the clue and then try and solve it, right?
Steve Stedman 32:18
Yep, and but it’s more like a blind Sherlock Holmes, unless you have the right tools with the right tools, then you can be Sherlock Holmes and go track down and Database Health Monitor can be your magnifying glass in that example. So if you’re overwhelmed with your SQL server performance and your waits, our team at Stedman solution offers a managed service to monitor and optimize your SQL Server. We also offer performance and health assessments, where we can come in and help you for a short amount of time, figure out what’s going on and figure out how you can fix those things, and we’ll make recommendations and help you fix those things on your SQL Server. If you’re interested in either of those, you can book a free 30 minute consultation with me, and just go to Stedmansolutions.com and click the Contact link, and you can set up a free 30 minute consultation where we can talk about what you need and how we can help you so wait types are basically your roadmap to better SQL server performance. You can start monitoring today and tackle the big ones like CXPACKET or LCK_M_X or IX, with Database Health Monitor.
Shannon Lindsay 33:28
Don’t let those traffic jams slow you down. We have tons of tips and tricks to keep everything running how it should.
Steve Stedman 33:36
Absolutely, and don’t let that LCK_, fender bender wait type, don’t let that jam you up, like the example we talked about in the beginning. So download our free Database Health Monitor at Stedmansolutions.com and start tracking wait types today, and check out our blog and podcast for a lot more details on different wait types.
Shannon Lindsay 33:58
Don’t forget to subscribe to our podcast. Also, there are a few short links you can follow, like stedman.us/podcastYouTube, and you can also listen on Spotify. And the link to that is stedman.us/podcastspotify.
Steve Stedman 34:14
Next week, we’ll be diving into ways that a DBA and your database can survive a ransomware attack. Nothing makes me more angry than some of these ransomware people out there. So next week, we’ll talk about ways to help with that. So thanks for joining us. I’m Steve Stedman,
Shannon Lindsay 34:33
And i’m Shannon Lindsay. Thanks for joining us. See you next time.
Steve Stedman 34: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.