While the ability to shrink data files is available in SSMS, the conventional wisdom is don’t do it.  I was extremely curious when I read an email from our guest suggesting the opposite.  In this episode we explain the ‘real world’ and discuss why you might consider shrinking files and the how it will affect you.  Nigel has a great sense of humor and I know you will enjoy today’s episode.

Episode Quotes

“We have a set percentage that we need to leave free on a disc, and that causes problems. I do tend to find that discs can be a bit like teenager’s bedrooms in that if there’s space available, it will be filled.”

“It’s an awful process. I think that’s why it’s become such a controversial or taboo subject, whereas, I live in the real world and from time to time, I do have to do this process.”

“I’ve been in situations whereby you’ve got systems that cannot be expanded for various reasons, and it’s a bit like doing a three-points turn with a petrol tanker in the children’s playground. You’re very limited on your maneuverability and you’ve got to be incredibly careful, but sometimes you do have to do these things.”

Listen to Learn

00:40  Intro
01:27  SQL Server in the News
02:11  Intro to the guest and topic
04:30  Compression might make sense depending on the amount of space you’ll free up
08:31  Do you compress if the growth is temporary?
10:20  What is the tipping point to determine if you need to reclaim space?
13:19  Recovering from the shrink database process
16:07  You set parameters, warnings and limitations and then proceed with caution
18:11  There’s more than one way to shrink
21:13  Cleanup and rebuild, then the shrinkfile will go more quickly
22:57  There are circumstances where shrinking may be necessary and we should learn more
24:21  Shrinking the transaction log
27:14  SQL Family Questions
34:28  Closing Thoughts

About Nigel Foulkes-Nock

Nigel Foulkes-Nock is a SQL Server DBA who supports and embraces technology, recognizing the need to provide true Business value while maintaining technical stability.

He enjoys bringing order out of chaos and embraces the power of education through self-learning and helping others.

Based in (old) South Wales, Nigel is a regular attendee at the Cardiff MSFT Stack and also the SQLBristol User Groups.

Nigel’s blog: https://nigelDBA.com. He can be reached on Twitter using @nigelDBA.

Carlos:             Compañeros, welcome back to the SQL Trail. This is Episode 133. It’s good to be with you again. I apologize for missing last week. Things got busy and I wasn’t able to get the episode out, but you are in for a treat today. Today we have Nigel Foulkes-Nock. He is out of South Wales and was a delight to chat with, so I think you’re in for an interesting conversation. Ultimately, we’re talking about shrinking files. This is one of those that’s interesting because we’ve talked about just not doing it on this program and this is certainly not an endorsement, so please don’t, by any stretch of the imagination say that, “oh, hey,” but I think Nigel does present some interesting use cases. We talk about the pros and cons of it, anyway, you’ll see in the conversation. I think you’re in for a treat today.

So, for a little SQL Server in the News. The big news this week is that SentryOne is acquiring Pragmatic Works. I know that may not affect most of you, and I certainly am not a SentryOne user, but I thought it was interesting just to start seeing some consolidation in the market. Pragmatic Works has been out of Florida. Many of you may know some of the people who have worked there. They have been doing quite a few things with the SSIS integration, of course, then with the consulting, so I just thought it was interesting to see this development. It will be interesting to see what the future of SentryOne is. They get to have another tool in their belt, so it’ll be interesting to see how that plays out.

The episode notes for today’s episode is going to be at sqldatapartners.com/shrink or sqldatapartners.com/133. Let’s go ahead and get into the episode today with Nigel.

 

Carlos:             Nigel, welcome to the program!

Nigel:              Thank you for having me.

Carlos:             It’s great. It’s always fun when I can get a listener onto the program and they’ve shared some ideas with me, we get talking and then I’m like, “hey, you know what, you should come on and do this.” So, thanks for taking the plunge and coming with us.

Nigel:              No problem.

