- Host: Steve Stedman / Derrick Bovenkamp
- Recording Date: April 4, 2025
- Topic: READ COMMITED SNAPSHOT Isolation Level
- Listen on Spotify
Stedman SQL Podcast Season 2 Episode 14 READ COMMITED SNAPSHOT Isolation Level with Derrick
Join host Steve Stedman and guest Derrick Bovenkamp in Season 2, Episode 14 of the Stedman SQL Server Podcast for an in-depth discussion on READ COMMITED SNAPSHOT Isolation (RCSI). Discover how this SQL Server feature enhances performance and reduces blocking in database environments. The episode covers how RCSI works, its differences from other isolation levels, steps to enable it, and best practices for implementation, along with potential pitfalls to avoid. Perfect for DBAs and developers aiming to optimize SQL Server workloads, this episode offers expert insights and practical examples.
Podcast Transcript
Steve Stedman 00:15
Welcome to the Stedman SQL podcast. Your go to spot for all things SQL Server. This is season two, episode number 14, and I’m your host, Steve Stedman, and today, Derrick Bovenkamp joins me as my co host. Welcome Derrick. I’d like to also welcome new and regular listeners. This is our 27th podcast now, since we officially turned into our streaming into a podcast late, late last year, and we’ve had been having a lot of success with it so far, and having a lot of fun with it too.
So, do you have a SQL server that is overwhelmed with locking or blocking or you’re continually running into issues with locking or blocking queries? Well, READ COMMITED SNAPSHOT might be one of those things that could help you. Today, we’re going to dive into RCSI, or READ COMMITTED SNAPSHOT isolation level. It’s a powerful feature in SQL Server that helps improve your concurrency and reduces blocking, and it’s perfect for busy database systems, but it’s not perfect for all systems, so we’re going to take a look at some of the things related to that to kind of determine where it’s right for if you have a lot of pain points where you have a whole lot of blocking going on in your SQL Server, deadlocks reader and writer contention, where you have like, one query doing an update that is blocking 10 or 20 other queries that are waiting to query that same table, well, recommitted SNAPSHOT, isolation level might be something to consider. So, Derrick, let’s jump into this. Let’s talk a little bit about what is READ COMMITTED SNAPSHOT isolation level, or RCSI.
Derrick Bovenkamp 01:50
Yeah, let’s get into it. So, I believe you know, we were talking about this earlier today. Steve and Reed considered READ COMMITTED SNAPSHOT isolation has actually been around in SQL Server for a lot longer than people realize, but it was a very early version, and we really consider it mostly a SQL 2019 and SQL 2022 feature, ideally on 2022.
Steve Stedman 02:16
One of those things relating to that is what it does and how it works, and it uses a lot of Temp DB. And because of that, one of the reasons we say 2019 or 2022 is because on those versions, there’s a lot of improvements around Temp DB. So, let’s talk a little bit first about how it works and how it varies from what kind of the standard is or the standard READ COMMITTED. So normally, I shouldn’t say normally, but by default, out of the box, you install SQL Server if you haven’t done anything to change your isolation level, you’re running in READ COMMITTED isolation level. And what that means is you don’t get any dirty reads, and you’re able to get really consistent data, but you end up with some blocking happening. And for instance, if a table is currently being updated and it’s a long update, well your SELECT statements may be stuck waiting for that, and I don’t know, we’ve seen that a lot as we’ve been doing performance tuning. Derrick, right?
Derrick Bovenkamp 03:16
Yeah, not, not just a large update. We see that with tables that have tons of activity. So, if somebody has hundreds of reads happening and updates happening at the same time, even if it’s a short update, it’s blocking all those reads. And another thing that we see, too, you know, Steve, is we see a lot of people go in and throw NOLOCK on their queries. You know, you want to talk a little bit about that and how that’s different than READ COMMITTED SNAPSHOT isolation, yep.
Steve Stedman 03:44
So, NOLOCK is one of those, I don’t know, oftentimes misused, but there are some great, great reasons that you would want to use NOLOCK once in a while, but most of the time I see it, it’s being misused. What’s happening is you’re ignoring other people’s lock, and you’re reading dirty data, and sometimes, because of that, you may have rows that show up as duplicate rows in your results, set or missing rows. Now that might be okay if it’s something like, I don’t know Facebook status, but if it’s something like your bank account balance, I don’t know if I’d want it to be changing every time I run a query, so that a lot of people have tried to get around locking by using the NOLOCK, but what READ COMMITTED SNAPSHOT isolation level does is it eliminates those locks that are needed for reads by using row versioning in Temp DB. What this means is it puts a lot more load on Temp DB, but it keeps track of those rows that are being changed, and it keeps a copy of it in Temp DB, so that if you’re at the point that a query is running that’s changing data, rather than blocking or rather than doing a dirty read like you might have done in the past, you’re going to query that version of the table before the update was started. It’s going to hit Temp DB to pull that data back in, and from the query perspective, it’s going to look like now. Thing changed, your query is going to run fast and there’s going to be no blocking happening there. So that’s one of those things that can really make a big difference when you’re running into a lot of blocking on a busy database.
So, Shannon, can we go ahead and play the video now? So, I’ve got a short video that I put together here that sort of shows an example of locking and blocking. So, this is a simple database I put together that just has 1000 rows in a table, and I’m going in inside of a transaction to do an update, then a SELECT. And inside of that, what’s happening is I’m leaving the transaction open, or leaving it hanging, sort of like simulating a long running transaction, and that’s currently running in that window, in the window next to it. We’ll take a look. Well, here you can see there’s the rollback that I specifically missed. We’re going to go into a different query window, run a query, and a third query window and run a query, and both of those queries, and this is, again, this is on SQL Server, 2008 I’m doing a test of this on but it works on newer, on everything newer as well. And then we’re going to go look at blocking queries. And oh, I clicked on the wrong this was recorded earlier. I clicked on the wrong server instance.
So, once we jump over to SQL Server, 2008 Express because I was trying on an express server, we’ll be able to see that there’s queries that are being blocked. So we click on the blocking queries here on the right instance, and now we can see that there’s one query that’s a blocker, followed by two SELECT statements that are simply trying to get data out of that table. And we go and look, and we can see that there’s the queries that are that are running, and they are running in READ COMMITTED isolation level, not READ COMMITTED SNAPSHOT, and they’re being blocked. So, then what I’ve got here is the script to actually make the change. So I’m going to alter the database, put it in single user mode, kick everyone out of it, and then from there, we’re going to turn on SNAPSHOT isolation, and then we’re going to put the database back into multi user to let people back people back in and use it again. Okay, now we go back and we run that same query that was doing the blocking before, and it is still leaving a transaction open. And then we’re going to go and run SELECT statements, and you can see the SELECT statements complete, and they run just fine with no blocking at this point. So this shows the difference is that the original query is still running, the update is still left open as part of that transaction, but you can see that the SELECT statements are not being blocked. Now let’s do another test here real quick, and we’re going to grab the transaction that has an update in it and go put that in a different window. And we can see here that when we run the update, we can see that updates do block other updates. That doesn’t I mean, that’s similar to how it always has been, but updates don’t block other updates. But while those updates,
Derrick Bovenkamp 07:56
Updates block updates, but updates do not block reads.
Steve Stedman 08:00
Did I say that backwards? Thank you. Okay, so updates block other updates. That’s correct. Updates block other updates, but updates do not block reads. So reads are never blocked as part of RCSI, but updates will block other updates because you can’t have two things, changing the database, changing the table, at the same time in order to keep data integrity. Okay, so let’s go into how it actually works, and what do we want to cover in that area? What do you think, Derrick?
Derrick Bovenkamp 08:30
So, I think you know, we you touched on it a little bit about how it maintains row versions and Temp DB. So RCSI does really rely on Temp DB, and you want to make sure you have your Temp DB on fast storage. You also want to make sure you have enough room for Temp DB to grow, if it has to on that fast storage when you turn on RCSI.
Steve Stedman 08:53
Yep. That’s an important thing, because if you’ve got RCSI running, and Temp DB doesn’t have enough room to grow to handle it well, it could end up with your transactions failing because of that.
Derrick Bovenkamp 09:04
I think we also want to say, you Sorry, go ahead.
Steve Stedman 09:07
I was just gonna say so, I mean, the thing is, the way that it works, if I’m running a select statement, it’s got a copy of that version kept around in Temp DB so that, and I could almost say magically. But the way SQL Server does it is that, magically, the query runs without hitting any blocking at that point. Go ahead with what you had there, Derrick.
Derrick Bovenkamp 09:24
Yeah, well, we’re on the same page. Steve, so you’re saying magically, I was going to say transparently, is, you know, the that end user query, or end application query that’s reading, it doesn’t know the difference, you know, it thinks it’s pulling out of the table, but it’s really taking a little bit out of the table. Out of the table and a little bit out of Temp DB of the old version of those rows and putting it in your output.
Steve Stedman 09:52
So this has been there for a long time, and it’s something that I haven’t really considered to be right for prime time, for. It for a very long time, until SQL 2019 and even more so in SQL 2022 but with SQL 2022 some of the things we’ve seen are some big performance improvements with the versioning, and much bigger performance improvements on Temp DB. And when we’ve run this on SQL 2019 we’ve actually seen an increase in the amount of IO on Temp DB. But having done a migration where we moved from like 2016 to 2022 and then turned on RCSI, we actually saw less Temp DB load based off of the improvements in SQL 2022 so let’s go into some of the when and why should or when, why should we use RCSI?
Derrick Bovenkamp 10:43
So, let’s talk about that ideal scenario, which, which I think, I think I talked about earlier, is you have a very busy tables with lots of reads and writes happening all the same time. You know, if it’s just lots of reads, you’re not going to get blocking, right? But if you have lots of reads and writes happening, that’s where we have certainly noticed with multiple customers, that they start to get contention, and they start to get a lot of blocking on those reads. And it’s usually the reads the end users notices, right? Because they’ll click the button in their application and they’re waiting for data to come back, and it’s sitting waiting on somebody else’s right query.
Steve Stedman 11:22
Yeah, a perfect example of that a system I worked on a few years ago that just had a really busy login screen, and they had one table that stored the user, the password and the last login date. And had they not stored that last login date, that that table would have almost been a read only table just to go verify if your password was correct when you logging in. But what happened is, they put that last login date, and it turned it into a frequently updated table, so that every time people were logging in, they were updating that table to set that last login date. Well, what happened was, this was a gigantic table, and it had a whole lot of contention going on, and you ended up with all of those updates blocking all of the reads, and then you also ended up with some of the reads taking a while, and the update was being blocked by the reads as well, because you can’t do an update until you can get an exclusive lock on the table. So that would have been a perfect example of something that could have worked with RCSI, but that was a few years ago, and we built some other ways around it. But the key here is we want to look for heavy reader and writer contention, meaning we’ve got a lot of writes going on and a lot of reads going on specific databases, and we’re really just looking at how we can, I mean, with three committed SNAPSHOT, we’re able to reduce that reader contention, and the reads are never blocked at all.
Derrick Bovenkamp 12:49
Yeah, and I think we also look for lots of blocking, right? If we look around and there’s no blocking, or relatively no blocking, and it’s not causing a problem, you don’t have to enable it, because you don’t have a problem, right?
Steve Stedman 13:02
And that’s why I really like the blocking over time report in database health monitor, because we can use that to go and look at how much blocking is actually going on and how often is it blocking. And, yeah, I mean, maybe if you get one or two queries that block every month, well that’s a whole different story than having 10s of 1000s of queries blocking every single day or more.
Derrick Bovenkamp 13:23
So yeah, and can we, can we talk a little bit about when it’s not a good fit? Yeah?
Steve Stedman 13:27
Yep. So if you’re on a system that’s already overloaded, and maybe you’re running with Temp DB on some slow storage, or maybe your IO bound, if you’re already struggling, struggling with your temp, TBI, oh, well, this is probably not a, not a fit for you. I think that also, if you have, like, real time changes that are somehow using, like, NOLOCK in order to be able to go see things while they’re happening. I mean, that’s, that’s a pretty rare example, but that could be another example.
Derrick Bovenkamp 13:57
Yeah, and I, and I think the other thing I just you touched on it earlier, but I just want to make sure everybody’s really clear on this is because that versioning, the readers are going to get the data that existed when the right query started. So if you know, so just make sure when, when you when you talk about turning this on. It’s a great tool, and we’re going to get into some real world use cases where it completely changed the performance of a client SQL server when we turned it on for the good so there’s a lot of good things here, but we just want to make sure that people realize what is happening in that that we’ll call it a limitation. It’s not really a limitation, but that limitation is compatible with the type of data and reads that are happening out of your database.
Steve Stedman 14:44
Yep. So, I was going to talk about how to enable it next, but rather than talking about how to enable it right now, let’s talk about some examples of how we used it. How’s that sound? Yeah, that’d be great. So we work with a lot of clients at Stedman solution, and we try and help with all their different performance and. The scalability needs. There was a client we were working with a couple years ago, gosh, almost two years ago now, and they had a system that had a lot of reporting queries that were blocking, and they were doing these massive queries to update their kind of roll up tables. And it was at a point that this was all happening. I mean, they didn’t have a window that they could run it offline, so they had all the applications that were trying to query these tables while they were all being updated, and you ended up with blocking every day, all day. I mean, we had 1000s of blocks per hour, I think, with this client, and there was no way around it without completely rewriting their reporting environment. So we went through an upgrade. I don’t know you want to talk about that upgrade a little bit Derrick with, I think we went from like 2014 to 2019.
Derrick Bovenkamp 15:50
So, and I can’t remember, you know, we’ve done this so many times. I can’t remember if that one we built a new server or we did an in place upgrade. But, you know, we got them on 2019 and turned on RCSI, and, you know, saw an immediate difference with the reporting on that server and the amount of blocking happening.
Steve Stedman 16:12
And that was such a significant change. I mean, it went literally from hundreds of blocked queries per hour to it hasn’t blocked since then. I mean, yeah, it was almost one of those, are we sure it’s working because it’s not blocking, and we’re, what, over a year and a half since we did that update, and there’s just no blocking going on because of the nature of the way that their updates were blocking so many reads, they were the perfect, perfect example of how to use that. So, yep, yep. So, do you have any other examples that we’ve done that you want to cover on that?
Derrick Bovenkamp 16:47
So recently, we’ve actually had a few different clients that we’ve worked with. But more recently, there’s, there’s one in particular that I have in my mind, where we, we went from, I believe it was SQL Server 2016 and, you know, they went to new hardware and SQL Server 2022, specifically to get them up to date, and then also to turn on RCSI. And this one was one where they were, they had some very, very active tables, and they were struggling with blocking. And I believe it was also, you know, hundreds of blocks an hour. And, you know, sometimes those blocks were really stretching out for a long amount of time, or would take time to clear. That’s the other thing is once, once you start getting that blocking tree get larger and larger, when, when one of the rights does clear, then the next right comes in, and that could take a long time to clear. And now this one, we were working heavily with them to add indexes and tweak little things to try to get around it, but we really needed to get RCSI in there. And that one, as soon as we turned it on, they’re, they’re blocking with, you know, I think not to zero, but almost to zero.
Steve Stedman 18:00
Yeah, and the key with that is the blocking of readers, blocking writers, meaning SELECT statements, blocking inserts or updates or deletes or insert update or deletes, blocking SELECT statements that absolutely went to zero. Where we still do see some blocking in that environment is where two things are trying to update the same table at the same time, and like we talked about or showed in the example earlier, that’s still going to happen with READ COMMITTED SNAPSHOT, because you can’t have two people changing at the same time, but all of the reads that were being blocked or being causing blocking are no longer in that scenario. So that was a huge win, I think, in that example,
Derrick Bovenkamp 18:40
Yeah, and I, and I think what I talked about earlier, you know, that’s end users will also notice the reads a lot, right? And, you know, maybe an example is, you know, you’ve got a website where you’re, let’s say, a web store, right? You’ve got a store on there. Well, people are usually doing a lot more browsing than actually purchasing, and what’s called the purchaser, right? And the browsing is a read. And you know, if every time they click on something in the store, and it takes a long time to come back because there’s a write happening, that would be, you know, that that would really slow down all those readers. So I think the big thing here is, each time we’ve seen this for every customer. We’ve done it on their end users have noticed a significant improvement, absolutely.
Steve Stedman 19:25
And take that online store example you’re talking about, and think about holiday season or Black Friday or shopping season, where all of a sudden there’s a lot more people shopping online now, RCSI may take that from previously, taking the site down completely to now you just got orders, maybe slowed down a little bit because there are other orders going on. Big difference there in the affected outcome for the people using the website at that point.
Derrick Bovenkamp 19:54
Yeah. And I think the other thing that you already touched on, Steve is we expected to see the. Temp DB get hit harder. But because there was so many version on, version improvements between 2016 and 2019 we actually saw Temp DB get hit less hard, and the server work a lot better.
Steve Stedman 20:12
Derrick, just to correct you said 2016 to you should have been to 2022 and yeah, that was really amazing, being able to go and look and we were expecting an increase in temp TB IO by using RCSI, and we actually ended up with less Temp DB IO issues than we had on the previous environment, just because of so many improvements in 2022 and what’s interesting is, when we look at these blocking scenarios, some people have the approach of, well, let’s just throw some more hardware at it. And even if you’re taking like, eight core SQL Server, and you’ve got an unlimited budget and you threw 150 cores at it with the fastest memory possible, well you’re still going to end up with blocking issues because the locking is occurring here. It may be a smaller window, but by turning on RCSI, you can actually get better performance or reduce blocking without having to spend all that extra money on more hardware.
Derrick Bovenkamp 21:09
And I think that’s the two things. One, you can save money on hardware, and you can save money on re architecting the database, like the customer you were talking about a couple of years ago is, you know, when you’re up against, like, let’s re architect everything we have built, versus do an upgrade and get an improvement right away.
Steve Stedman 21:30
Let’s do an upgrade and get an improvement right away. Or sometimes you don’t even have the option to re architect some of this stuff, you know? I mean, it might be like the example a few years ago. I think that was one where they had some third party reporting system that was being used, and that reporting system was what was causing all the blocking and their code, which was the SELECT statements, well, they couldn’t change the vendors code that was doing it, so it was really the only option they had to improve the performance there. Okay, so then, how do we go about enabling RCSI? What does it take to do this?
Derrick Bovenkamp 22:02
It’s a pretty straightforward process. And I think you even showed it in your demo. We usually put the database in single user mode, give it an alter, alter database, database name, and set recommitted SNAPSHOT on, and then throw it back in multi user mode. And you does require that system admin access. So you know your regular end user that’s using SQL Server can’t do it, but you know us, you as a DBA, should have the access to your SQL server where you can turn that on.
Steve Stedman 22:34
Now, one of the things to keep in mind is, if you just run that alter database to set READ COMMITTED SNAPSHOT on, and it just hangs and doesn’t return ever. Well, that’s a that’s a clue that, well, maybe you forgot to go into single user mode before doing it, and it’s just waiting for other transactions to finish, which may or may not ever completely clear out if, depending on the load on your system.
Derrick Bovenkamp 22:55
Yeah, especially if their reason for doing that is the server’s really busy, yeah.
Steve Stedman 22:59
And so it’s just something you wouldn’t want to necessarily be turning on right in the middle of the day when without knowing that you’re going to knock all the users off that database while you turn it on. So oftentimes, it’d be an after hour maintenance window thing where you could do it, but it could be done. I mean, if you’re already in a world of hurt, you could try turning it on, throw in single user mode, turn it on, and then go back to multi user mode if your system was already crashing and failing because of that. So I don’t know. It just depends on how much of a cowboy approach you want to take to resolving that issue, versus a planned and tested update.
Derrick Bovenkamp 23:31
Yeah and then to know too, like if it was causing an issue. I don’t think we’ve ever had to go back, but you would, you would potentially need to go and single user minute to set it back.
Steve Stedman 23:41
And all you have to do is change that, alter database and change that set, READ COMMITTED SNAPSHOT to on and change it to an off. And I did that just four or five times while I was building that demo video that we had at the beginning of the of the episode here. So yeah, quick and easy to do there.
Derrick Bovenkamp 23:58
And now, now that we’ve talked about enabling it and some real world use cases, and you know the whys and when it’s not a good fit. Is there any other gotchas that we need to talk about?
Steve Stedman 24:10
I think we’ve just hit on it a lot with Temp DB. I mean, that’s going to be the biggest gotcha, Temp DB, and making sure that you have monitoring and tracking for things like file growth and IO and those kind of things, so that we can make sure that Temp DB Temp DB doesn’t get out of control. You can monitor a lot of what’s going on with a dynamic management view called sis.dm, underscore, Tran, underscore, version, underscore, store, underscore, space usage. It’s a long name, but it’s a way to go and see what’s happening with the version store in temp TV right now. Now, the other thing you want to keep in mind is you might have, if you’ve got an application that is somehow expecting dirty reads like what you would have had going on with NOLOCK or something like that, your application may behave a little bit different. You want to make sure you test that, and then you may end up with different plan caches than you normally are used to because of the different read behavior based off of this.
So, I think the thing that that we’ve seen, the only time I’ve seen it, cause problems, is with one client. We had them with long, long running transactions that were getting left open. And what I mean was left open for like, more than a day, which is bad practice by any means have a transaction open that long, but we had to create a job that would actually go in and look for long running transactions that were more than a couple of hours. We actually we set it in more than a few minutes and then terminate them, because those long running transactions would keep a hold on the attempt DB and not release it until they were completed. So I think they had other issues going on in that system that with those long running transactions, that unrelated to what we had going on here with RCSI.
Derrick Bovenkamp 25:48
Yeah and that really brings us right into our next topic is, you know, Steve, and this is with every feature in SQL Server, you don’t just really want to turn it on and forget it. You want to be monitoring it and following up afterwards. And you know, that’s where we use we use database health monitor, and we have some features in there to help keep track of your Temp DB load and how RCSI is affecting your SQL Server.
Steve Stedman 26:17
And on that example that we talked about, where the client, we turned it on, and we went and looked, and we compared the IO on Temp DB before and after the upgrade. I mean, that was database health monitor we were able to use to do that. And it was just really amazing to be able to go and see the time of the upgrade, how big the Temp DB IO actually changed, going from 2016 to 2022 and being able to turn on RCSI. So gotta make sure you track those things and be able to know what’s going on. And sometimes you’re going to do something like that, and it may have a negative impact, you want to make sure you catch it.
Derrick Bovenkamp 26:49
Yeah. Certain life has a negative impact. You want to catch it. And then also you want to be able to show the positive impact. You know, multiple times when we turn our on RCSI, the actual seat of a pants, has noticed a difference. But if that’s not the case, you want to at least be able to have the data to show that, hey, we really did make an improvement, even though it’s maybe not, is seen by the end users.
Steve Stedman 27:16
And like you said, Every time we’ve done this, it has been seen by the end users. But it’s always good to be able to show that, yes, our deadlocks have changed by this amount, or our blocking has changed by that amount, or long running queries have changed by this amount. And that’s why I just love all the reports we have in database health monitor to track that. So I guess then at this point, I mean, I’m just thinking, I mean, you were kind of joking with me the other day, Derrick, about I bring this one up the what was it? CTE, or common table expressions versus RCSI? And, I mean, I Gosh, 15 years ago or so now, I wrote the book on common table expressions, and I learned a lot about common table expressions. So from Derrick’s perspective, a lot of what, when we’d run into a weird query, it would always be a CTE to fix it. And he asked me, well, is RCSI the new CTE in that example, meaning it’s the new it’s the new hammer to fix everything. And the answer is, no, it’s not the new hammer to fix everything, but it is a great tool. And if you have it, if you know how to use it and keep it in your tool belt ready to use well, and know when the right time is to use it. It’s an awesome feature, and being able to take advantage of that, we’ve seen massive performance boost on several clients that we’ve dealt with here. And I would say, though, make sure you test it and understand it and have ways of monitoring and tracking all those things before you go ahead and use it. Yeah, for sure. Okay, so let’s talk about just kind of wrap it up here, some of the pros and cons around RCSI. And I’ll start by throwing out, well, one of the pros is that you have reduced blocking on reads. I mean, that’s gigantic.
Derrick Bovenkamp 28:54
The main reason for doing it is you reduce that blocking significantly, which can really help your end user application work a lot better.
Steve Stedman 29:05
And then as far as cons, I mean, the biggest one we’ve seen is just temp TV if you’re on 2022 it’s not as big of a con as it used to be, but just more Temp DB issues, IO issues at that point.
Derrick Bovenkamp 29:18
And those are more for servers that are already at capacity or beyond capacity. You know, if you’re already struggling so bad that you’re out of this space, and your CPU is at 70% all the time, and your IO is really struggling because you don’t have fast enough IO, you know, that’s where you maybe you need to get that stuff fixed before you turn on RCSI or turn on some of these other things. But I think for servers that you know are already, you know, the hardware is not the problem. And we’ve seen this, right, Steve, where we’re like, the hardware is not the issue of the slowness. It’s something that RCSI will actually fix.
Steve Stedman 30:01
It’s the query logic and the things where there’s lots of updates going on and there end up blocking lots of reads, and yeah, that RCSI can have a big impact on that. But if you’ve got a system that’s overloaded or slow and it doesn’t have a lot of updates going on, it just has a lot of selects going on and there’s no blocking happening, well maybe RCSI is not the right thing for you in that case, but if you’ve got a lot of blocking going on where selects are blocking, updates and vice versa, well maybe it’s a great solution for you. So call to action here that I’d like to say that, evaluate this, try it out in a test environment, if you can with careful monitoring database health monitor is a great tool to use for tracking and keeping seeing how things are going with your system for before you do it, as well as after. And if you need help with this, reach out to Stedman solutions, and we can help with SQL Server health check, or maybe we help you implement RCSI if you need to. And the other thing is, if you do need help, we have our managed DBA services where we help take care of your SQL servers for you. And in that case, it’s just part of the part of the contractor, part of the agreement you say you want RCSI, we help you get it all turned on.
Derrick Bovenkamp 31:14
Yeah, we look forward to helping you out and that’s where you know, even if that’s just using database health monitor, that’s great. Or you want that health check, or you want us to do it for you, or you want us to teach you how to do it, we’d be we’d be happy to work with you. Just reach out to us.
Steve Stedman 31:32
Okay, well, anything else you want to add? Derrick, before we wrap this up?
Derrick Bovenkamp 31:35
No, I think that’s great. I think go check out if you have a lot of contention, if you have a lot of blocking due to writes and lots of reads, go check out. RCSI.
Steve Stedman 31:47
Yep, absolutely. Well, thanks for being a guest today. Derrick, always appreciate having you on the podcast, and I want to thank our listeners for listening and watching. And I’d like to invite everyone to join us next week for another episode of Stedman SQL podcast. Also, if you’re interested in being like Derrick and being a guest on the show, if you have an interesting SQL Server topic you want to discuss, reach out to us through the contact form on the Stedman solutions site, through the podcast section, there’s a way to ask to be a guest, and we’ll consider you. And we’d love to have you on the podcast. If you’ve got something interesting to talk about. Remember, all of our podcasts are available on YouTube and on Spotify, you can get those short URL of Stedman.us/podcastYouTube or Stedman.us/podcastSpotify. I know I say short URL, they don’t seem so short when I spell them out that way. So anyway, thanks for listening and thanks for joining us today, Derrick, and have a great day. You. Steve, 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.