- Host: Steve Stedman / Mitchell Glasscock
- Topic: 5 things you should never do with SQL Server
- Listen on Spotify
Stedman SQL Podcast Season 3 Episode 2 5 Things to Never Do with SQL Server
Welcome to the Stedman SQL Podcast Season 3, Episode 2, hosted by Steve Stedman and joined by Mitchell Glasscock from the Stedman Solutions team, where we dive into “5 Things You Should Never Do with SQL Server (Plus 2 Bonus Items)” and explain how common but dangerous practices like shrinking databases, clearing the procedure cache, using REPAIR_ALLOW_DATA_LOSS, blindly trusting the Database Tuning Advisor, and running sp_updatestats can seriously impact performance or cause data loss, along with two bonus mistakes around auto-growth and auto-shrink that we see far too often in the real world; we share expert insights, real-world examples, safer alternatives, and a special January offer for new managed services customers—12 months for the price of 10—while also previewing what’s coming next on the podcast and how Database Health Monitor and Stedman Solutions Managed Services help keep SQL Server environments healthy and reliable.
Podcast Transcript
Steve Stedman 00:00
Welcome to the Stedman SQL Podcast. This is season three, episode two, and I’m your host, Steve Stedman, and today I’m joined by one of the Stedman Solutions team, Mitchell Glasscock, welcome Mitchell. So I’d like to welcome all the listeners to our podcast. Thanks everyone who comes back and listens every single week or every other week, depending on when we broadcast these and like I said, this is season three. Stick around. We have lots of other episodes planned for this season. In season one or two, we had a total of 12 and 28 episodes for a total of 40. So this is technically our 42nd episode so far. Thanks for joining. If you’ve missed out on these previous episodes, please take a look at some of the most popular episodes from season one and season two. First off, we had our indexing episode, which was one of the most popular. And you can get that at stedman.us/episode2.4. Another popular one was the building your career episode. A short URL for that is stedman.us/episode2.22 our third most popular episode was join types, and you can get that at stedman.us/episode1.12. All right, well, five things that you should never do with SQL Server. That’s what we’re doing. That’s what our topic is for this week, and just to be safe, in case you don’t like one of those five or two of those five, we’ve added two bonus items as well, so you’re really getting seven for the price of five. So what we’re going to do is we’re going to dive into some of the common pitfalls that can wreck your SQL server performance, integrity, or even cause data loss. We’ll cover the five big ones, and we’ll explain why they’re dangerous with real world insights. And keep in mind, we’re going to do the five and then two more at the end. Also Quick disclaimer, these are based on expert consensus. Is from SQL Server professionals and the SQL Server community experiences. I want to make sure that you always test these in in your environment in a way that you can undo them or roll back before you ever before you ever try them on your own. So let’s jump into it. But first a word from our sponsors is your SQL Server slowing down your business, slow queries, bottlenecks and unexpected issues eating up your time, introducing database health monitor, the powerful tool built by our team at Stedman solutions, get real time insights into performance with over 100 built in reports, index analysis, weight stats tracking and proactive alerts, quickly diagnose and find problems before they impact your operations with an easy to use interface for DBAs and developers, monitor unlimited servers, tune queries and keep your databases running healthy and fast. Download a free trial today at Databasehealth.com and take control of your SQL server performance.
Steve Stedman 03:44
So on to the five things you should never do with your SQL Server. Now, first off, when I say never, I guess what we really mean is almost never, or almost never, without discussing them with someone who knows a whole lot about SQL Server and knows the pros and cons before doing it. There are things that are dangerous and they can be done and but generally shouldn’t be so. Mitch, as we get into this, do you remember a time we’ve ever come across someone doing these?
Mitchell Glasscock 04:12
I think we’ve come across pretty much every single one of these happening in real world instances. And it’s really scary.
Steve Stedman 04:19
When it’s happening on a production environment, which leads us into shrinking databases with DBCC shrink database. And what this does is it reduces the overall size of the data or, or, I should say, data and or log files, to reclaim disk space. Now the problem with shrink database is that it just kind of tries to make the file as small as possible, independent of how things are going to perform or what other impact that has in your system. So can you think of some reasons why we would, why we would say that this is bad, or why you would not do it routinely?
Mitchell Glasscock 04:56
I mean, some of the things that we’ve run into when we’ve seen. Shrink database, or DBCC, shrink database is some index fragmentation, or it can cause massive index fragmentation. I can also reverse page order, which will lead to poor performance on future reads and writes, and then that space often just fills up again quickly due to the auto growth taking back up,
Steve Stedman 05:19
yep, and that last one filling up or the space filling up again. Yeah, that’s a real world example that we’ve seen on many occasions where someone shrinks the entire database and the log file, like maybe nightly on a maintenance plan or something like that, and then the very next day they grow back immediately, causing excess slowdowns. So here’s the thing with SQL Server, when you’re growing or shrinking a file that causes additional blocking on different parts of your database. So if you’re going to do a massive shrink, it’s going to cause some blocking and a lot of IO slow down while things get moved around in that database. And then if it needs to grow again, through auto growth, what’s going to happen is the database is going to expand. There’s a lot of blocking that occurs while that happens, and making sure that your database files are properly sized is a smart thing to do, but having Auto Shrink run or running shrink database, DBCC, shrink database is not a good idea. So that brings us to DBCC shrink file as part of the recommendation here, where shrink database just kind of goes in blindly, shrinks your database, all your database files, however many you have in your log file. But sometimes you’ll end up in a situation where maybe you’ve had some growth, maybe you’ve done an import table, or maybe you’ve got a bunch of data in a database that is getting smaller over time, and you want to free up some of that space. Well, we’re not saying don’t ever shrink your files. We’re just saying don’t use the DBCC shrink database command. Now sometimes, if your log file has grown, you want to make that smaller, you can use shrink file, DBCC, shrink file on that. Or you can use it on your data files as well. But we just generally don’t recommend doing it as like a nightly practice, because it just causes a whole lot of IO that’s just going to make your performance worse in the long run. Any other thoughts on that one?
Mitchell Glasscock 07:18
Mitch, I think, like you said, it’s important to do your sizing before. And it’s a, it’s a planning item, to look at your file sizing beforehand, instead of trying to run DBCC shrimp database to manage file sizes on your drives beforehand. So that’s a, that’s a separate conversation on proper drive sizing. But you shouldn’t be using this as a solution, right?
Steve Stedman 07:46
And if you are going to use shrink file to go and adjust it on a specific like a one off basis here or there, you should do that during a maintenance hour or maintenance time, whether it’s after hours or sometimes where there’s not a lot of load on your system, because it will impact the performance while it’s going on. And yes, there are cases where you might need to shrink a file make sure the system is not under load when you’re doing it. All. Right. On to the next item number two, and this is one, gosh, working with a client, and they have a product supplied by a vendor. The vendor was having issues with performance and production, and the vendor came back and recommended, oh, just run DBCC free proc cache. That’ll fix everything for performance. Well, clearing the procedure cast with cache, with DBCC, free proc cache is not a good thing to do, because it takes all of the plans that are currently cached in memory and flushes them, and then the next time a query gets run, it has to come up with a new plan for that cache, rather than using a plan that you already have now. That’s very similar to the performance that you see after you restart SQL Server, where there’s no plans cached at that point. And the problem here is that there’s a little bit of work to figure out the right plan, and depending on things like parameter sniffing and other stuff like that, you may get the wrong plan. So it forces recompilation of every query, and this can cause a lot of CPU load over to you on this one. Any thoughts.
Mitchell Glasscock 09:16
I mean, some better alternatives to this are clearing the specific plans by handle or using optimize for hints, this will help address root causes like outdated statistics when you’re trying to seek out performance improvements on stuff that might be currently failing or might be having performance issues at the time.
Steve Stedman 09:37
Yeah, that’s a really good point. And the difference between running free proc cache to clear everything versus running free proc cache to clear a specific plan handle well, if you just clear one plan for a single query, that may help once in a while, but it’s not going to have the overall negative impact that you have of clearing all the plans for all the queries in all of your data. Basis on that SQL Server. So, yeah, this is one of those that I don’t know. It’s one of those that people who don’t really understand how the plans are being used may recommend it. I would recommend never running this, yeah, never running this for all plans. Just do it as a one off basis. All right, so what’s our next topic? Mitch on a number three.
Mitchell Glasscock 10:22
Number three is using repair allowed data loss when you’re running DBCC check dB, so the repair allow data loss command or the parameter for DBCC check, or DBCC check DB is an aggressive repair option for database corruption. What this does. Let’s see. We’ll let Derrick explain Actually, why repair allow data loss is so bad.
Steve Stedman 10:49
This is from our corruption episode a year or two ago.
Derrick Bovenkamp 10:53
So Steve, one of the things that we see people do when they encounter corruption and they see an error in their SQL server log, or they realize they have corruption, they go to Google, and what’s one of the first things that comes up in Google to fix corruption? What does Google say?
Steve Stedman 11:11
Oh, well, you got a lot of pages where people are suggesting you run repair, allow data loss, and if you go, don’t you on your Derrick Bovenkamp blog page have like a giant red alert button or something like that. Repair allow data loss.
Derrick Bovenkamp 11:29
I’ve got the Apollo 13 master caution alarm that shaking around a repair allow data loss.
Steve Stedman 11:36
So what repair allow data loss does is it basically says, scan my database and any page or any 8k chunk of that database that looks corrupt, just throw it out. It’s sort of like if you built coffee on a book and you went through in every book page that had some coffee spilt on it, you’re going to throw away, and then you try and read the book later. It’s not going to make any sense. But what repair allow data loss does, and some people phrase it as well, it’ll get rid of data. If it needs to no it’ll get rid of data if it sees corruption at all, it’ll just throw it away. And one of the things we see, I mean, how many times have we seen Derrick where somebody says, Well, I ran repair allow data loss, it didn’t fix it, but it got rid of the errors, and then now we need to recover the database. Not only do we have to fix the corruption, but we have to get back all those rows that were somehow thrown out.
Derrick Bovenkamp 12:29
I mean, I would say, like in the extreme, lucky it gets stuck and it can’t throw anything out and they’re okay. But a lot of times we you and I have seen it. It’ll throw an entire table out, not just an 8k chunk. When there is maybe only a couple 8k chunks that are actually corrupt, it’ll just be like, throw that entire table out. And we’ve seen people, and I don’t think in, you know, to be fair to them, they’re in a stressful situation, and they’re reading what people say. We’ve seen people run that and not really realize that, hey, maybe it says it’s not corrupt now, but I may have lost crucial data. And if you’re talking about payroll data or banking data or healthcare data, you know how many of you are willing to just, you know, go into a filing cabinet and pick a folder and throw it out, and know you’re never going to need it again.
Steve Stedman 13:27
And you know, if, if this is my bank, and they’re running repair allowed data loss, and I suddenly looked and see that my account balance is not what I expect it to be, and they just happen to throw away a month worth of my transactions in the bank, that would not make me very happy. So one of the things that we always tell people before ever using repair, allow data loss, call us and we can talk about options, and that’s one of the things we offer, a free 30 minute consult. If you’ve got a corrupt database, call us. And sometimes we’ve been able to talk people through in 30 minutes and come up with a solution. They go and do it on their own. Didn’t cost them anything. Other times, it leads to a full corruption repair on our part. But either way, we’re going to use that 30 minutes to take the best stab we can at doing whatever we can to get that database repaired for you. Now with that, there’s also the repair rebuild. And from my experience, repair rebuild is okay to run if you’re running DBCC check table with repair rebuild and you’re just repairing an index in a table or something like that. But oftentimes, if it’s something that’s actually in the data pages for a table and not an index, it’s going to push you to run repair allow data loss. Oh, and that’s one of my peeves as well. Is that when you run CheckDB, it will often tell you repair, allow data loss is the only option to get this back and or to get your database back. And yeah, it’ll bring your database back, but it might be missing a whole lot of data after you run that, so do not run repair, allow data loss. And just as a reminder, because it Yeah, it throws data. Database out, all right? Well, there’s a blast from the past, from, I think that was two years ago that Derrick and I recorded that. And, yeah. I mean, the thing is, repair, allow data loss. What it does, it just throws away the places with corruption, and it eliminates opportunities that you may have to be able to repair that at some point. So better alternatives on that would be things like restoring from a clean backup and then moving data over. If you’re able to back up the data out of that table and salvage everything you can, and then maybe drop the table and add it back and put all the data back into that table. That’s a much safer way to do things. So if you’re ever in a position where you think you need to run repair, allow data loss. Call me first, or call Mitchell first, and we’ll talk about how we can help you, and so you don’t have to lose data, or you have your best chance of getting data restored.
Mitchell Glasscock 15:52
So yeah, I really like Derrick’s example there, where it’s like opening a file cabinet and grabbing a random file and just throwing it away and you’ll never get it back. And it’s easier than that, because sometimes copying and pasting in a SQL Server and hitting f5 is a lot less consequential than opening a file cabinet in person. So knowing what you run before you run it is really important.
Steve Stedman 16:18
Yep, for sure. All right, so next one, number four on our list, blindly relying on the database tuning advisor. And maybe I should rephrase this to just ever using the database tuning advisor. The database tuning advisor, or DTA, is one of those things that comes with SQL Server, and it’s basically a component you can turn on, that will monitor the load on your system and come up with a bunch of suggestions for indexes and statistics based on the workload. Now, when it creates indexes, it generally has DTA included in the index name, so we’re able to see what indexes were created by the database tuning advisor over time. But the thing is, I don’t know. I mean, the way I’ve looked at this over time, and I’ve said this before, is that because SQL Server is licensed on a CPU or core based licensing, if, if Microsoft wanted to come up with a way to sell you more licenses, it would be to create a tool that goes and adds a bunch of junk into your database that maybe bloats it and makes it makes you think things are improving, but over time, you have to end up buying more licenses because it’s so bloated with all this junk. I don’t know. Mitch, is that an unreasonable assessment there?
Mitchell Glasscock 17:38
Or I think that’s a fair assessment. I mean, DTA just looks at what SQL server needs, without recommend or looking at the true cost of what it’s going to put in. SQL Server will just say, hey, this would be really handy if you would put an index on this. But it doesn’t consider that this index is massive, just it is a hog that will take up everything that can be thrown at it.
Steve Stedman 18:04
An example of that is, if you’re familiar with the include statement on indexes where you have here’s four or five or 10 columns, or whatever, that’s your main index columns, and then you include like every other column from the table in the include section. Well, yeah, the DTA has a lot of those. And I find that if you were to analyze what was there and get rid of the includes and maybe just have those things that are in the index itself, it would be way more efficient. And so the alternative that we offer on this, I mean, there’s, there’s a lot of different alternatives, but missing index DMVs, looking at execution plans and understanding what indexes are missing using the Query Store or using database health monitor with like some of our missing index suggestions, or the SQL performance monitor that we have in database health monitor that will catch the indexes that are needed right now that will help with the queries running In memory. Now, with that, I say it’ll catch them. It’s not going to go and add them automatically, but with any of these, you’re going to want to look at what indexes are being suggested, and then look at what indexes are already there. And it might be that whatever tool you’re using is going to recommend something very similar to what’s already there. And you need to determine, will there be actual value added by adding this index? I know in database health monitor, we have some reports that show things like inefficient indexes, and oftentimes, some of those DTA indexes are huge, and they show up in there as not being not being used efficiently. And what not being used efficiently generally refers to in that environment is that there’s lots of updates, but that there’s very few usages of that index. Anything else on DTA before we move on Mitch.
Mitchell Glasscock 19:49
Like you said, with indexes, we always, we always test them after adding and if we have index suggestions, we always say, test it. Make sure. It’s make sure it’s running as expected and keep an eye on what’s happening, because you don’t want to add, like you said, an index that seems useful and just never gets used. So that’s a very important note to indexing. It’s a balance to run. Oh yeah for sure.
Steve Stedman 20:19
All right. On to item number five. This is running the MSDB procedure that’s SP underscore update stats. And gosh, this is one of those that we’ve seen so many times. And what it does is it runs and it updates statistics for all the tables in a database, and oftentimes it’s using, it’s doing a whole lot of work to update things that haven’t changed or may not need any updates. So this, I mean, I think this was an obsolete feature left over from SQL Server 2000 and that there are much better ways to do it. Now, for instance, we use the OLA Halligan scripts all the time for doing index and statistics maintenance. And the thing that we get the most value out of with that is with those scripts, they go through and they look and see, do these indexes need to be rebuilt, or do these statistics need to be updated? And the key here is, with updating statistics, it’s a very IO expensive thing to do, and if you cannot rebuild statistics when it’s not needed, you can save a whole lot of IO on your system. One of the things that we’ve seen in the real world on this I’ve seen it many times, but it was with a medical clinic that they had a pretty good sized database with all their patients, and it was the thing that the doctors and nurses needed every day in order to be able to, like, check people in and go record their vitals and record all the stuff that was done for that patient as they visited the office or the clinic. So what we were seeing was that they people were running the original update, SP, update stats. It was going through and updating statistics for everything, and it was something that they were kicking off at 11pm and it wasn’t finishing until around 10am the next day. And what that meant was, from that time that that clinic opened until 10am when it finished, their system was really unreliable and oftentimes completely locked up, because when it’s rebuilding these stats, SQL server doesn’t necessarily make the right decisions on how queries are run. So what we did to fix it is we got rid of that procedure and said, instead, we’ll use something like the OLA Halligan scripts and only rebuild those statistics that have changed, and that made a huge difference. And instead of running for 11 hours, I think, or whatever it was, yeah, 11 hours, we were able to get the whole thing finished in under two hours, and the system performance improved massively. I don’t know Mitch, anything else on that one to add, or did I kind of hit it all there?
Mitchell Glasscock 22:58
I guess. A note with the Ola Hallengren scripts is that you can set a time frame. You set the start and limit for how long these are going to run. So even if you have, say, a massive database that needs and has a lot of changes in these statistics need to be updated frequently, you can set it so it only runs in your off time, which will prevent cases where it will run over into production hours.
Steve Stedman 23:24
That’s a good point. And then if that limit is like two hours, and it doesn’t get everything it needs today, it’ll hopefully catch them tomorrow or the next day, and you’re gonna have a lot better performance overall, doing it that way than letting it run throughout the whole day to get all those updated. That’s a good point, definitely. All right. Well, that’s the first five before we move into the two extra bonus items. I just want to suggest that everyone subscribe. Hey, listeners, if you’re loving these deep dives and mind blowing insights on the Stedman sequel podcast, imagine getting even more exclusive episodes, behind the scenes, bonus content and premium interviews you won’t hear anywhere else. Head over to our YouTube channel right now and hit that subscribe button turn on notifications so you never miss out on the content dropping every week. Join 1000s already unlocking the full experience, and don’t get left behind. Subscribe on YouTube today. So one of the things that I mentioned as a reason to subscribe is that extra bonus content. Well, here it is. We’re going into our bonus segment right now. Mitch, two extra things you should never do this. Next one is, one we see a lot is auto growth settings and small fixed sizes for growth or percentage growth. I don’t know. How many times have we seen this working with clients when we take a look at their system for the first time?
Mitchell Glasscock 24:52
Yeah, this is one of the most common things that we run across, and it’s, it’s easy to fix, it’s easy to catch. But if you don’t. Fix it. It’s one that can cause massive problems, especially that percentage growth. This is one where it can be an exponential problem if you let it go without fixing this one.
Steve Stedman 25:11
So just to be clear here, we’re not saying don’t use auto growth, because I think you should use auto growth on every single database file you have, because if you don’t and that file hits a point where it needs to grow instead of growing, and you don’t have it turned on, it’s just going to fail whatever transaction is currently running at that point. But what we’re saying is, don’t use auto growth, specifically with small fixed sizes, like a lot of the time we’ll have one megabyte or even 10 megabytes or 10% growth. Now, there’s different reasons for why you go small, why you don’t want to go small, or you don’t want to go a percentage so imagine you’ve got a brand new database file you’ve just created. It’s just about empty. You allocate it for 10 megabytes. Great. That’s way more space than you need right now, because there’s nothing in there. But then over time, you add tables, and that database grows. And once that 10 megabytes gets full, it grows by 10% to 11 megabytes. And then once that’s full, it grows by 10% to 12.1 megabytes, something like that, and it grows and grows and grows in all these small chunks. Well, at the time the database file grows or shrinks, like we talked about earlier with shrinking, is that there is some blocking that goes on in your system while it’s happening, so what we recommend, generally is auto growth settings that are sort of proportional to the size of the database, and I’m not and we’ll get to that in a second, but that are also related to the speed of IO that you have. I mean, in a perfect world, you would expand all your files after hours in a maintenance window and never have auto growth occurring during the day. But the reality is that doesn’t really happen all the time. So what we generally recommend if you’ve got fast storage is we go with larger auto growth settings. If you have slow storage, we go with smaller auto growth settings. But when we say larger or smaller, we’re generally in like the 250 megabyte size, up to a gig or two gigabyte size, depending on the size of your database. Now, if you’ve got 100 megabyte database, maybe growing at 200 megabytes is not right. Maybe you want to grow it at 50 megabytes at a time. But if you’ve got a I don’t know, one terabyte database, you sure don’t want to grow it in like 200 gigs at a time, because that’s going to be really slow and inefficient. But you also don’t want to grow it in like one megabyte sizes, either. So we really recommend there. I mean, if I had a one terabyte database, it better be on fast storage, and I would usually probably go with a gigabyte of growth, or maybe two gigabytes of growth at that point, but if it was on a little bit slower storage, I might go smaller, like 500 megs or even 250 megs on a system like that. So that’s one of those things that we do as part of our performance assessments, is we analyze all that and figure out what the best settings are for your databases and your environment. So mostly what I’ve talked about there has been data files, Mitch. You want to fill us in on what happens with log files and VLFs with these kind of growth patterns. Yeah.
Mitchell Glasscock 28:16
So the VLFs, they can get really nasty, especially during stuff like recoveries. So your log file grows out in virtual log files each of these, especially if you have them set to the percentage, they get incrementally larger and larger and tack on to the end of your log file each time. What can happen is, if you do need to do a recovery, doing this recovery with a bunch of VLS, and especially large ones at the end, and make that recovery last a long time. We’re talking hours, if you try and do that with without the race settings. So your growth settings need to be your growth settings are especially important in your logs, yep.
Steve Stedman 29:01
So let’s take an example of a data file that you may have had incorrect growth settings on. Well, is there anything we can do to fix that? Well, really, all we have to do is set the growth going forward on your data file and it’ll be good. But like Mitch said, on the log file, if you’ve had it set incorrectly, it grows in those VLS, and you’ve got a lot of little chunks in there that eventually get bigger and bigger over time. Or maybe, if you’ve got a fixed size, they stay small over time. Well, we have the VLF report and database health monitor, and what we oftentimes recommend in that case is, let’s say the log file is the size it needs to be. What we’ll oftentimes do after hours in a slow time in a maintenance window is shrink that log file as small as we can possibly get it and then expand it back out in chunks. So instead of having hundreds or 1000s or 10s of 1000s of virtual log files inside of that log, we end up with maybe 100 to 200 kind of that range is usually a more comfortable place to be you. It gives you better manageability of your log files. So you can do all that with DBCC commands, or you can use the tools that we have in database health monitor to help with that. All right, on to bonus number two. Now this kind of overlaps with the number one item we had in our list, which was, don’t, don’t use DBCC shrink database, but Auto Shrink is so basically, what we’re saying is, don’t ever enable Auto Shrink on any database. This is a database option that will automatically shrink files when SQL Server decides it wants to and when there’s free space in a database file. Now imagine if you’ve got auto growth on, which we always recommend, and you’ve got Auto Shrink on, well, your database could get in this thrashing mode of either constantly shrinking or expanding to keep your database as small or as big as possible. And basically it puts you in a position where it’s just doing a whole bunch of work to shrink and grow that file, and all of that is going to negatively impact your performance. So what we recommend is, if you have any database with Auto Shrink enabled, is that you turn it off immediately and you learn how to manage your space correctly. Mitch, any thoughts additionally on that?
Mitchell Glasscock 31:20
No, I think, like you said, the thrashing is the important there, where it can just fight itself back and forth, growing, shrinking, growing, shrinking, and file management is something that a DBA needs to manually consider, like we talked about earlier.
Steve Stedman 31:37
Yeah, and I often think about this is, imagine if you worked in a office with cubicles, right? And every time the person in the cubicle next to you left for the day or went to lunch or something, you move your cubicle wall out to take up a bigger space, and then when they come back, they move it back to the original space, or even smaller to get even with you. That would just not be sustainable. Yeah, Auto Shrink is kind of the same way. Just don’t do it all right. Well, if you want to be a guest on your show, here are some options. Are you interested in being a guest on the Stedman SQL podcast? If you are just reach out to us and we can talk about what topics, things you want to cover, or talk about anything relating to SQL server, Database Health Monitor or about our company. You can reach out to us at Https://Stedmansolutions.com/guests, or go to the podcast page and click on the guest link, fill out the form and find out if you’re going to be a guest on one of our future episodes. Well, speaking of being a guest on the podcast, I’ll just take this opportunity to say thank you, Mitchell, for joining me on today’s podcast and being a guest. It’s not just team members or employees that are welcome. We’ll have anybody in the community, SQL Server, community that has something of value that they want to bring, that we think will be valuable to our customers or clients. So please join us. So that really wraps it up. We just want to go through and summarize a few of these here, really from the top. I mean, the first one was DBCC shrink database. Just don’t do it. There are better options and get your databases sized correctly. And then DBCC free proc cache. Well, you can use that. It’s okay if you’re doing it on a single plan, but don’t run it on the entire cache to flush everything out of memory on that repair, allow data loss. I think Derrick said it best in there. And just don’t do it, and then blindly relying on database tuning advisor, yeah, there’s way better options in today’s world. SP update stats, stay away from that. And then auto growth, setting it too small or to a percentage, that’s an easy fix going forward, and then enabling Auto Shrink. Just don’t do it. There’s no reason to ever do that. So yeah, hopefully staying away from those will save you from performance nightmares, data loss or unnecessary maintenance headaches, and if you’ve had horror stories with any of these things, please comment on this post or in the in the video as to what you’ve seen and the experience that you’ve had there. I’d love to hear what other people have run into with these so what’s our next episode?
Mitchell Glasscock 34:15
Mitch, next episode. We’ll be going over the Database Health rewards program, and this is what you get when you sign up and join all the users of Database Health Monitor.