Carlos:             Today, our topic is an anti-topic. We hear a lot of information out on the internet. We’ve talked about it on this program: don’t shrink your database files. That’s what we’re going to talk about today. Nigel came to me and he’s like, “well, you know what, every once in a while, you do need to shrink” and there’s a time and a place for it. That’s what we want to be talking about today. It is interesting, and I think we should probably set some parameters here. When we talk about databases, there’s two components in play here. One is the data file, and then we have the log file. We’re not talking about shrinking your log files. That’s kind of a tried and true practice, everybody can do that, particularly if your transaction log backups fail for any length of time, that will be something that everybody will probably have to do at some point in their lives. We’re not talking about that.

Nigel:              No, we’re not. We’re talking specifically about the data files and I would say it’s quite a controversial topic. It’s something that I’ve had to do from time to time. The general reasons behind it are to do with the implementation of things such as data compression, which is going to give you massive space reduction. You have a file that is extremely large and you need to shrink that down. Or another example is if there’s been, I’d like to call it some form of developer or implementation incident which has caused a data file to grow massively. So, you do get times when you need to shrink the data files.

Carlos:             Let’s take that first example. Compression, and maybe the parameters around under which you’d consider shrinking those data files, because you’re right, we’ve talked about it not being a good thing. It does some different things to the database, but here you’re saying, depending on the amount of space that I’ve actually freed up, it might make sense. When you talked about your data compression example, what kind of space are we talking about? How big was the database and then how much space did you save through compression?

Nigel:              We’re talking there about having databases of 500GB to a terabyte and under certain circumstances, I’ve seen those, you can literally drop the zero off the ends, so you are shrinking by 90%. I should have mentioned at the beginning; the general suggestion is leave that space there. Leave that space there for natural data growth and the data is going to grow into the size of the file. But how long are you going to wait for that to happen? An instant where you’re shrinking your data by, perhaps 85, 90%, you could be looking at 10 years, 20 years. My experience with data compression has been really positive. But that’s only good if you’re actually getting the space back.

Carlos:             Sure. I guess I am curious, does it have to do with the number of databases in the environment, as well? Because I think the push-back would be, “yeah, great, 500GB, I’m not saying it’s nothing, but eh, is it worth the extra cost?” But if you tell me, “okay, I’ve got 5 or 10 of them and I’m managing lots of databases, 100, whatever the number is. Okay, maybe that adds up.” What was your experience there? How many databases are we talking about that were actually used compression?

Nigel:              We’re only look at a couple of databases in my particular area. But the world that I live in means that 500GB to a terabyte is a fair amount of data. At the time, that data is also replicated onto another system, backed up, okay, the backup is compressed as well. But you’re talking about a fair amount of space and to leave that filled is going to cause nightmares or headaches, indeed, for the SAN administration. We have a set percentage that we need to leave free on a disc, and that causes problems. More so on the second example where something suddenly grows, then I do tend to find that discs can be a bit like teenager’s bedrooms in that if there’s space available, it will be filled. That’s something that I’m constantly working against, on both counts.

Carlos:             I can see that. Maybe you don’t have the resources to invest in additional disc space, so you want to be cognizant. Before we jump into the extra, the developer creates a second table or something, staying on with the compression theme there. Why not just move to another database? Assuming you’ve done some compression testing in the test environment, you’re happy with everything the way that it’s turned out. Why not just go from database A to compressed database and then drop the bigger database once you’ve done the migration?

Nigel:              That’s certainly an option. That would depend on what sort of change window that you’ve got available, how transient that data is and the speed of the updates to that particular data, and again, the amount of space in general and the environments that you have available to do that in.

Carlos:             Yeah, so your situation will vary. Your mileage is going to vary depending on your circumstance. That’s fair enough. Now, let’s get into the other example that you mentioned. That is, all of a sudden, my data grows, but it’s not growth that’s going to be sticking around.

