- Host: Steve Stedman / Shannon Lindsay
- Recording Date: December 31, 2025
- Topic: What will you do different this year with SQL Server
- Listen on Spotify
Stedman SQL Podcast Season 3 Episode 1 What Will You Do Different This Year
Steve Stedman and Shannon Lindsay discuss SQL Server security and performance improvements for the new year. They highlight a 16% discount for new managed service customers and emphasize the importance of enforcing the principle of least privilege, implementing data encryption, and regular patching. They recommend using SQL Server audits, extended events, and the Database Health Monitor for advanced auditing and monitoring. For performance optimization, they suggest focusing on slow queries, optimizing storage and indexing, and enhancing backup and disaster recovery strategies. They also mention new features in SQL Server 2025 and the importance of ransomware preparedness.
Podcast Transcript
Steve Stedman 00:00
Welcome to the Stedman SQL Podcast. This is season three, episode one. This is our New Year’s episode. I’m your host, Steve Stedman, and today I’m joined by my co host Shannon Lindsay. Welcome Shannon. This month, for the whole month of January, we are offering a deal on our managed service customers. Well, for new managed service customers, where we will take care of your SQL Server, and you can get 12 months for the price of 10 for the first year. That’s a 16% discount in year one. So I’d like to welcome everyone to the podcast, whether you’re a first time listener or you’ve been listening since the beginning three years ago or two and a half years ago when we started this welcome back. So like I said, this is the first episode of season three. Let’s stick around. We have a lot of other episodes planned for this year, and in season one and two so far, we have a total of 12 and 28 episodes in each of those seasons for a total of 40 episodes. So this is technically our 41st episode so far. Thanks for joining.
Shannon Lindsay 01:24
Yeah, thank you it’s so nice to have continual listeners.
Steve Stedman 01:28
Yep, this week’s topic, what are you going to do different in this year? And it’s kind of a New Year’s resolution kind of thing, where we’re in the new year, it’s a good opportunity to just take a look at well, what do you want to do you want to do different with your SQL servers? As we wrap up 2025 and head into 2026 it’s time for SQL Server professionals to reflect on their resolutions for better database management, focus on actionable changes and enhance security and overall improvements. We’re going to dive into that in this episode, but first a word from our sponsor 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, wait 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 02:55
All right, so jumping into our first segment here, we’re going to talk about some ideas of things you could do this year to lock down your SQL Server. Now, as every year goes by, it seems that security matters more and more with the rising cyber threats and different compliance or auditing like GDPR, CCPA, HIPAA and others, security becomes more and more important than we’ve ever seen before. So let’s look at a few resolutions to consider for this year.
Shannon Lindsay 03:28
Yeah, I agree. I think especially as technology improves and it’s more accessible, there’s a lot more that we need to look into and consider. I think probably resolution number one would be to enforce principle of least privilege. Now how can we do this?
Steve Stedman 03:50
Well, the way we do this is really kind of twofold. One is we need to go through and fix it for those that are in place today. And then two is how we approach it for new users. But let’s take a look at how we do it for those that are in place. Are in place today, what we need to do is start out by auditing and revoking the unnecessary permissions for all users and roles. Now that can be a bit scary to go do it all at once, but maybe you do it step by step in your test environment and see how it goes. But the idea here is we want to move away from overly permissive defaults, using fixed roles like data reader or data writer, those kind of things sparingly, and to use custom roles for granularity. What that means is that if you’ve got someone that’s working on the server, on your SQL Server, and they’re just there to run reports. Well, maybe they don’t need full sysadmin permissions. Maybe they just need data reader or maybe a more limited on a specific database by database level. So what you do is you start by figuring out who are the users that maybe shouldn’t have those higher permissions, and then revoke. Them and then find out what’s needed. Now you got to be careful when you do this, because if you revoke too many permissions, it might make it so people can’t do their job. Just talking to a client yesterday where they revoked some permissions, and it made it really difficult for people to do things. So you need to make sure that you revoke the permissions, and then let the person test it and make sure they can still do their job.
Shannon Lindsay 05:23
Implement data encryption everywhere. Isn’t encryption at rest enough or no?
Steve Stedman 05:31
Well, what’s interesting is when you look at a lot of audits, a lot of the auditors are out there using the terms encryption at rest, and what that usually means is that your database files are encrypted on disk, and usually, if they’re doing a good job, it should also mean that your backups are encrypted on disk. But those could be two different ways of doing things. Now, the encryption everywhere also includes encryption in transit. So let’s say you’ve got your desktop computer connecting to a SQL Server that’s going through a VPN and a number of different connections. If somebody is on that network and you’re not using an encrypted connection, even though the data is encrypted on disk, someone could do packet sniffing or other things like that, where they can get in and capture that data when it’s traveling between your desktop and the server. So if you’re not doing this, it’s something to consider. You probably should be doing it. But really, the key here is number one, make sure you’ve got Transparent Data Encryption turned on all of your databases that contain any kind of privacy data. Then make sure, well, of course, with that, you want to make sure you have your TDE keys backed up and all of that kind of thing. Then next, you want to force SSL or TLS for connections, meaning you want to configure SQL server so that when people connect, they have to connect with a secure connection. It’s kind of the equivalent of the web browser, where, back in the old days, we just had HTTP, and then everything started moving to HTTPS for more security. Well, SQL Server has done the same thing, and you want to make sure you’re using that SSL connection and to make sure that everyone’s using it, so that you don’t have anyone that could possibly be leaking data that way, then we want to also make sure that we encrypt backups. Now that’s another step that you want to do on top of, or independent of TDE, but to also make sure that you practice the restore of those backups and make sure you’ve got that good so the benefits of all of this, it’s going to protect your data against data theft, and it’s going to meet compliance standards now really well, those both kind of mean the same thing, hopefully. But if you’re in a place where you’re being audited, make sure you’re doing it right. And this is one of those things that we help our clients with all the time and again, just yesterday, I was talking with a client, and they had TDE set up. But they had a couple databases that missed TDE because they were created later and they didn’t think to turn it on. So making sure that everything is TDE encrypted using SSL, TLS for connections and encrypting backups, got to do all three.
Shannon Lindsay 08:13
of those. Oh, regular patching and isolation. Why is that important?
Steve Stedman 08:18
Well, Microsoft, whether you’re on SQL Server 2017 or SQL Server 2025 they’re still finding holes, security holes that need to be patched, and keeping your server up to date makes it so that if someone does gain access to your network, that they are unable to use those known exploits, meaning there’s, let’s say there was a security hole or an exploit that was found in SQL Server four years ago. If you’re not doing patches and not keeping up to date, even on that older version of SQL Server, someone could still access it through that exploit. But if you’re doing updates, and Microsoft has patched that, even if it’s SQL Server 2019, to the latest service pack level. That means you know that someone’s not gonna be able to come in through that. Now, the other thing is isolating your SQL server from non essential network access, meaning that limiting who can get access to your SQL Server. It might mean that you can only be accessed from the office, or it might be meaning it can only be accessed from a data center network, but limiting it so that not everyone in the whole company has access to it. And then the other thing is, it’s important to disable unused services and different features during the install. I’ve seen this so many times where I’m going to do updates for someone on SQL Server, and I notice they’ve got both R and Python installed and a bunch of other features or services that they’re not using. Now if you need those things like R and Python or SQL Server replication, great, install them, use them and keep them patched. But if you. Have them installed and you’re not using them, it’s just opening up more security holes. So reducing SQL server to be the minimum you need for it to run without all those extra features, and certainly install them if you’re using them, but don’t install them if you’re not using and overall, this will reduce the attack surface and the overall reliability of your SQL Server.
Shannon Lindsay 10:22
That’s one of our benefits, I would say to our managed services, is that, I would say we do that for all of our customers, right?
Steve Stedman 10:32
Yes, yes. And where it gets tricky is, well, maybe the first time we’re patching SQL Server and we realize, Oh, they’ve got R and Python involved. And realistically, there aren’t that many people using those from what I’ve seen on SQL Server, and we look at it and talk to them about it and make sure they’re not being used. And then next time we do updates, we turn it off or uninstall it to reduce that overall attack service and exposure there.
Shannon Lindsay 10:56
All right, I would say next resolution might be to enable advanced auditing and monitoring.
Steve Stedman 11:02
There are a lot of different ways to do this now. You can do this with things like setting up a SQL Server audit or using extended events to catch different things that might indicate you have some kind of a threat. Or you can use something like the database health monitor, structure change log, which is something we added in 2024 to track and monitor who’s changing your database, something like that. We’ll catch and see, did somebody change a stored procedure? Did somebody change a trigger? Did somebody change a table structure, things like that in each of your databases. So you can catch it, see who changed it, and know that those kind of things are happening. It’ll also catch things like users being added into a database. If you have someone who has no business being in your payroll database, for instance, and all of a sudden you see some user pop in there that shouldn’t be there. Well, you know someone’s doing something maybe malicious or mischievous there. So what you want to do is create different audit specs to catch things like logins, failures, schema changes, things like that, and review those logs regularly. So the benefits of this is really getting an early warning on suspicious activity. I mean, let’s say it’s a holiday weekend and you’re planning on doing something and you’re not actively monitoring that server. Well, maybe if you have some alert alerts in place that not notifies your support team, then you’d be able to catch someone doing something malicious on that slow holiday weekend.
Shannon Lindsay 12:30
Yep, and like I said, this is something we’re happy to help with, and we do with multiple of our customers, and one way is through our managed services.
Steve Stedman 12:39
Let’s take a take a moment here to talk about being a guest on our show before we go into the next segment here. 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 Stedman solutions.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. Okay, so now into a few more new year’s resolutions to talk about. Want to talk about different things that we can do around boosting performance and reliability, and I think that security and performance go hand in hand in a big way, because a secure server, if it’s completely secure, is still useless if it’s slow or unreliable. So we want to make sure that what we’re doing covers all areas so that beyond just security,
Shannon Lindsay 13:45
yeah, leverage performance monitoring tools like our database health monitor. What can I do specifically?
Steve Stedman 13:54
Well, it really depends on what time and availability, you have to focus on improving the performance on your SQL Server. If you’re like a lot of SQL Server shops out there, well, where maybe you don’t have someone who’s doing full time performance tuning and monitoring, one of the things I recommend is use database health monitor to go in and find just one of the top five slow queries each week and determine what you can do to improve the speed. Now, the reason I say one out of the top five is typically on most of the really big SQL Servers I see, you end up with somewhere between five to 10 queries showing up as kind of the worst offenders. So if you can just go pick one of those as the first week of the year and work on it and improve it, and then do another one by the end of the year, you’ll have been through, let’s say you’ve got some vacation time in there, 45 to 50 queries that you’ve improved the performance on, and your SQL server is going to be running much better at the end of that year. Now. Know what I’d like to suggest on that, and the way we find a lot of these is using the database health monitor, historic monitoring, so you can turn it on. If you don’t have it already, have it running, let it run for a few days, and then you’re able to go in and find, what are the queries that are taking a long time, or what are the queries that have the most weights or the most deadlocking or the most blocking things like that, and figure out how you can improve those. One of the big benefits of doing this, and I think it’s kind of hard sometimes to justify it with some of the bean counters, because it takes a little while in order to get the benefit out of it. But performance tuning can really reduce your overall SQL server costs over time, through both your licensing costs and the need for more hardware, we took an approach like this with one of our managed service clients a while back, and in the first year, we were able to reduce their CPU the number of CPUs needed on their SQL server from 96 to 48 and they simply went to The data center and plucked out the CPU core. After doing that, they were able to reduce their licensing cost by 50% on a monthly basis on that SQL Server. I’m sure what they were paying for that SQL Server on a monthly basis, and what we were able to save there was greater than what it cost to do all the performance tuning.
Shannon Lindsay 16:19
Optimizing storage and indexing strategies. How would I get started on something like that?
Steve Stedman 16:27
Yep. Well, this is one of those that, gosh, we look at this on almost every SQL server that we work on, whether we’re doing a performance assessment or managed services or just keeping the server running. With this, what we want to look at is figuring out, how can we get the most effective IO out of disks? And one of the things that we do a lot of the time with that is separating the transaction logs and the data files onto different drives. Now, not only is this one of Microsoft suggested best practices, but it’s also a way to speed up the overall performance, if you can, if you have one disk that may be overloaded on IO, taking those logs and moving them off to another disk gives you more throughput in order to be able to do everything that needs to be done for a transaction to complete. When a transaction runs on SQL Server, there’s work that has to be done in the data file, and there’s work that has to be done in the log file, and moving those logs to another disk sort of reduces that contention there. The other thing that we really recommend is rebuilding indexes regularly. What we want to do with that is making sure we’ve got a good process to script out index maintenance jobs, we often recommend the whole the Ola Hallengrin Maintenance Solution for doing this, because it’s really a lot better than what’s provided with SQL Server for just general index maintenance. Monitor fragmentation and missing indexes with database health monitor, find out what you need to add for indexes in order to be able to help your system work, as well as making sure that they’re not getting too fragmented. And then, with the combination of faster storage, splitting off your transaction logs and data files on separate drives, you’re going to end up with better IO throughput, and overall, reduce your contention and enhance backup and disaster recovery.
Shannon Lindsay 18:19
That’s something that we’ve talked a few times about. How does someone get started doing that?
Steve Stedman 18:32
Well, before I talk about how to get started on it, let me share a few stories. I mean, 10 years now, I’ve been doing SQL Server consulting, and I’ve got phone calls over the years from somebody that says, I need help. I lost something on my SQL Server. And then we take a look at it, and this is someone I’ve never talked to before, because if it was a regular client, they wouldn’t be in this situation. But they say, Well, I’ve lost something. Let’s go see what we can do get it back. And then we find out, Oh, that was deleted yesterday. Well, why don’t we go grab a backup from before that happened and go pull that data back in that’s now missing? Oh, well, we don’t have any backups. We thought that was running, but we found out the last backup we had was 14 months ago, and now we’re stuck without any backups. So the key to fixing this is not just to turn backups on, but to make sure you test those backups and to make sure that the backup strategy that you have in place meets your recovery time and your recovery point objectives. So that should be something that on a properly running server should be fully automated to be able to run the backups, as well as testing backups on this, I think I’d like to suggest you consider our backup and recovery course. On our backup and recovery course, you’re going to learn how to do all of these things if you don’t know how to do them today, whether it’s backing up, doing full differential and log backups, how to encrypt and compress those backups. Is how to do regular restore drills, or how to do backups to the cloud or off site, things like Azure backups. Part of the benefit of this is you end up with much faster recovery times, and you have data integrity assurance, meaning that if something accidentally gets dropped or lost, and you’ve got good backups, it’s way easier to get it back, and it back, and it might make the difference between whether you get it back or not. So I would recommend checking out our backup and recovery course. It’s available at stedman.us/backup and it’s one of our more popular courses, and probably one of the most important courses that you could take to prepare for any kind of disaster recovery.
Shannon Lindsay 20:40
And some of our most popular podcast episodes too has been the recovery point objective, the time objective, and just anything in regards to backups has been quite a hit.
Steve Stedman 20:57
Yep, and think of it this way. Would you rather explain to your boss, whoever’s up the chain of command that’s going to fire you if things go bad? Would you rather be explaining them today before you’ve had a failure, that you don’t have good backups and we need to fix them? Or would you rather try and explain that after you’ve had a failure and you have to explain we don’t have good backups and you’re never going to get this back. So yeah, one of the things they call, one of the kind of jokes along the way has been they call that where you have a failure and you don’t have good backups, a resume generating event, meaning there’s no way you’re going to fix what you’ve got going on there. So your only option is to work on your resume. So the other thing we say is, you better have a good backup solution or a really good resume. I prefer. I prefer having both.
Shannon Lindsay 21:48
I would say a couple main points to touch back over is scheduling full differential and log backups, encrypt and compress them, perform quarterly restore drills. So basically, get together with your team, have essentially a fake scenario, and walk through the steps of what they would do, and then, you know, a lot of it is just, there’s not really any downside to it, there’s only benefits, so you’ve got faster recovery times. And like you said, data integrity assurance, it makes a big difference.
Steve Stedman 22:29
Oh yeah, for sure, for sure.
Shannon Lindsay 22:32
So next resolution, let’s hop into adopt performance monitoring best practices.
Steve Stedman 22:41
Okay, so this is really important for performance, is to know what’s happening with your SQL Server. And I guess the question I have, I obviously I often ask people when we’re first looking at a server is, do you know what times of the day that you’re having CPU issues? And somebody might respond with, well, it’s slow all the time. Well, that doesn’t necessarily mean it’s a CPU issue. Do you know what time of the day you’re having IO issues? Well, they might say it seems slow all the time. Well, it could be that it’s sometimes it’s slow because of CPU, sometimes it’s slow because of IO, sometimes it’s slow because of the amount of memory on your system or other things like that. So using database health monitor, with our historic wait time monitoring, including things like tracking, blocking queries, tracking deadlocks, and looking at what’s slow, you can use this to establish a baseline and figure out if things are improving or getting worse, and figure out how to spot those issues. We can also set up alerts for things like high CPU, high memory utilization, and figure out how to tune queries with the longest running plans in order to be able to get them to work faster on your system. Now, a big part of this, once you have all this monitoring turned on and you’ve got baselines, you can look and see, and when somebody says, gee, it seems slow today, well, you can go look and say, well, the CPU memory or see, CPU utilization is normal, or the memory utilization is normal, or IO is high.
And why is IO high? Well, you need to go look and figure it out, and that’s where all this monitoring can be so handy when people start or if your system has any kind of performance issues, it helps reduce downtime. It’s good to know about these things before they knock your system out. It really helps you optimize resource usage. I’ve seen too many times where somebody says, gee, our SQL Server is just slow all the time. Let’s go get a bigger, faster server with more memory, more CPU and faster disks. And I’ll never complain about that, other than it increases costs quite a bit. If costs aren’t a concern, you can just keep throwing more hardware. At it, but with a lot of cloud hosted servers like Azure or RDS and things like that, the servers get quite a bit more expensive when you add more resources that way. So figuring out what the baselines are with the monitoring tools so you can go and know, are things getting worse or all that, are they getting better? One of my favorite things on this was working with a client. All of a sudden, their SQL Server got slow, and we were able to track it back to a query that had been deployed in a code update just that morning, figure out what it is, roll back that code change, get the query fixed so that the server performed well after that where, without the monitoring tools, they would have just known that, gee, the server is slow now, and not necessarily been able to figure out why it’s slow. So do what you can to prevent that downtime and optimize the resource usage.
Shannon Lindsay 25:54
Were there any new features that were added in 2025 for scalability?
Steve Stedman 26:02
Yes, Gosh, 2025, just came out, like, a month ago, and we really haven’t had a chance to fully test it yet. I mean, we’ve got it several instances of it running in house, and we’re working with it to make sure database health monitor and things like that work good with it. But there are some features and enhancements to always on availability groups, things like being able to transfer query and plan information between the primary and the second day a secondary in an availability group. The other thing is, there’s a lot of Query Store improvements to help with consistent performance across replicas. Those are some of the things I’ve only read about so far, and I’m looking forward to trying those out as we build our first 2025 availability group. But there are a lot of improvements there that can help with performance in that environment, and to be able to configure readable secondaries for reporting integrated with containers for easy scaling. And the benefits of that is you’re going to get better uptime, better load balancing, and if you need help with any of this, we’re here to help you. We’ve set up in the last year, we’ve set up several availability groups, and we’ve helped quite a few clients with getting to that point of that high availability option with availability groups.
So I just want to remind people, don’t forget to 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. Okay, so one of the things that we’ve seen over the years is that ignoring patches has hurt a lot of people specifically related to things like ransomware. And the sad thing is, the people out there who are building and using ransomware are making so much money that they just keep doing it. Now they are criminals, and they should be prosecuted, and they probably are quite a bit, but a lot of them are getting away with it, unfortunately. So we’ve worked with several clients over the years, and even ones who we didn’t know before, they called us up and said, Hey, we just got hit with a ransomware attack, and our SQL Server has been attacked. And after looking into it, well, we find out that there was some part of their SQL Server, or their web servers, that was perhaps out of date, and had they just been up to date, their server would not have been that point of access that allowed the ransomware to get in. So it’s important to make sure that you’re prepared for ransomware and doing what you can to secure your systems and with good backups. I mentioned our backup class earlier, but I also want to mention our ransomware preparedness class. We have a free class available at our SQL school, Stedman SQL school. That’s our ransomware class, and the URL for that is Stedman.us/ransomware and that is an absolutely free class. It’s a subset of what we covered in our backup and recovery class. And once I was doing it, I just realized I wanted to give that away for free. If we could help one person prevent ransomware, it would be worth it. So check out that free ransomware class. The other thing I’d like to do is encourage listeners. If you can go out and audit your current setup, you can use a tool like database health monitor and let us know if you need help but go out and look and make sure that you’re up to date on your patching, make sure that you’ve got the right performance places and right performance indexes and statistics maintenance jobs and all those kind of things to make sure that your server is going to be in. Good shape. We help clients with this a lot, whether they’re a managed service client and we’re working with them month to month, or whether it’s a one time server assessment, we can come in and help find those problem areas and help get you protected so you’re going to be safer for the long run. So some of the top things we’ve covered today are around security and making sure that you basically go with the least privilege permissions, meaning you’re not giving permissions to everyone, making sure you’re doing encryption everywhere. Make sure you’ve got good patching and isolation. Enable advanced auditing and monitoring, and some of that you can do with database health monitor, leveraging performance tools, optimizing storage and indexing enhanced backup and recovery and disaster recovery and performance monitoring tools and checking out some of the new SQL Server 2025, features for scalability. So that’s kind of the big list there.
Shannon Lindsay 30:57
Yeah, I think that covered everything we chatted about, don’t forget to check out our next episode, which will also be with Mitchell. He’s going to come back and do another guest appearance. The topic, though, will be five things you should never do with SQL Server, so that’ll be an interesting one.
Steve Stedman 31:20
Yes, and we’ve got some great stories to go along with that as to why you should never do those things. Okay, I guess that wraps it up. At this point, I’d say, subscribe to the podcast, rate the podcast, visit Stedman solutions.com for more resources, or to see how we can help. Thanks for watching and have a great day. You.
Steve Stedman 31:56
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.