- Hosts: George Stedman / Mitchell Glasscock
- Topic: 5 Things Every Junior DBA Should Know
- Recording Date: July 2, 2026
- Listen on Spotify!
- Download Database Health Monitor
Stedman SQL Podcast Sn 3 Ep 13 5 Things Every Junior DBA Should Know
In this episode, Mitchell Glasscock and George Stedman discuss the situations they have been faced with starting as Junior DBA’s and gaining knowledge and tips over the years. They explain the top 5 tips and tricks to make sure you don’t make the same mistakes that they have encountered. Check out this last podcast of Database Health Monitor Month!
If you’re seeing these issues in production and need experienced SQL Server specialists, Stedman Solutions’ Managed Services team continuously monitors SQL Servers using Database Health Monitor and helps customers resolve performance, corruption, backup, and availability issues before they become outages, find out how we can help at StedmanSolutions.com
Podcast Transcript
Mitchell Glasscock 00:16
Welcome to the Stedman SQL Server podcast. Today, I’m your host Mitchell Glascock instead of Steve Stedman. We also have George Stedman on the show as well today. Hello, George. Thanks for thanks for having me. I guess. Well, we’re co-hosting today. It’s us. We’re the replacements. So today’s topic is going to be five things every junior DBA should know about SQL Server, and I think that’s a good one for us because coming from the junior position to a more senior standing, getting the fundamentals in place was a really big thing to make that leap, to be able to not only know how to fix things but explain it to other people as a DBA is one of the most important things. I think I’ve realized.
George Stedman 01:13
The other thing is, I think the five things we’re going to go over are also pretty similar to the first five things we look at as a managed service,
Mitchell Glasscock 01:23
Yeah
George Stedman 01:24
And see what the previous junior DBA or DBA missed, or yeah, maybe I mean a lot of these, a lot of our customers don’t even have a DBA, so
Mitchell Glasscock 01:35
yeah, that’s a good point. The not having a DBA, I think we have another podcast coming up where we’ve done it recently, where it’s the accidental DBA guide. That one might be coming up soon. Yeah, and it’s kind of similar. This is going to be a good loop into that situation where a lot of people don’t necessarily seek out the DBA role. A lot of people do seek it out, but some people don’t seek out that DBA role. You just have the opening in the company, and they’re like, “Hey, you know SQL more than anyone else. Why don’t you give it a shot? And these are the things that you can at least start with and set yourself up for more success as you move through that. Yeah, why don’t we just jump into the first of the five things?
George Stedman 02:24
All right. Well, I’ll start. Number one, backups, aka backups mean nothing if you’ve never tested a restore. So not only backups, but also making sure that those restores are functional. Understanding like exactly what the business needs as far as recovery, like if the business expects that you can restore to like a week ago at 3p.m. on a on a Monday, if that’s what the business needs, you can certainly do that. But you got to make sure that you’re able to do that restore, and you gotta make sure that like that you have enough logs, diffs, folds to actually go to that point in time.
Mitchell Glasscock 03:11
Yeah, it’s about knowing. We have plenty of other podcasts that cover this topic too, but the big picture is knowing your company’s RTO, your recovery time objective, and your RPO, your recovery point objective. If they shove you, and we have a story about it. If you get put into the DBA position, and all of a sudden you run into corruption or ransomware in the next week, are you comfortable with your backups to fix it? Like, yeah, it’s not a good situation to be in, and it’s got to be uncomfortable. But you can at least ease the pain a little bit by making sure you have those good backups in place first, right out the gate.
George Stedman 03:56
That’s another thing you just mentioned was the ransomware and or the down like whatever causes, but like with ransomware, you can’t just put those backups on the drive. You got to have those backups securely somewhere where the ransomware can’t affect them. It’s yeah, you got to make sure they’re secure as well as being done.
Mitchell Glasscock 04:19
Yeah, yeah, and I mean, there’s 100 different reasons as to why you would actually need to perform a restore of any of these backups, or whether it’s ran ransomware or corruption, or a machine goes down, you need to restore offsite or something like that. The other side of it is practicing that restore. It’s not just, oh, I have my backups in place, and you can show on paper to whoever is asking you, hey, what’s our backup policy look like? Are we meeting it? And you’re like, oh yeah, it’s great. And then next thing you know, they’re like, oh, can you actually restore it?
George Stedman 04:59
Yeah, I would. Say if you’re starting out as a DBA, you should try to test a backup on each of your databases, like once a quarter, or just practice once a quarter, once a month, just to make sure that you can do it. Because when it comes to crunch time and everyone’s screaming at you to get the database backup, you want to be able to do that without worrying about if it’s going to work or not.
Mitchell Glasscock 05:26
Yeah, each of these come from like I don’t I don’t think we’ve each been in a specific situation, or maybe we have, but they come from situations where one of us or one of our coworkers has been in a situation where they’re like, there’s someone watching over our shoulders because of a like a machine went down, and then all of a sudden you’re in a Teams call with a client, and they’re like, hey, is this done? And it puts the pressure on. So these are let’s reduce the pressure by making sure those backups are in place.
George Stedman 06:04
Yeah, there’s yeah, there’s all kinds of reasons to do restores too. It really depends on your environment. We work with a few different clients or customers, and some of them have really active dev cycles where they need prod restored to dev like all the time, and it’s like, or that they’ll screw up dev, and they need like a restore done, like, ace. I mean, it’s dev, so it’s not as soon as possible. But like, if we want to continue working today, like they want it done today.
Mitchell Glasscock 06:35
Yeah, yeah, for sure. And it ties in. I think one thing we’re also going to point out through the podcast is we’re going to try and tie this into Database Health Monitor as much as possible as well. We George and I are both developers for Database Health Monitor, which was originally created by Steve, and every tool that Steve wrote or put into Database Health Monitor was because he’s been in a situation like we’re explaining, and he wanted to make it easier to fix that situation whenever he was in. So with Database Health Monitor, we have reports like the backup status report to make sure that your backups are happening as expected.
George Stedman 07:21
Yeah, and there’s also there’s a tool in Database Health Monitor to generate the restore chain as well. You have to do some modifications and stuff to make sure it works for how you want to restore. But it can the backup status report can generate those restore chains really quickly, and then you just got to verify that they’re going to work for how you want to do the restore. Because a lot of people don’t just restore over the live data. They’re the broken database. They’ll restore next to it, and then make sure like oh, because if you store over it, you lose all your current data. But if you’re like restoring a backup from like an hour ago, and there was a lot of important production changes over the last hour. You restore next to it, and then move everything that you can over to the new one.
Mitchell Glasscock 08:09
Yeah, yeah, and it’s also important to note practice the restores, and if you do need to restore, make sure you’re restoring in a safe manner that you’re not just going to wipe everything even further. All your practice should be done in a dev server. It’s really easy to say, “Hey, I’ve been practicing this, and then to just accidentally wipe everything. There’s a lot of things that can go wrong when you’re touching a SQL server. So, all of this practice stuff, set up a dev environment, practice in there,
George Stedman 08:41
yeah, and you know SQL or Microsoft actually hands out that dev environment for free as long as you have the hardware to put it on. So utilize it,
Mitchell Glasscock 08:50
yes, for sure. That’s I think day one for both of us when we started with Stedman Solutions. One of the first things we did was just set up local dev environments.
George Stedman 09:03
That was mainly just so we could also test Database Health Monitor to actively code on it.
Mitchell Glasscock 09:09
True, true. Already, I think we’ve hit on backups enough, but trying to think if there’s anything else. I can’t think. I mean, there’s we have a whole another podcast about backups. Go watch that one. I was I was part of that one as well, I believe, and it’s such a deep topic. We don’t want to dive too deep into all of these. So moving on to item number two,
George Stedman 09:32
one thing before we move on, you can’t do a restore when you when it’s needed. That’s a really good way to lose your job as a DBA. If you want job security, knowing how to do a restore is one of the like first things you want on your checklist.
Mitchell Glasscock 09:52
Alrighty, item number two, we have performance blocking and deadlocks. Learn to read what SQL Server is telling you. I think we can kind of jump. We don’t want to, like I said, we don’t want to dive too deep into the topic. But the big picture is these are three separate items that SQL Server will tell you about, and you need to know how to handle each one of them. They go hand in hand, but handling each one of them requires a little bit different process as far as to what to do to fix them.
George Stedman 10:27
So, I’ll start with performance, right? So I like I had what I think one or two classes in college for SQL Server management, and I don’t really think they gave us a real test database. They just kind of said make your own and test the queries and do this and that. And I had a really small database, not a whole lot of rows or whatnot. It’s and it’s not really good practice to do queries on a really tiny database if you’re trying to like become a DBA. Like you need a actual real big test database because one of the first things you realize when you get to a live production system is these tables are ginormous. Sometimes, like some I’ve seen tables with 1000s of columns, and that select star that select star query works real good when you have five columns, but when you have 1000s, a whole lot more data to move over. And there’s, I mean, there’s a whole book to be written on how to tune queries and affect and adjust performance. And college just doesn’t teach you enough of that, so I think one of the first things you need to know is how to find what is impacting your performance, and then use what the internet resources, AI now to, I mean, with you know due diligence, what knowing where your slowness and blocking is half the battle, and then so I guess that ties into blocking.
Mitchell Glasscock 12:09
Yeah, yeah. Well, I kind of wanted to go back to the college discussion. Is we both have slightly different college backgrounds. I went for management information systems, and your networking.
George Stedman 12:25
It was a general network security IT cybersecurity degree. I had like three different names on it.
Mitchell Glasscock 12:33
Gotcha. So slightly different like paths. I had a few more SQL Server courses. I think I went through four overall, and I want to say that MIS is a bit more of a like a DBA type focus, or people that want to be DBAs will often use that degree. But even then, like you said, college didn’t teach me how to performance tune queries, like it didn’t teach me what blocking and deadlocks were, like how to find them and fix them, and the core root of those problems. It’s all it’s all tied into performance, like blocking and deadlocks. But each one of the slightly different, actually getting into production and seeing like, hey, we have people waiting on this software because SQL Server is blocking itself, or two queries are blocking inside of SQL Server. How can we make that faster? And looking at our tool Database Health Monitor at the blocking chain and being like, oh, this query is a big pig. We need to trim it down and either split it up into different transaction or not different transactions, but split it up into different processes. I mean, the million different ways you can take a stab at performance tuning. Yeah,
George Stedman 13:58
that’s the other thing is the you don’t realize how important, like an index is in college, but the day you add an index and it makes a query go from taking an hour to run to 15 seconds, you realize how powerful they can be. But yeah, we have tools in Database Health Monitor for understanding indexes, for finding missing indexes, for finding out-of-date indexes.
Mitchell Glasscock 14:29
Yeah, I mean, there’s tons of different tools just for index performance. We have both the blocking and the deadlocks report as well on an instance level and on the database level, and they’re each going to tell you slightly different things. Like blocking it, it can clear itself eventually. Deadlock SQL Server is going to actually kill one of those processes and declare a winner, so one can get through. And that’s where you have to figure out. I mean, even performance tuning like deadlocks. If your deadlocks are coming from. Two processes that are scheduled to run at the same time. Maybe the performance tuning is just changing the schedule, so it’s not it’s not just butting heads the entire time. So that’s where we go back to Database Health Monitor as a junior DBA. Utilize that tool and see what’s happening behind the scenes in performance before just saying, “Hey, this query’s slow. Let’s rewrite the whole thing. Why is that query slow? What else is it affecting? X, Y, and Z. I mean, we have a whole class on performance tuning. We have podcasts on performance tuning. Jump into those and figure out where to start with that.
George Stedman 15:38
But going back to job security, if you can make your database run better, you’re gonna earn that raise real quick, or hopefully really quickly. If you can make the entire system run quickly in your first few months or a year as a as a new DBA,
Mitchell Glasscock 15:58
yes, yes, definitely greasing the wheels is a great way to make a name for yourself.
George Stedman 16:05
Yeah, I think that’s probably one of the biggest things that gains our customers’ trust, like right away, is when we come in and make their slow system fast. Like it’s, they’re just like, holy cow! Like we didn’t even think about this being possible, and a lot of people when they get to the point where they need to hire a DBA, it’s because they oh the first thing sysadmins will do when they when they have a database that’s running slow is they’ll just throw more resources at it. That only goes so far, and eventually they’re just like, okay, I mean, we can’t throw more resources at it. It’s too expensive. Let’s hire a DBA or contract a DBA to actually figure out why it’s using so much resources.
Mitchell Glasscock 16:53
Yeah, for sure. Speaking of the throwing resources at a at a server just to make it go faster, we kind of covered that in the last podcast we did with the query looting ramp is our performance assessment tool, or one of our performance assessment tools. It’s in the suite. It comes with Database Health Monitor, but it’s a great way to stop throwing resources at a machine and actually test the queries that you need to test. That was a really fun podcast. If you haven’t listened to it, go back. That’s gonna be episode 11, I believe. But it’ll be that’ll be out by the time this one’s out. So give that one a listen. Alrighty. Is there anything else on performance? I’m trying to think. I mean, I could keep talking about each one of these for forever, as far as what we do, what recommendations we can make, but we still got to make it through three more topics.
George Stedman 17:49
Yeah, and I would just say like in the end, understand how what’s available to you. Understand like you if you have the ability to throw more resources at it. It’s a good short-term fix, but you also have to balance that with actually tuning and making sure that everything’s running smoothly. Or sometimes the resources are thrown at the machine poorly. So like maybe they just added a ton of RAM and didn’t even add any CPU, or maybe they added a whole bunch of CPU and the memory is still like really low, or maybe the whole thing’s running on like this really old NAS that’s got spinning disks, and you have flash storage now. So maybe just moving the whole SQL server over to a flash storage would make things better. But yeah, just kind of looking at all the different resources that can affect queries, and understanding like how it all ties into each other is super important. I we could go into it for hours, but it’s just I think it’s one of those things you just got to go play around in your own environment and figure out what needs to improve where?
Mitchell Glasscock 19:01
Yeah, we even said there’s a there’s a million different ways to stab at performance. Like we could pull up 100 different queries and figure out different ways to tune them. So it’s not the overview of this section is not there’s not one right way to do it. It’s just you need to get in there and grease the wheels. You need to make things faster, and you need a tool that’s going to bring the problems to light. So that’s I think the biggest. If I had to summarize point number two, bring light to the performance issues so you can fix them. Alrighty, jumping into number three. Do you want to give this one a go?
George Stedman 19:44
Sure. Security isn’t someone else’s job. The, I mean, sure you can have your security admin manage all the permissions and give you groups and stuff, but when it comes down. To it, the security of your like the database you’re responsible for is your job. It is part of your job. Like sysadmins just don’t have the bandwidth to worry about the different database level permissions, and a lot of the times, at least from what I’ve seen, is like a third party vendor will come in, and your sys. They’re working with your sysadmin. Third-party vendor is like, yeah, just give us sysadmin. That’ll be fine. We’ll be able to get everything done, and that’s where you guys like put your foot down and just say, hey, they probably don’t need to see the whole database instance to work on their to make their application run, and you really just got to tune down and then work with your sysadmin in the in whatever integrations you’re working with to find the right permissions, or even with the different yeah different departments, make sure that no one gets too many permissions because, I mean, with the amount of the amount of like credential leaks and stuff in in the world today, I mean, I feel like I’ve gotten a million different. My password’s been found on such and such database, and it’s. I mean, you can’t stop it. You just gotta keep the keys close to your chest as a DBA.
Mitchell Glasscock 21:26
Yeah, for sure. I mean, there’s so many risks with the nature of our world today, and it’s only getting worse every day. There’s a new way to crack something. Every single day, there’s bad actors springing up everywhere, and the responsibility of it ultimately falls back on the DBA’s shoulders. Like it, it’s scary to say like, hey, you’re responsible for the security of this, but it’s on you to lock it down and keep it safe. And then the other thing is, it’s there’s the legal compliance too. Like there’s if you’re working in healthcare, there’s HIPAA protection. If you’re working with finances, there’s various levels of protection that you do need to go through. Have you completed? I can’t remember what it’s called. There’s certain audits if you’re working with financial information.
George Stedman 22:25
Yeah, it’s but P payment. If you’re working with credit cards and stuff, it’s the payment PCIe. No, P is it? Is it PCIe PCI compliance? It’s the payment card industry. I’m gonna look that up.
Mitchell Glasscock 22:42
And then. breaching it, it comes with not just like hey you need to fix it, but there’s like actual financial risks. Like you can get slapped with fines, you get slapped with tighter compliance regulations if you fail.
George Stedman 23:02
So the big one is if you can’t be compliant with a lot of these, you can’t be properly insured by your insurance company.
Mitchell Glasscock 23:08
Yes, yeah, yeah. So there’s there it goes beyond just like your job security. It moves up the chain of leadership. Like it can fall on the shoulders of those above you if you can’t get into compliance with the security practices that are necessary today, so back to Database Health Monitor, we have a tool that can help you run security compliance checks.
George Stedman 23:35
That just goes through all the SQL best practices that are on every single one of those compliance checklists, and I looked it up. It’s PCI DSS Payment Card Industry Digital Data Security Standard, which is huge because that’s like any time any company that takes a credit card has to follow those to some extent, which is pretty much every business.
Mitchell Glasscock 24:00
So this isn’t one to like scare junior DBAs either. This isn’t like oh you need to do this right now or else everyone’s gonna be suing you for money or you’re gonna lose your job immediately. It’s this is another one of those grace the wheel moments that is like hey I just ran a security audit on our system and we’re not compliant. Bring that to your boss. Bring that to your boss’s boss. Be like, not just here’s the compliance that we’re missing. Here are the steps that I’m going to take to ensure that we are meeting compliance. This isn’t just to boost your role in the world, but it is a great way to show that your role matters,
George Stedman 24:42
and I will say this: the security changes that SQL Server recommends is they’re not they’re a headache. I I’m gonna be honest. They a lot of the times you have to work really hard with all the different teams that access your database. To, because like some of them, it’s just like it’s like force encryption. Like a lot of applications will communicate to SQL Server without encryption. Well, as soon as you turn that setting on, all the integrations break because they have to specify in their connection string that oh, I have to use encryption because it doesn’t it those some of those integrations don’t automatically go for the most secure. Yeah, it’s one of those you do have to work with your whole your whole IT team and to properly implement security and it can take time, but it’s worth it with the amount of ransomware attacks, the amount of like credential harvesting that happens at different organizations, yeah, it’s in the data in the database is pro is for a lot of companies the most important asset the company has, especially a lot of these different like startups and I mean that’s it’s all your customer information right it’s all your it’s all your orders it’s all your inventory. It’s no matter what industry. It’s databases are can be the just the lifeblood, and if you can’t ensure that that’s is secure, it’s just a lot of risk.
Mitchell Glasscock 26:17
Yeah, I think as a as a consumer, it’s always like a bummer to get the notification, like, “Hey, your data was involved in a data breach. And as a DBA, knowing that it’s on our shoulders to help prevent it, it makes it that much more real. I would almost say it’s one of those like it happens in real life scenarios. It’s not fun to deal with. We’ve all we’ve all gone through the training. A lot of breaches are facilitated by human nature, whether it’s phishing attacks or just a simple mis-click on something. But just because someone else does it doesn’t mean you can’t protect it.
George Stedman 27:05
So, all right. Well, now to go to a less serious.
Mitchell Glasscock 27:10
Yeah, I know that one. That one turned in a little heavy, didn’t it?
George Stedman 27:14
Yeah, it did get a little heavy. Yeah, we’ll go to regular maintenance. Maintenance is important. Maintenance includes everything from updates, making sure your SQL Server is nice up to date, making sure your Windows host or I guess Linux hosts now are up to date. It’s that it’s making sure that disk space is free, making sure your statistics are up to date, your indexes are not fragmented. Yeah, there’s all kinds of things that you need to check on a daily, a weekly, a monthly schedule to make sure everything’s going nice and smooth.
Mitchell Glasscock 27:54
Yeah, I think the best starting point as a new DBA, what you can do in this, I’m trying to give a an actionable item. Look at look and see if you have any maintenance plans. If you have database health monitor installed, you can run the quick scan. It will tell you if you have maintenance plans. And if you do have maintenance plans, scrap, get rid of them. Throw them away. Well, don’t do it on production immediately. If you do have maintenance plans, look at how you can replace them with a maintenance tool like Ola Hallengren’s scripts, his index maintenance, the Ola Hallengren index maintenance, the backups, the DBCC checkDB, all of those are a great starting point to get regular maintenance in place.
George Stedman 28:52
I would, yeah, all the Hallengren scripts are the pretty much gold standard of like what the baseline maintenance needs should look like on a SQL server, and there’s tons of stuff outside of that. But I think as far as just the SQL server is concerned, all like those scripts cover everything that should be done, and he does them way better and more efficiently than SQL Server maintenance plans.
Mitchell Glasscock 29:21
Yeah, yeah, we’re a we’re a big proponent of not using SQL Server maintenance plans. They’re clunky and outdated, and they just don’t really integrate well into modern maintenance solutions.
George Stedman 29:37
And I guess going back to number two, which was performance maintenance plans are awful. Don’t use them. But also, the database tuning advisor in SQL Server is also not recommended. Go see if you have any DTA tables and figure out how to replace those with real indexing solutions.
Mitchell Glasscock 29:58
Yes. Yeah. Those. I mean. That’s just extra weight. The we always say that the best way that, or one of the best ways that Microsoft has sold more SQL Server licenses is by recommending DTA indexes, is because they are just heavy and they can increase your costs. So another one that rolls back into performance, though, is index maintenance. The old Hallengren index maintenance. If you haven’t had statistics updated or your indexes are out of date, just as far as organization internal type stuff, this is without getting too deep running the index maintenance can greatly increase server performance across the board, all numbers.
George Stedman 30:49
And it that’s one of those things that it’s a slow bleed. You won’t if you don’t do it right away. It’s not a big issue, but all of a sudden stuff is noticeably slower. Like a year later, that’s when you start to notice. And it yeah, it doesn’t happen overnight, and you don’t realize stuff is slow until someone’s like, “Didn’t this used to take like a second, and now it takes a minute?
Mitchell Glasscock 31:16
Yeah, yeah, for sure. That’s one. It’s a it’s a big one if it’s never been done. If it has, you know, you’re just making sure that you’re using the best solution that you can. And then one we haven’t really talked about is DBCC Check DB. I’ve we’ve seen it before where people just aren’t running it. We get it. Like I understand, it’s a, it’s a. It can be a heavy operation, especially on larger databases. It can take some time, and it will it will eat up resources. But that doesn’t outweigh the cost of knowing whether corruption is in your databases are not like that’s huge. If you if CheckDB hasn’t been ran on your servers and you do find corruption, well, that’s a whole different give us a call.
George Stedman 32:13
Yeah, and that’s one of the things where we go back to like maintenance is really necessary on databases, and DBCC is one of those super important ones. And we recommend that you should try to. I think our recommendation is what nightly to run it, or is it every other? Yeah, nightly. And if you go get Database Health Monitor, the we have reports like CPU by hour and disk latency by hour and all the by hour reports. Those are super helpful for trying to schedule in that maintenance job that everyone says you can’t do. Well, you just go figure out when the database is not being used and schedule it during that time. I mean, usually everyone has like, I mean, except like some companies have you know worldwide act like worldwide databases that are being accessed constantly at all times of the day, but even then, you should make sure that your database isn’t corrupt, and you should have the CPU the resources to be able to run that during the during a slower period.
Mitchell Glasscock 33:27
Well, let’s just say if your company is running a worldwide solution on a single server, there’s probably you might want to look at some other options.
George Stedman 33:42
Well, I didn’t mean a single server. I meant probably availability group or some kind of replication. Makes
Mitchell Glasscock 33:47
it easier if it’s in an AG. Again, we’re getting into those niche topics that I would love to dive into more. But yes, you do need to have if you are running a worldwide solution on a single server, you need to have a conversation of well, we do need to run DBCC at some point because if we have corruption, that’s a big issue.
George Stedman 34:08
Yeah, and we’ve seen some. I feel like we’ve seen it once where someone had DBC DBCC check DB running, and it was it was like once a month, which is better than nothing, but still, that’s a whole month worth of corruption that you could have by the time you notice it.
Mitchell Glasscock 34:28
Yeah, it’s. I don’t like to push it like it. I’ve seen it done once a week or like you said once a month. The gold standard is using Ola Hallengren script once a night. That’s what we recommend. If it’s easier to come back from 24 hours of corruption than it is for seven days of corruption, than it is 30 days of corruption, than it is six months of corruption.
George Stedman 34:57
Yeah, and sure, if you have good backup. Like you can usually, I mean, it’s a pain in the butt, but you can with good backups and the last known good, you can get most of your data back. But sometimes you don’t realize that how deep the corruption is until you’re digging through the tables trying to find stuff.
Mitchell Glasscock 35:20
Yeah, no, it’s one that we can tell stories. We’ve been part of recoveries where the client had corruption, and it was anywhere in a six-month time frame, that that corruption had started and wasn’t found because DVCC hadn’t been ran, and we didn’t have good backups to go off of. So, it’s a very difficult process. It can be done. It’s a very difficult and very time-consuming process to come back from that level of corruption. So, run it once a night.
George Stedman 36:05
Yeah, and I to tie this back to our college didn’t prep us good enough for anything for databases. I think college does a lot of big picture database structure and like query building, but as far as like daily, monthly, weekly maintenance, it they barely touch on it. I think they even recommend using DTA and maintenance plans instead of. I mean, I think I think we had a chapter on maintenance plans when I, in my like one, my first SQL class.
Mitchell Glasscock 36:49
I didn’t even have one. That’s yeah. So that’s more than you got from me. I would agree with it was big picture at writing queries, but it wasn’t actual database maintenance, so
George Stedman 37:02
yeah, and as a DVA, maintenance is what makes your life easier when push comes to shove.
Mitchell Glasscock 37:09
Yes, yeah, for sure. And it, I, I mean, we keep we keep alluding to it. It’s it. This is a big web of intertwined topics. Your maintenance relies on your backups and your maintenance. Relies on performance, and all of this can be enhanced with Database Health Monitor. So we could keep talking on it for forever. As far as you can make it fast, we can make it faster.
George Stedman 37:39
Yeah, you can always make it make slang faster, and I guess brings us to our final topic, which is documentation. Having those checklists that you follow to make sure that everything’s being done properly, having those checklists to do the like restores when you need them, having everything written down so that when you need it, it’s you don’t have to go scrambling to find an answer. Especially because a lot of every database is a little different, and Google won’t always give you the correct answer for your environment.
Mitchell Glasscock 38:23
Yeah, I think there’s. I keep saying I think there’s two sides of the coin. There is documentation that you write yourself, and there’s source control for the stuff that you use. If your server goes down, and you’re you are saving your documentation, like oh, this is how I’m going to restore this backup on the server that just went down, and you need to restore from somewhere else. Can you do it yourself? Did you put your documentation the right place? Where’s your source control for all this stuff at? Be smart about the layout of everything, keep don’t keep paper notes of everything because jobs are oftentimes remote. You get a call when you’re on a work trip.
George Stedman 39:10
Well, even if you are in in in office DBA, when someone calls you at 12 a.m. and they say fix it now, you’re gonna be remoting it. You gotta have those. It can’t be written in a notebook on your desk, which I don’t think anyone really uses paper notes anymore. Well, I’m sure there are people, but
Mitchell Glasscock 39:28
it. I still have sticky notes on my monitors.
George Stedman 39:31
Yeah, I mean that’s fair, but for important documentation, put it somewhere that’s accessible wherever you’re going to be working from. Don’t save it to your desktop on your computer because save it to somewhere on the network, save it somewhere that’s in the cloud securely, of course, because that’s the other thing is you’re you don’t want your documentation is a good way to learn a lot about someone.
Mitchell Glasscock 39:56
Well, it’s always nice to keep a library of your DBA documentation. Your regular maintenance tasks. I mean, companies change and evolve, and someone new comes along, or you move to a new position, and you’re like, hey, these are all the tasks that I’ve been doing for the past three years, and here’s how to do all of them. That’s more than you got on your way into the job. That’s a huge positive for the next person coming in, and if your boss asks you, like, “Hey, what are you doing exactly? Like, how are you doing all of this stuff? Don’t there’s the balance of like, don’t replace yourself. It’s a great way to show like, hey, I know what I’m doing.
George Stedman 40:43
Yeah. The flip side too is writing stuff down, documenting will help you remember it when it’s time to do stuff. So it’s not just in case you forget. It it’s not in case like you’re not there. That’s not who you’re writing documentation for. Writing down the documentation will help you learn it in a way that you can remember it when you need to, or even you’ll remember. Oh, I think I know how like 80% how to do this for store, but I know I documented it. So it’s yeah it’s a great way to just I mean the human brain isn’t perfect
Mitchell Glasscock 41:25
beyond just the tasks that you do yourself too would you agree with writing documentation on what’s on what’s actually like in your database as far as I the biggest one is like what are the jobs that are running on my server a lot of them, you get short names of jobs, and then two years down the line, you’re like, “What is this? Documenting that kind of stuff is a great way to know what it’s actually doing and how important it is.
George Stedman 41:53
That’s another part of documentation is making sure all those jobs have proper names that when someone comes and looks at the database, they’re like, “Okay, what does this job say? Or like, “Like, what does this one do? And it’s like, “Well, you should just have it named in the job name what it does. And they have a description field in that job name in that job too that you can use. And the step has a description field, and using like properly documenting everything that is actually an object in the database is important, especially yeah, especially when you start to get lots and lots and lots of jobs.
Mitchell Glasscock 42:32
Yeah, yeah. We kind of talked about it. You write the documentation, and it’s a great way if you move on to give to someone else as far as the background, it it’s incredibly difficult to come into a server and just have it handed to you. Hey, you’re responsible. You’re the owner of this now, and you don’t know anything about it. You got to hand dig through everything. You gotta, you gotta look at all the maintenance plans if they are there. You gotta see what is going on, like all the baselines. These are all the baselines we’ve been explaining. It’s so much easier to get started if you have documentation to go off of.
George Stedman 43:14
And I, I will say too, almost all of the topics we covered today, if you go and make sure they’re being done, it also allows you to have a vacation, which most DBAs don’t usually ever like they’re not really allowed to because they’re the only one that knows how the database works. So like even if you go on vacation as a DBA, you’re still on call. Where if you have everything documented for like, if this happens, restart this. If this happens, like stop and restart this job. Or like, if you have all the like little things that come up on a daily basis documented, then you can actually take a mind resting vacation when you need to. And we actually offer at Sedman Solutions. We offer the DBA on vacation package, which, if everything’s nice and documented, we can come in and just keep an eye on things while you’re out of the office.
Mitchell Glasscock 44:14
That is, yes, that is true for us going into a documented environment and just providing that coverage for someone else to go on vacation is a huge difference than going in and being like, oh yeah, he went, he left for three weeks, and we don’t know what’s going on here.
George Stedman 44:32
Yeah, I think that’s one of the like things with DBAs is you hear a lot is yeah, you can go on vacation, but can I get your cell phone number, and it’s like also you got to bring your laptop into the office. And I
Mitchell Glasscock 44:47
think we kind of closed up everything in the documentation section. The this one doesn’t really tie into Database Health Monitor as much.
George Stedman 45:00
Documentation does. I will say part of documentation is also historical metrics could be considered documentation, and the historic monitoring it it’s a bit of a stretch. But having the documented metrics of your server over the last month or two, when someone comes and asks, hey, like stuff was slow these three days, being able to go back and be like, “Oh yeah, the database was actually slow those three days. I guess it’s not really documentation, but it’s another good thing that database health monitor helps with.
Mitchell Glasscock 45:34
It’s truly metrics, though. Like you, yeah, you can prove what was going on the server. It’s you’re not fighting through stuff blindly anymore if you do have the historical metrics. So yeah, that’s a good point. It does tie in, but that’s the end of all five of the things the junior DBA should know. I feel like it’s a lot to go over, but it’s all the most important things. Everything that we’ve dealt with the most as DBAs.
George Stedman 46:09
Yeah, I guess the real title of this podcast is the “What College Didn’t Prepare You For, and yeah, I think it going into being a DBA, listening to this stuff and being like, oh yeah, college didn’t cover that. College didn’t cover that. Like knowing what the real world will actually entail is a really useful resource. Yeah,
Mitchell Glasscock 46:33
and it’s there’s a couple important notes to throw on top of all of these. Is as a DBA, like yeah, you probably will make little mistakes here and there. You might get stuck in performance tuning, but practice on your dev server. Practice if you’re going to make changes, make them on the dev server. Have a dev environment. Have a dev environment. Be open and honest about what you’re doing and what your plan is. It’s better to communicate and teach others about what’s going on than it is to sit and be the dungeon DBA that hides all of their secrets and doesn’t let anyone else touch their systems.
George Stedman 47:26
Yeah, that’s another common stereotype that is actually somewhat real. Is the DBAs are usually well, not usually, but oh, they can be because they are dealing with a very different kind of system than the rest of the IT department. There’s not usually a lot of communication that it’s like, oh yeah, you guys won’t understand. I’ll just deal with it,
Mitchell Glasscock 47:52
right? But it’s not it’s not necessary. Like you’re not trying to teach a master’s level course to people who don’t really need to learn or don’t want to learn a master’s level course on database administration, but you can at least say, “Hey, I’m looking into this for performance, and here’s my explanation on it, and I’m improving our maintenance by doing X, Y, and Z, and here are the tangible Historical benefits that we have been seeing because of this. So the communication line, keeping it open. Maybe we’re trying to create new wave DBAs, but we’re putting it all out there in the light. No more dungeon DBAs. And then I guess last one is database health monitor. We’ve been saying it this entire time. We’re both developers for Database Health Monitor. That’s where we started, and every tool in database health monitor has been written because we’ve been in situations where we’re like, “Hey, this would be super handy. We need this as a DBA. This is going to improve our work. This is going to make things faster. We can grease the wheel with this better, you know. So we can also run the Database Health Monitor sponsor video. Thank you to the sponsor of this channel.
Steve Stedman 49:19
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.
George Stedman 50:08
So yeah, I guess takeaway: subscribe, leave a review, go get that seven-day database health monitor trial because you seven days is a with a very powerful tool is can do a lot, and I guess we’ll go with a go out with a quote. I don’t know who it’s from, but every senior DBA was once where you are. The ones who grow grew fast were the ones who asked questions, used the right tools, and wrote things down. Thanks for listening. Hit subscribe, and we’ll see you on the next video.
Steve Stedman 50: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.