Nigel:              That does happen and I realize that there’s all sorts of things at play here, to do with who’s doing the implementation, what system that you’re on. At the end of the day, you do see things where people are either have an incident that occurs that causes a lot more data to go in there. Or one that I have seen as well is to do with when people are doing deployments, using deployment tools. Look at the difference between one environment and another. We’ve seen a lovely one whereby if a table is compressed, even a compressed table in a production environment and uncompressed on development, then the implementation tool will try to make them the same. By doing that, you suddenly get a massive expansion of data.

Carlos:             Interesting, the table will actually uncompress, basically?

Nigel:              Oh yes, that was great.

Carlos:             Yeah, that sounds like fun. Okay, interesting. So that’s one scenario. Another one that I think a lot of people can also sympathize with or connect with is they want to take a backup of a table. “Hey, I’m about to make this change, let me SELECT * into TABLE_SAVE.” Then all of a sudden, I’ve this extra data. I’m not keeping that around. I only want to keep it around for a short time.

Nigel:              They do smile as they tell you that they dropped the table afterwards. But of course, by that point, your database is enormous. It may have hit limits on the size of the drive. All sorts of things could have happened.

Carlos:             Right. One of the great things, and we actually mentioned this before I clicked the recording button, but one of the things that I really enjoy about the podcast is being able to get different experiences from people. You talk about this table size. What is it that you were then looking at? With compression, we mentioned, “oh, I’m going to save 90% of my space.” What’s the tipping point if I have extra tables before you decide, “okay, hey, maybe I need to reclaim some of that space”?

Nigel:              I tend to like to keep a bit of space in a database, anyway, so I’d like to see between 10 to 15, possibly 20% available so you’ve not got auto-growth happening while auto-growth is set on. You haven’t got auto-growth happening during overnight slow periods, so I like a bit of space in there. But if you start looking and you’ve got that the data’s only filling 50% on a 1TB file, then I’m going to start to consider whether we should shrink that back down.

Carlos:             Okay. In following that, you have one terabyte, you’re only using 500GB, you want to reduce that size. How many times are you going to reduce it before you say, “you know what, enough is enough. Yeah, maybe I’m hitting the threshold. I’m getting the alerts.” The SAN guys are like, “hey, we’re running out of space, we’re getting notified here. We have to do something about it.” How many times are you going to do that before you say, “okay, manager, I need more discs”?

Nigel:              Again, it’s a case of if I go in to say I need more discs, then I need to be able to justify that. Is that through natural growth? Is that through an accident?

Carlos:             But even on the SAVE TABLE example, isn’t that, I won’t say natural growth, that’s maybe a stretch. However, it is a mechanism. It’s a culturally accepted practice to back up the table that way. Now, sure, are there other ways to do that? There’s no question. I’m not saying that that is the best way. But if that’s the way your team is doing it, isn’t that justification enough to say, “these are the problems we’re running into. We need to make the change.”

Nigel:              Possibly. But we’re talking about if that’s culturally acceptable within the team that does it, that’s quite a different topic from the team that handles the SAN admin, and indeed myself. I act as a gatekeeper between two teams that don’t naturally work together. I’m extremely diplomatic on both sides, really, just to make sure that we do get the space if we need the space. But they know that I will only ask for the space if we really need that space. I think that’s key, really, in terms of working in a business.

Carlos:             There you go. I guess I’m particularly interested in the compression scenario. Steve had this great scenario with a shrink database. Imagine going into the grocery store and you have aisles to walk down. But when you shrink the database, now imagine all those aisles coming together and then you have to go just around the edges. What kind of downsides do you see when you have to do that? How long is the recovery, if you will, from the shrink database process?

