- Host: Steve Stedman / Derrick Bovenkamp
- Recording date: February 28, 2025
- Topic: SQL Server analysis in 30 minutes
- Helpful links: Databasehealth.com
Stedman SQL Podcast Sn 2 Ep 8 SQL Server Analysis in 30 Minutes
In this week’s episode of the SQL Server Podcast, Steve and Derrick Bovenkamp, break down the first steps they take when analyzing a SQL Server. In just 30 minutes, they cover key areas like performance bottlenecks, missing indexes, query optimization, and database health checks using tools like Database Health Monitor. Whether you’re troubleshooting issues or optimizing your environment, this episode is packed with expert insights to get you started.
Podcast Transcript
Steve Stedman 00:15
Welcome everyone to this week’s Stedman SQL Server podcast. This is season two, episode eight, and I’m your host, Steve Stedman, and today, Derrick Bovenkamp is joining me as my co host to discuss analyzing SQL servers with database health monitor. If you missed last week’s episode, please check out season two, Episode Seven, where I reviewed and demoed schema drift, a tool that we’ve now shipped and included with database health monitor. Can find those previous episodes of podcast available at stedman.us/podcast YouTube. So welcome everyone to this podcast. This week’s topic is analyzing SQL Server, really the first 30 minute analysis. And welcome Derrick. Let’s take a look at what we’ve got here.
Derrick Bovenkamp 01:05
Okay, great. Thank you.
Steve Stedman 01:09
So one of the things we do quite a bit of, and we can jump over to, like the full screen mode, I think at this point, one of the things we do a lot of is SQL Server Analysis and health assessment and those kind of things. So a lot of the time, we’re being thrown into a new SQL server environment that we may have not ever seen before, and we have to take a look at it and come back with recommendations and findings and things we need to fix and repair and what we can do to make things run better. So you do a lot of that with us, and you want to share with us some of your how you go about doing that.
Derrick Bovenkamp 01:46
Yeah, yeah. So perfect. So the very first thing I do is, I, you know, get, get database health monitor installed on the computer, make sure it’s up to date on the latest version. It’ll tell you if it needs to update, and then you can come down to your database and connect and connect the SQL servers that you want to connect, either with Windows or SQL authentication. And then also, just to prep, I also always open up Management Studio get connected. Is there as well? Just so I’m ready to go back and forth between Management Studio and database health. But we’ve got our multi test SQL server here that has lots of SQL Server instances on it, connected to two of the instances. First thing that I want to show you guys is, on this home screen here, you just get a little bit of a basic info of what’s going on, what the uptime is, when the last time the this is when the SQL service started. This is not when the computer rebooted. That’s why you see the services started a couple minutes after each other. We see the addition, the install date, the version, server, memory, available queries, and also we’ve got SQL Server Update available. But let me go ahead and go into 2022.
Steve Stedman 03:03
Oh, no. Shame on me. I put you into a demo where I should have done updates first.
Derrick Bovenkamp 03:06
Yeah, I should have done the updates, but that’s okay. Absolute first thing before I do anything is, you know, I see what version that they’re on, and then I come into CheckDB. So let’s go into CheckDB and say, Hey, this actually looks really good. Everything’s green. If we wanted to get a CheckDB on Temp DB, we could double click on it and say, CheckDB now. Hey, that’s green. Okay, I can refresh, and we’re good to go. So before I do anything on a SQL Server that I don’t know, I’m not friends with that SQL Server. I always do CheckDB make sure everything’s CheckDB sometimes you come to a server where they haven’t scheduled check DVDs before, so check TVs never ran, or it’s been months since it’s been ran. So I always come in here and make sure it’s been run recently. I look at today, I’m like, Okay, well, it’s the 28th today, and these all ran last night or this morning. So from a from a database integrity position, we should be good.
Steve Stedman 04:08
And, you know, that’s a really good point on that too, because that’s one of those things that I actually build into the contract when we’re doing an assessment like that, is that one of the very first things we will do if they have not done it is run CheckDB, just to make sure that we have a solid environment that we’re working in before we go start doing other things.
Derrick Bovenkamp 04:26
So started with the CheckDB. Next thing that I will do is I’ll either go to the quick scan report or I will take a look at the air log. So let’s do the air log first. And reason why I like to open up the air log is just to see if there’s anything crazy going on in here. So I could come in here. I say, Oh, check. DB was run. Oh, look, I failed to log in a few minutes ago. But I. Like to just come here and scroll through this a little bit and just to see looks like we we’ve got a trace flag that we can disable there that won’t show all those backups, but I just like taking a quick look and see like is there anything in here that I need to address right away? Now, our quick scan report will also show us things out of the air log, but I think it’s good to just just take a quick scroll, yeah, not seeing anything here besides the backups. Oh, we’ve got some SQL agent. Look like it failed to log in to a query training database. But,
Steve Stedman 05:38
oh, I can explain that one. We were doing a training where we had to delete the database. The agent was still trying to do something with it after I deleted it.
Derrick Bovenkamp 05:46
Oh, okay, perfect. So we got an excuse for that. But I think the important thing here is there’s nothing in here that’s like, you know, you open this up and there’s 100 errors in a row or anything like that. So let’s come back and let’s go to the quick scan.
Steve Stedman 06:08
So while that’s loading a little bit of background in the Quick Scan, and this is report that I built early on in database, health monitor, and it probably had 20 or 30 checks on it initially that went out and checked a bunch of things that were sort of common practices and stuff like that. But over time, over the last 14 years, database health monitor, this has grown to over 200 checks of different things that have been problems we’ve found over the years. And what are you seeing here? Derrick, yeah,
Derrick Bovenkamp 06:35
Well, it looks like first thing we have is pretty common with new SQL Server installs, and that is, we’re not setting a max memory setting for SQL Server, so it’s got the default value, which is basically unlimited RAM. Server only has 32 gigs of RAM. So normally we would go through there and there’s a there’s a rule of thumb that we use to set that to leave Windows or other applications on the server a little bit of RAM, but and then this server is also because there’s multiple instances on it, you’d want to be really careful with that setting. But, yeah, on
Steve Stedman 07:14
a production system that’s got a lot of load and maybe not enough RAM, if you don’t set that, what can happen?
Derrick Bovenkamp 07:19
Well, SQL will just sit and use all the RAM, and then windows and any other applications on the server won’t have any RAM, or they’ll be fighting over the RAM. So it’s always smart to go in there and set it so we give windows at least a little bit of RAM that it always has to itself. And then SQL Server will go right up to that Max and stop and not use any more room.
Steve Stedman 07:43
Okay, great.
Derrick Bovenkamp 07:45
Next thing, it looks like we have here, and I’m glad that our test server actually has stuff that we could look at. It looks like we’re not using compressed backups. So usually what happens there is, we’ve got backups in place, but we haven’t set the default backup setting to do compressed backup, so we’ll, we’ll just kind of take a mental note of that and scroll down. Next ones are all around alerting. So there’s a default set of alerts that we like to set up on every SQL Server that’s got air, air, 823 824 825, and then alert level 19, 225, these are generally to the type of things that you want to know if they’re happening and you want to know right away. You don’t want to find out after the fact, after your database has corrupted, that you’ve been having errors 823, through 825, happening for a long time. So we’ll go into every server we work on. We’ll set up alerts to email us anytime this happened. The next thing that we’ll do is we’ll definitely set up alerts for all of our SQL agent jobs, because if these are running and failing, and we don’t know, you know that can be a problem, right? What if you are running CheckDB every day, but you don’t have something in there to tell you that it’s failed? Oh, yeah, you never stop database or your backups aren’t running, and you don’t know why, or your backups are running, but they’re failing because the backup disk is full, yeah, and those areas CheckDB and backups.
Steve Stedman 09:24
I mean, those are the two areas of jobs that when we get a call to do a corrupt database repair, it’s really pretty amazing how many people have both of those failing or not notifying when something happens. So taking care of those can make a big difference for future health of your SQL Server.
Derrick Bovenkamp 09:45
Next thing is, let’s just scroll down a little bit more. This is telling us that we don’t have any operators configured, so that means we would have to set up an operator before we did notification on agent jobs. I. Um, another message here that it looks like one of our backups isn’t using checksum. So we would want to look at that and make sure we’re using checksum. Steve, you want to talk about the remote, dedicated admin connection.
Steve Stedman 10:15
SQL Server can get stuck in a situation where, if something’s jammed up and it’s just getting slammed with lots and lots of connections, that all of the connections to the SQL Server can be in use, basically, almost looks like a denial of service attack, but it might not be nefarious. It might just be that something’s bogged down and all those connections get used up. What the remote DAC, or dedicated admin connection does is it allows you to connect in on a separate port and have one dedicated connection that even though all of those other connections are filled up, you have one way you can connect in order to go in and figure out what’s wrong or terminate the other connections. And it’s one of those things that most people don’t turn it on, but you get to a point one day where it gets all jammed up, and when you need it, it’s too late to turn it off. Turn it on at that point. So it’s sort of like buying a smoke alarm for your house after you already had a fire. Well, yeah, when you need to put it in, you need to turn on ahead of time if you ever plan to use it. And it’s in the few occasions that I’ve had to use it, it is really handy. It doesn’t really open up any security issues or anything, because it still has the same password, authentication and verification, all that kind of stuff, and only administrators can connect in on that extra port. So definitely, one of those things we recommend people doing.
Derrick Bovenkamp 11:40
Yeah, next one is actually one of mine. Ones that I always like to turn on right away is this is telling us that error log retention is minimal, and that’s the default. And what can happen is, if somebody has a problem with their SQL Server, and they reboot it five or six times, every time you restart SQL, it rotates the air log, and if you only have it, you reboot it five or six times, and all of a sudden you can’t go back and look at what the errors were saying before you started rebooting all those times. So I always go in right away, and I I just like setting this to 30 so we have the last 30 logs. So this is, this is a really important one to change. And again, it’s one of those things where you don’t need to go back and look at the old air log until you need to. So it’s good to have the ground. Then we’re also seeing another thing about disaster you know, and we’ve got types here, which is important. So this is about disaster recovery. And this is like, Hey, you’re saving backups to the same drive as the databases, and you might lose both of them at the same time. Now, again, with this test server, do we care, not really, but in a production server? Yes, we would really care when we see this message, yeah,
Steve Stedman 12:51
You know, on this test server, if it completely failed in the head, and rebuild it from scratch. I’d burn a few hours to do that, but there would be nothing permanently lost of any value there, it would be a pain. But unlike a real production server, yeah, so we’ve kind of taken a few shortcuts here on this test server, but it’s interesting, because that allows us to show some of the common things that we see in real production environments as well.
Derrick Bovenkamp 13:18
And then here’s where I was talking about where we are actually seeing some errors in the air log. So if sometimes you’ll see stuff in the air log that’ll show up here. And is it actually looking for the word error? I think it is. That’s why we’re seeing Yeah, I think it’s doing a wild card search on the word Yeah. It says there’s zero errors. Well, of course it’s catching it, so maybe I need to make that a little bit smarter.
Derrick Bovenkamp 13:41
Yeah, that’s okay. Now logs flooded with a log backed up and database backed up. So this is one of my Well, it’s probably my favorite trace flag, because it’s the one that I always say. This is where we go in and we turn on that the database SQL Server will not put in successful backup messages in the air log. It still, you know, writes them to the backup log, but not in the air log. So then, that way, when we’re looking through the air log, like you saw me when I just did, is we don’t see all these, oh, sequels, backed up, back up, back up, backed up, backed up. You’ll still see it in there if it fails to back up, but you’re not going to see successful backup messages in the air log. So that’s another one that I always like to set.
Steve Stedman 14:30
Yeah, you know, honestly, that is one of my biggest annoyances. Like, if somebody says we had a failure of some kind, and I need to go look at the error log, and there’s like, 10,000 messages in the error log that, I’ll say something was successfully backed up. And they bury the real error, and you make it hard to find, then you’re looking for the needle in the haystack.
Derrick Bovenkamp 14:46
Looks like we’ve got some orphan users. So this is, this is a cool thing. I mean, they don’t really hurt anything, but it’s a cleanup thing. So if we’ve got. Database. If we’ve got users in the databases that they don’t exist on the SQL Server, we can go and say, Oh, maybe this database was moved or maybe that user was deleted. It needs to be deleted out of the database so it and again, it gets back to the type. It’s just a general, general cleanup. Looks like we also have somebody has been bad and has been putting tables in the master database. So again, this is a great example that we can go and show. Hey, you know, these are in the master database. You really don’t want to be using the master database for user tables.
Steve Stedman 15:36
Oh, you know what? That might have been part of my schema drift demo where I was comparing databases and might have done that, yeah, okay, it’s a test database.
Steve Stedman 15:48
So we get a little bit more wild on it than we would on a real SQL Server, on a production server.
Derrick Bovenkamp 15:52
Yeah, Steve, this is a new this is a newer check. Do you want to talk about this one? This is in the last, oh, I would say, three months we added this.
Steve Stedman 16:00
Yeah. So what this one? It’s about SQL Server Agent jobs that are exist but don’t actually have a schedule associated with that. And if you go and look in SQL Server Management Studio and expand your SQL Server Agent and look at the jobs, you can see that, hey, I’ve got a bunch of jobs there, but there’s no there’s nothing that shows here, obviously, which jobs are scheduled or which jobs are not scheduled. So like the one Derrick just opened there, it looks like it’s a job that’s running, but there’s no schedule associated with it. So this is just a way of kind of flagging and saying, hey, you know you’ve got this job here that doesn’t have a schedule with it. Is that a problem? And what I like to do is I like to go in and actually disable the job so it shows little red X on it once. If it’s a job that I do not plan to be running, just right click and disable. And then it shows up a little x there. So you know, it’s not supposed to be running. And to eliminate this, we either disable them that way, or if it’s something that we thought should have been running, we go in and put a schedule on it to run on specific time. And this came from specific customer environment where, yeah, they had a bunch of jobs set up, they said they were running, and then we went looked, and it’s like, oh yeah, the jobs are there, but they’re not running. They thought they were but they’re certainly not. So, yeah.
Derrick Bovenkamp 17:21
So I think that is that is a great check to have. Scrolling down a little bit further, looks like we’ve got performance notification. Here is we’ve got quite a few untrusted form keys in some of these databases. Yeah.
Steve Stedman 17:36
And that’s an interesting one, because if these are on databases that you’ve built, or your company has built, then you’re probably should be aware of those and go and understand what’s going on with it. If this is on a vendor supply database, and you’re seeing that untrusted foreign key, you probably don’t want to go be changed and go and change that one. So it really depends on whose database it is or who created it, that the importance of that untrusted foreign key, but it can make a performance difference. So yeah,
Derrick Bovenkamp 18:03
The next two are also performance related. Cost threshold for parallelism. This is, this is how much a query has to cost before SQL Server parallelizes it. And this is set way back from the 1990s so we pretty much across the board, go in and set this to 5010, times what it is now, and instead of five, and that can help improve performance a little bit, because you’re not wasting time to parallelize. You’re keeping it single threaded. Next one optimize for ad hoc workloads. You want to talk about that one.
Steve Stedman 18:44
Yeah, so what this does? It’s a setting that changes how queries are being how the compiled plan of a query is being kept around, meaning the difference is an ad hoc group. An ad hoc query is a query that’s been run just once, like something you might have typed in SQL Server Management. Studio, whereas a non ad hoc query is one that might be being run from an application or a code and being run all the time. And what the Optimize for ad hoc workloads does? It just changes how those plans get cached, and then says, don’t actually keep a cache of the whole plan around until the query has been run twice. So if, for those one time truly ad hoc queries that you might be running through Management Studio, it’s not going to keep a plan around for those because you don’t really need the plan there if you’re not going to be reusing it. But for those queries that are being run all day, every day, from your application or whatever it’s using the SQL Server, those plans will be cached, and it will save more of that memory that’s associated with the plan cache to be used by real queries, like real queries. Maybe that’s not the right term, but applicants and queries, rather than stuff that you’re running one off here and there and Management Studio or some other tool.
Derrick Bovenkamp 19:53
And we can keep going through these, but I don’t want to get you know too. Deep in this, I want to show you some other stuff, you know, exciting that we check in database health monitor so there’s more stuff with performance. Then we get down to security. There’s some security things. There was, you know, our servers out of date. The one thing that I did want to point out is, remember when we were talking earlier about how we saw stuff that wasn’t compressed, backups that were not compressed. So here’s this right here, telling us, like, Hey, you should turn on your default backup compression. Here’s our more than one instance installed on SQL Server. So all good notifications here in the Quick Scan. It’s kind of our bread and butter. We keep going back to the Quick Scan until we get it cleaned up. But next thing that I want to show you everybody is we’ve got these related reports right here, and this is telling us, like, Hey, I just actually can tell you they’re related. Because there’s our CheckDB, there’s our error log, we can also go look at backup status. So like, let’s click on that one. So let’s go back up status, see what that says. Okay, here’s another thing, not so much performance related, but important to know about is, you know, we can look at our databases. We can see what recovery model they’re in. We can see when the last full was, the full size, the differential, the log in where the last full was. So this is another one I look at pretty early on in any SQL Server, because I want to see where their backups are going. If the backups are happening. Another thing that Steve, you and I see a lot is backups are happening, but databases are in full recovery model, and it’s only sometimes getting log backups every hour. Or, you know, sometimes you and I have seen ones where they’re never getting logged back ups, or they’re having every six hours. So important, another to check into.
Steve Stedman 21:57
Yeah. Another thing we see there is if something’s in simple recovery model, and they are running log backups, but log backups Skip, skip, all the databases that have simple recovery model, and they think they’re getting log backups, but they’re not actually getting them. So there’s a lot there. And this report, I’ve really been amazed at how many surprises we found when we come to this report over time, where you talk to someone and they’re convinced they’ve got good backups. And we look at here, I look at this, and we find out that things are not really as they had thought they would be, yes, and then I want to come back to the main screen here.
Derrick Bovenkamp 22:32
We’ve got a little bit more info on the server config, how many CPUs? How many logical CPUs? Again, back to the version. So just, just some basic info here. Then we get down to logins. This is, this is important to know, because you’ve got, you know how many logins are on the SQL Server. And we can, we can cook on these, like, how many sys admins do we have? And then you know how many, specifically, Windows logins that we have. So this is a great one to look at, especially on the security side, that you’re making sure that all the logins that you have on the SQL Server are expected to be there.
Steve Stedman 23:19
It’s been a while since I’ve seen this, but one of the things that’s always disturbing is when you look there, you realize the only login, besides the system ones, is SA, and that’s the way of knowing that. Well, if that’s your only login, then everybody’s using the same essay.
Steve Stedman 23:35
Everybody’s using sa, security best practice, by any means. Yeah.
Derrick Bovenkamp 23:38
And I think, you know, Steve, have we shown one on setting up database health? Maybe we should show that as a future topic if you haven’t done one yet.
Steve Stedman 23:48
Yeah, I don’t think we’ve shown that necessarily. But really the I can talk about that just for a quick second.
Derrick Bovenkamp 23:54
Yeah, if you want to talk about what you would see here, if it’s not set up in this historic weight area, yeah.
Steve Stedman 24:00
That top chart there that says historic weights on it, if you have not yet configured database health monitor on this server, when you come in, it’ll say database health monitor is not configured. Click here to configure it. Would you like to create a database and create some SQL Server Agent jobs that will run and track a lot of this information that we’re seeing over time, and that creates a really small database. And then think four or five SQL Server Agent jobs now that track a bunch of stuff over time, so we can have that for later diagnostics. And for instance, here we can go and see that on February 25 there was something going on related to weights. And we can probably double click on that top one there and see, oh, yeah, a lot. Yeah, it’s a lock. And if you don’t know what that lock means, just double click on that lock down below there, and you’ll find out, okay, this is a description of what that actually is. What it means if your query up top is really long. And cancel that one and double click on the query. Just double click there and open it up. So if you got a really long story procedure there, you can make it bigger and see the whole thing. Yeah. So this is perhaps, I think, one of one of the more useful tools in finding out, kind of over time, how things are trending with things that are stuck waiting on different things on the SQL Server.
Derrick Bovenkamp 25:23
That’s an important one, and it also fills into our next topic about some of the other reports. So I will go over to CPU load by hour. And again, this one, you need to have database health installed and monitoring to get this information. So this is not one that you look at, you know, 10 minutes after you install it. It’s one that you look at a couple days after you installed it. But if I click show more and show more and show more, I can go back, and you can see this is all the way back to one. So basically four weeks. And, you know, actually, this would be a good question. It’d be like, hey, what changed? What changed on two, five or two, six, that doubled our CPU load. Now 11% is almost nothing, so that’s not really anything to be concerned about, but it does let you say, hey, something changed. Or, maybe even better, you see the opposite as your 50 and 60% CPU load. And you address everything on those quick scan reports, and then you drop to 30% CPU load. So this will let you see a little bit over time, or somebody’s complaining, everything’s slow. You come in here and you see this pegged at, you know, 70s, 80s, 90s, and you’ll see it get red and, sorry, orange and red as the CPU load increases, right now it’s this, like bluish teal color, which means everything’s fine. Yep, we can also go look at the CPU load by database, which is going to break down a little bit about what database is using. Now, this is a test server, so database health history is, is the hardest one in the in the box, versus you’re going to have on a production server, you’ll probably see their main production database, or databases be up there, but it usually you’ll know what you’re going to see here, but it gives you a little bit more info, we can go right to our memory report from here and see what’s using RAM, how much RAM is available, plan cash, and we can see what, what’s using RAM in here, which is great. Steve, what other reports do you like to look at right away?
Steve Stedman 27:43
Well, there’s the new one that came out in the last update, which is the deadlock report. It’s right in the middle of the gray buttons, right? Yes, yeah, deadlocks. There we go. So all the deadlocks that have occurred on this server since we started tracking, and then you’ve got some links up top to deadlocks by hour and deadlocks by database. That will give you a little bit more so we can see that, oh yeah, deadlocks are not occurring all the time. There was just a couple days here that we had a lot of deadlocks on, probably testing Exactly, exactly.
Derrick Bovenkamp 28:16
Another cool one is we can go to blocking queries, and this is going to show us what’s blocking right now. So there’s a lot of times where if there’s blocking going on, or if there’s a real performance issue going on, I’ll go back and forth between what is active, and this is going to show me what’s active this second, I can refresh it, see what’s active. I can go back to blocking queries. I could go back to what is active, blocking by hours. Another good one. Well, you can see two, five. There is a lot of blocking, but this will you know that there’s a lot well, even disk latency. That’s a newer one as well, by hour. This is in also in the last couple of months, where a lot of times we used to have to go to the Server console, you know, if it was a virtual server, we’d have to go to the host and go look at what latency was. But now we’ve got some disk latency right in here, which is nice and easy to see.
Steve Stedman 29:12
And with these tools, this is where we can come back and say, We think your server may be having issues related to CPU or maybe having issues related to IO, or you’ve got plenty of CPU and plenty of IO, but you’re having blocking that’s on, that’s not related to the CPU or IO and things like that. So with all of these tools, we can really get a comprehensive view of what’s happening with that SQL Server.
Derrick Bovenkamp 29:37
Yeah, and we’re just scratching the surface here. You know this is the first 20 or 30 minutes, but I think it gives you, gives you all a good idea of some of the basic things that we check on SQL Servers when we first touch them. And I think that’s really that we look at the CPU, we look at the Quick Scan, we look at. CheckDB, the backups, those are the things that we hit right away. And if it’s an active issue, you know, sometimes we’re on a new customer system, and they’re calling us because they’re in a performance issue, and that’s where we’re going to go straight for that, what is active, or the blocking, blocking report?
Steve Stedman 30:14
Yep, absolutely. So part of what we talked about on this was, this was what we do in that first 30 minutes, and we are hitting right about that 30 minute recording time here. So anything you want to add before we wrap it up, Derrick.
Derrick Bovenkamp 30:30
No, I think this is a pretty good, pretty good first start, and I’m sure we’ll have more sessions in the future about digging into some of the database level reports, but this was your main, what I would call, instance, level reports of things that we go and check.
Steve Stedman 30:48
all right, great. Well, I guess at this point, I want to thank you for joining us today, Derrick, and your insight on this is always valuable. And I want to thank all of our listeners for watching or listening today. We hope you’ve enjoyed this episode. We’d like to invite you to join us next week for episode nine, where we show some of those neat new features that just released in database, health, monitor. You did get a preview of a couple of them that Gary clicked on here today, but you’ll see full details those in the next episode. If you want to watch more episodes or take a look at what we’ve done here. Just go check out our YouTube podcast channel, where this episode and all of our previous episodes are listed, and that’s available at stedman.us/podcast YouTube, and this is season two, episode eight, or our 20th episode since we started with our podcast. So thanks everyone for watching. Have a great day, and thanks for being here.
Steve Stedman 32:00
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.