Nigel:              The shrink database process or shrinking files is quite a horrible process. I’ve described it as you’re literally picking up the data from the edge of the file and then smearing it across all the gaps in the earlier parts of the file. It causes dreadful IO while it’s running, dreadful IO afterwards, when you’re using the data. It causes fragmentation of the data itself, and this is where it becomes really funny whereby you see people who will look at it and let’s say we’re talking about shrinking files knowing what you’re doing at the moment. If you’ve got people who are totally ignorant to it, you often see that they will see, “oh, there’s a bit of space there”, so they will shrink that file and it makes this enormous mess within the file. Then in the evening, defragmentation and index maintenance jobs come along and they say, “oh, look at that, what a terrible mess. I’ll reindex all these tables.” So, it reindexes all the tables and then causes the file to grow once again. I’ve seen that happen to people. And what’s worse is if something else takes the disc space that you’ve shrunk the file to get, and then it can’t go anywhere in terms of defragmenting that in the future. I think that’s almost like an accordion where they can shrink it and then they do something and it expands and then they say, “oh no, I’ll sort this. I’ll shrink it again” and it’s an awful process. I think that’s why it’s become such a controversial or taboo subject, where I think there’s a lot of people that are really not keen on people doing it. Which is fine and understandable, but because of that reason, it’s just not spoken about other than the Don’t side of it. Whereas, I live in the real world and from time to time, I do have to do this process. That’s what got me thinking into what different ways can I do it.

Carlos:             That’s a great point. Obviously, we’re a bit more knowledgeable. We understand the ramifications and we’re not doing it on a regular basis. You set up some parameters, you’re like, “okay, I think I can save this much space”, warnings, whatever the threshold might be, you’ve given yourself some limitations, I guess is what I’m saying, and then you’re going to proceed with caution.

Nigel:              Absolutely, proceed with caution, and that’s when the fun starts, really. What I have found, especially it happens at the end of a change window where you sync, for example, going back to the data compression. You can do the data compression, you get it down, there’s plenty of space, part of your justification for doing the change is this particular system cannot have extra discs attached to it for various reasons and you need to just shrink that file at the end. And then, as I say, you get to the end of the change window, you just issue the shrinkfile and it does nothing. I do describe the shrinkfile process as just going so slow, painfully slow, and time just stands still. One thing you haven’t got any chance of doing is finding out how long SQL Server is going to take to shrink that file.

Carlos:             Right, even the windows copy, as bad of estimations as they are, is at least trying to give you some indication. With shrinkfile, you get nothing.

Nigel:              It doesn’t even give you anything for the person that, again, at the end of that change window is now stood on your shoulder asking you when you’re going to be done. I put that down to being even SQL Server not liking to shrink data files and it’s not very efficient at doing it. Describing it like my kids, if you give them something they don’t want to do, they’re going to string that job out for as long as they can, until you’ve either asked them to stop, or if they do complete it, you’re not going to ask them again. There’s a few different ways that you can do it. We’re just talking there about traditional where you just sit there, type in DBCC SHRINKFILE and then wait for it. The ideal method that’s pushed forward by the industry greats and leaders, is to create a new file group and move all the data into that file group.

Carlos:             There you go, so it’s almost like an in-between step. You’re not moving the database, you’re just creating a new file group.

Nigel:              That’s right, create a new file group, drop the other one. That can be really good. Depends on how much data you’ve got, how much time that you’ve got, and how much disc space that you have. You might be in this position because there is no disc space.

Carlos:             Sure, also true. That sounds like a different problem altogether.

Nigel:              It is a different problem, but they are related. Just as somebody might not know sufficient to do that, so there’s a knowledge issue there, as well.

Carlos:             Okay. Now one of the other things you talk about is along with that migration process is to attempt, and maybe you’re still creating the file group, but attempt to actually rebuild some of those clustered indexes before you do the shrink to then help you go a bit faster.

Nigel:              Absolutely. What SQL is doing, as I mentioned earlier, when you are shrinking, it’s going to the end of the file finding what data is over there and then picking it up page by page, trying to squash it in somewhere else and it’s just not efficient at that, at all. But index rebuilds, I got to thinking about those, because index rebuilds, SQL is really good at. It’ll use the memory, it’ll use the CPU that you have and when it rebuilds the index, I will say most times, it will move data from where it is, say, at the end of the data file, to a position that’s more inland. But it’s a case, then, of knowing what SQL Server is actually doing, what table SQL is working on when it’s just sat there doing a shrinkfile. Everything that it does is a logged operation, so I started to think about, “well, I wonder if there’s anything I could find from the transaction log.” That is one place to go. But if you look at what tables are locked, because it’s going to lock a table while it’s doing a shrinkfile, which is another reason to not do a shrinkfile. Pick your time in and where you do it, otherwise users are going to be sat there waiting on locks. But it will lock a table in order to move bits of them safely. I’ve found that if you look at what tables are being locked and then stop the shrinkfile, rebuild the table, and that will rebuild all of the indexes on it, it will move that further in.

Carlos:             That’s right, you’ll kind of get that movement by itself. Now, having said that, that doesn’t, maybe not the compression, you can correct me on the compression, but that doesn’t necessarily apply to the scenario we talked about where, “hey, I’m backing up a table into a new table.” That wouldn’t apply there. That would be more of a scenario where, “okay, we’ve gone through and we’ve just dumped a data warehouse.” We deal a lot with medical practices and they have to keep seven years of data, so now at year eight, I can now legally get rid of that data. I’ve just dumped a bunch of data from seven years ago. That would be more of the scenario where it would be like, “okay, now I have to go into the tables themselves and do some of that cleanup.”

Nigel:              Yeah, by cleaning that up, you could then, again, rebuild the table.

Carlos:             But that’s the scenario you would use for the rebuild process?

Nigel:              Yes, but also if you’ve had somebody take a full copy of an enormous table and then remove that, chances are SQL will have put some more data on the end of it, but any data at the end of that file, if you see that it’s stuck trying to move that data and you do a rebuild on that particular table, then you’re likely to– I’m trying to show with my hands, but I can’t.

Carlos:             The downsides to audio.

Nigel:              Absolutely. There’s going to be a large chunk of nothing which you might have data to the right of at the end of that file, but once you get rid of that data to the right of it, then it’s going to be able to shrink fairly quickly, so remove that table.

Carlos:             Very good. Ultimately, I like the approach. I like this idea to say, “hey, there are parameters” and that is something that we should probably be better as a community about is training people or telling people, “hey, under what circumstances might you consider this?” We’ve talked about some of the downsides, but if you need to do it, there is an option and at least here’s what you need to know.

Nigel:              Yes, there are a few other caveats there in terms of if you’ve got heaps, they will often stay exactly where they are, but then the old trick of adding and removing a clustered index is likely to help. But you’ve got to be aware, as well, that your transaction log has got to be big enough to store the table rebuild. You could just push into a different issue somewhere else. But as you say, it’s a case that most of the time, leave the extra space there if you’re going to grow into it. I’ve been in situations whereby you’ve got systems that cannot be expanded for various reasons, and you’re literally, it’s a bit like doing a three-points turn with a petrol tanker in the children’s playground. You’re very limited on your maneuverability and you’ve got to be incredibly careful, but sometimes you do have to do these things.

Carlos:             That’s right. Very good. We’ve been talking about data file shrinking. I know we mentioned at the beginning everybody’s going to have to do log file shrinking. We make some of this, just to that point, you were talking about rebuilding an index. Your transaction log may then be affected. Do we need to talk about shrinking the transaction log at all?

Nigel:              The only comment I was going to mention is that you know those lovely days when you suddenly discover another SQL Server where somebody says, “hey, I installed this. I took all the defaults and now it’s run out of disc space.” I think the best ones come when somebody does that and they say, “well, I put everything on the C: drive, so literally everything has stopped.” That, as you mentioned earlier, if somebody sets up a system or a database using the full recovery model but never schedules log backups, then that’s going to grow and grow and grow. You end up with a situation where you might get a 100MG database and a 200GB log file and that will just run until it completely fills the disc. I’ve seen that sort of situation, whereas it would be nice to back up the log, there’s no space to do that, or it doesn’t make sense because it’s too large. That’s a situation whereby you are just getting into switching the database to simple recovery mode, switch it back and then shrink it back down. Generally, shrinking log files is a lot more acceptable, other than you need to find out what happened, why that log file grew so big, just like the data file, really, and put things in place for that not to happen.

Carlos:             Yeah, that is an interesting thought there. Playing a little detective work so that you can know what is the reason? Why am I having now to perform this? You don’t want to go about it willy-nilly and knowing about it is going to be helpful. I kind of think, and this is a slight tangent, but I kind of feel that log growths are the hidden gremlins in the systems, sometimes. When you’ve set it up, and again, these are more the scenario that you mentioned, “hey, I’ve installed this SQL Server. We’re now kind of using it and now all of a sudden it’s a big deal.” But nobody’s really been maintaining it. It’s still using those percentage growths. Then all of a sudden it gets to a size where it has to grow, it’s slow disc because it’s all local, and then you see that, because everything stops and the disc has to grow. I kind of feel like that’s one of those things that can get people if they don’t leave enough space and they don’t know what the growth rates look like for those log files.

Nigel:              Absolutely. Absolutely.

Carlos:             Should we go ahead and do SQL Family?

Nigel:              Yes, that would be fine.

Carlos:             Nigel, tell us how you first got started with SQL Server?

Nigel:              Okay, I started my working life in the transport industry, even before it got called logistics, but my heart was always with IT and computers, always loved that. So, that took me through various experiences and jobs, ending up as a coder. I had a few years’ experience with coding in Visual Basic and VB 4.

Carlos:             Now, I am curious, so you mentioned you started a profession, so you’d been working there several years. Was that night classes, did you just pick up a book? How did you kind of get started there and then even make the leap from ‘technology’s not my job’ to ‘it is my job’?

Nigel:              Technology was always something I was interested in as a hobbyist. It was back in a day where, perhaps, it was easier to move from one to another. I was coding many years before I took it up as a job.

Carlos:             Okay, hobbying, as you mentioned.

Nigel:              Yeah, certainly hobbying, but I was recruited into a company that was using Visual Basic and also SQL Server. Visual Basic, I felt, was getting a bit crowded, at the time. There was an awful lot of self-taught people in those days and I decided that SQL Server looked a safer bet for the future, because you couldn’t really learn it in your bedroom and SQL, being harder to spell than VB. Now, that was in the day of SQL 6.5, so it’s a few years ago. I do recall a colleague talking about upgrading to Seven Heaven and essentially, SQL Server and me have looked after one another ever since.

Carlos:             Very nice. In all that looking after, if there was one thing you want to change about SQL Server, what would it be?

Nigel:              The pricing structure.

Carlos:             Even with SP1 changes that they made in 2016, a bit more freedom in the Express Edition, you still think that there’s some more wiggle room there?

Nigel:              There is some wiggle room in there. I think the number of times I get people coming to me to complain about how expensive this thing is, and I’ve seen SQL Servers with large number of cores being quite uneconomical to run under Enterprise because of the ‘every core needs to be licensed regardless of use’. Or indeed, somebody who very proudly purchased a SQL Server with a raft of memory, but can only afford to run Standard Edition on it.

Carlos:             Yeah, they get tied in there.

Nigel:              That’s a bit of a problem. And I think also the pricing structure lends itself towards bad practices, so ideally, we’d be looking at separate SQL Servers for different services, such as SSRS, SSIS, SSAS, so Reporting, Integration and Analysis Services. But then it becomes difficult to justify, economically, having them on those separate servers.

Carlos:             Yeah, it’s a little bit of having your cake and eating it too, though, because we get so used to having, we think SQL Server and somebody comes to us, even with Reporting Services. Well, it’s SQL Server. Well, not really. It’s bundled with SQL Server. You get it with SQL Server. But I wouldn’t say Reporting Services is the same as SQL Server.

Nigel:              Oh, they’re very different.

Carlos:             That’s right, they’re very different. But it’s become so commonplace to have them there.

Nigel:              I think instance stacking is another example where people believe, “right, I’ve paid for SQL Server on there, how many instances can I put on there?” And then it is literally how many clowns can we get in this car, after a bit.

Carlos:             That’s true. There is one minor exception to that, and that is with containers. The Windows containers, you have to license each individual container, so there’s really no benefit there. But I know that under, for example, the WinDocs platform, you actually do get some benefits. You can actually layer those up and actually see some license benefits. But yeah, I totally agree with you there. It can get pretty crazy, pretty quick.

Nigel:              It is.

Carlos:             Nigel, what’s the best piece of career advice you’ve ever received?

Nigel:              I struggled with this one, but I think it’s making yourself useful to the business and knowing what your value is. You should always consider what value you are adding to the business. I’ve had moments in the past where I felt I’ve done a tremendous job. I’ve sorted out large issues and it’s kind of just viewed as a bit of, “well that’s computer, you should deal with it, why am I getting billed for this?” And also, I think, I think as IT professionals, we struggle with how to get recognition for doing something without feeling like a fraud. Our nature means that we’re often happy, “well, we’re just doing our job” as opposed to shouting it from the rafters. So, you then put that in a situation whereby there’s other people at performances reviews or the like, that are far better at selling themselves and what they’ve done. We’re just happy doing our job.

Carlos:             That’s true. It can be tough and I think there’s a fine line, because we all know those show-boaters or the know-it-alls that are constantly reminding everybody about what they’re doing and we don’t want to do that, either, so it can definitely be a delicate balance. Nigel, our last question for you today. If you could have one superhero power, what would it be and why do you want it?

Nigel:              I would like the ability to turn back time. I’m getting to an age where I see younger people, children included, and I’m really excited for them. I’m really excited for their future and the opportunities that they have, because it might be more difficult out there these days, starting off than when I started. But there’s way more opportunities, there’s way more advice and guidance than we ever had. Nothing is beyond people now. I’d love to redo some of my career years, learning from my mistakes without them actually happening, I guess. But equally, I guess I’d probably get stuck in an infinite loop of trying to fix different things and other things happening. But yeah, I think turning back time would be a nice one.

Carlos:             Yeah, wouldn’t we all, in that sense? I hear you on the young people. You look at them, and I think that’s why people enjoy working with youth so much is because they see that future, the untapped potential there, and it’s exciting to think about. I also look at some of the high school students, so this is the 14 to 18 age group, of which I have a daughter in that bracket. I look at her and I’m like, did I look at that young when I was in high school? Because yeah, they sometimes look like babies and you’re like, “yikes, they’re making a lot of decisions that can impact that trajectory”, and they don’t recognize it. You almost want to play that role of, “look, no, this is– I’m coming back from time.” Yeah, exactly, exactly. Well, Nigel, thanks so much for being on the program today. Great conversation and thanks for making some time for us.

 

Carlos:             What I think is just so funny, Nigel, we were chatting and again, this is one of those areas where I think you definitely don’t want to automate it, but as Nigel said, “I live in the real world, and there are things that will be required”. He doesn’t have the luxury of going out and getting new hardware all the time. I think in limited situations, and as long as you know the issue and how to go about it, yeah, this could be a help for some of you out there. I’m interested to know, as always, compañeros, if you have feedback or thoughts on today’s episode. You can leave those on social media, on the show notes for today, which is at sqldatapartners.com/shrink. We’re always interested in hearing what you want us to be talking about. Our music for SQL Server in the News is by Mansardian, used under Creative Commons. You can connect with me on LinkedIn. I am @carloslchacon and I’ll see you on the SQL Trail.