Hello T-SQL Tuesday Readers! I’m sorry for being really late in getting this post out this week.
So! A couple of weeks ago, for this month’s topic, I asked everyone to post about something that broke or went wrong, and what it took to fix it. Last week, fourteen of you responded with your stories of woe so we could all learn from your incidents and recoveries in a constructive way, like pilots do. Here’s the recap of those posts, in the order that they came in.
What Everyone Had to Say
First, is Rob Farley with, “That time the warehouse figures didn’t match“… heh, I feel like I’ve heard this one before. But it turns out, no! this is new and awesome. Rob talks about a fundamental rule he has when loading data into a data warehouse: “protect the base table.” This is his first step in ensuring that data in the DW is correct, and as anyone who does DW or BI work knows–that is always the most important thing, because if trust in the data coming out of the reporting system is lost, it can be pretty hard to get it back.
John McCormack has “Optimising a slow stored procedure” next. John walks through his process of tuning up a stored procedure he had gotten an after-hours call about being slow enough that things were breaking. He’s got a good tip in here if you use SentryOne’s Plan Explorer, too. AND, there’s an added bonus of including something that I find frustrating when it happens. Basically: “This web page is usually really slow and the users were frustrated about it, but nobody ever told me!” Y’all! Tell us (IT, support, whoever) when you’re not happy, we’re usually happy to fix things to make your life easier!
Richard Swinbank talks about that time he unintentionally set a trap for himself in “Default fault.” Changing the default database for your login in SQL Server when you’re the DBA is all fine until you decommission that database! Richard includes great steps for digging yourself out of this hole with sqlcmd if you’ve “locked yourself out” of the instance when using SSMS.
Eitan Blumin’s post about a mis-behaving set of Azure VMs has a good surprise twist in it. This post struck me as a little hilarious, both because of the 32 hours bit, but also because I/we had just been talking about fullscan statistics update in our internal corpchat this week. I like fullscan stats in general, when they can be pulled off and are helpful (think non-uniform data distribution), but when they take down your AG, that’s, uh, bad. Don’t do that. Eitan also includes a nice set of takeaways at the end of the post.
SQL Cyclist/Kevin3NF I think wins the prize this month for having the longest contribution. Turns out, he has an ongoing series of blog posts of real-life stories along these lines, which include seven posts about fun goings-on that fit into this topic.
Next is Jason Brimhall with “Disappearing Data Files“… Jason shares a pet peeve of mine, which is having to fix the same thing over and over again. When that happens, it’s good that one at least has/knows the fix, I guess…. Anyway, Jason goes into using Extended Events as an audit tool to detect changes to tempdb files to help track down the root cause for a “recurring fix”, and reiterates that sometimes those root causes are hard to track down, and the best place to put yourself in for those situations is to be ready the next time.
Deborah Melkin says, “I feel like it’s been a while since I’ve joined the party.” Ohh, I’m pretty sure it’s not as long as it has been for me… Debora doesn’t have a specific break/fix story, but talks about how experiences and dealing with problems over time makes it easier to address new problems as they come up. This is the core lesson (lesson? Process?) I’m wanting everyone to get this month, so I appreciate this perspective!
Hugo Kornelis has my favorite post of the month. If you’re the type who doesn’t read all of the T-SQL Tuesday posts and waits for the recap to find the one or two that look the most interesting, make sure this one is on your list. It’s short and to the point, and contains a fantastic lesson. Two, really, although one isn’t explicitly mentioned as a lesson. This one is the fact that if there’s something you do on a regular or reoccurring basis, you should have that process written down. Think of it like a checklist (flying reference ahoy!). But what Hugo makes clear is that even if you’re doing something different that you don’t have a process for, but is adjacent to that process, it’s still a good idea to reference that process. Just read Hugo’s post, it’s easier than listening to me
I felt bad just reading Aaron Bertrand’s post. Just, go read it. Promise. Take his advice.
Lisa Bohm brings us what I think is a heartwarming story about what transparency and honesty can bring to even professional relationships. Lisa tells us about how this worked out for her while working for an ISV when things went bad on a Friday night (it’s always a Friday night). In addition to the honesty part, she had another takeaway that we can all do better at sometimes: Shut up and start listening.
Next up is STEVE JONES, the one that got me into this damn mess in the first place. He at least takes ownership of that in the post, heh. Steve’s speaking my language here with “And too few companies share their learnings publicly.” …This is a crab of mine, as well, and I think a lot of IT shops would make fewer bone-headed mistakes if everyone was more willing to share what they’ve learned, NTSB-style. I understand why things are the way they are, and all, but it doesn’t mean I have to like it. Anyway, Steve has many encouraging words for learning from others in the first place, and how he has been fortunate enough to be able to work with people who have helped him build better systems. I always appreciate Steve’s writing, and this post is no exception.
Glenn Berry wrote about a place where I think we’ve all been–it boils down to not RTFM But also, it involves building PCs, which maybe most of us used to do, but hardly any do anymore. I still do, but only once every, like, eight years, so… This was funny, because as Glenn walked through how he got here, I saw right where this was going; I mean, with four disks to hook up, I would have gone right for that nice quad of stand-offs, too! I mean, why split the cables up between two places when you could just do one! Yeah. Uh-huh. Yep. Glenn’s main takeaway is, basically read the documentation, which is always a good idea. As someone who really likes writing it (I’m aware of how broken I am), I also know how little this happens in practice.
Todd Kleinhans talks about Letting it Fail. This is true–sometimes things have to break to get the right peoples’ attention, or to show just how bad a situation could get. Todd has a story about just one of these situations. I don’t think any of us like things getting to that point, but sometimes there aren’t other options. Todd also has a good final takeway, about “doing nothing” being a valid option to a situation, and it really is. May not lead to a good outcome, but it is an option!
Tracy Boggiano starts out with a line that is a big “been there, done that” for me: “One fateful night while I was not on call, I got a call around 3:30 AM.” Ahh yes. You’re not on-call, but you wind up on the horn with Ops, anyway. Tracy’s story has some good head-shaking items in it, which is about how I expect a story that starts like this to end. Tracy has a good line towards the end: “Everything from the network, to the server hardware, to the database creates the system and working as a team is the only way to make sure things are configured to perform and not fail.” Ain’t that the truth…
And finally, my man Andy Yun talks about Presentation Disasters. Andy comes through here with probably the most aviation-related lesson of all: Paranoia Pays Off. Yessssss! Always have a Plan B–plus C and D if possible–so when things go pear-shaped, you already have a plan. Andy was presenting at GroupBy back in May, when his headset died. But he was ready! Good lesson for all and everything here, not just those of us slinging TSQL or flying airplanes.
And that’s it! This was the first time I’ve hosted T-SQL Tuesday, and I want to thank everyone who shared their stories with us this week!
Contact the Author | Contact DCAC
Pilots do something that a lot of non-pilots will find fairly weird if not outright horrifying: We read accident (“crash”) reports. Some of us spend a lot of time reading accident reports, actually. Officially “Accident Reports”, these are put out by the US National Transportation Safety Board (NTSB) after investigation into a crash or an “incident.” In addition to aviation-related reports, there are highway and railroad reports, and even hazardous materials incidents.
Reports come in two flavors, a “preliminary” report, and ultimately, a “final” report after the investigation has completed. The final reports includes such items as conclusions and the probable cause of the accident or incident. To make life easier, they also include a Recommendations section, which, well, includes recommendations for how to keep this type of accident from happening in the future. These tend to be regulatory in nature, as they are geared towards the FAA.
The search form for aviation reports is here–https://www.ntsb.gov/_layouts/ntsb.aviation/index.aspx–if you’re, uh, thinking you want to get into this sort of thing.
Why do pilots do this? The rationale is pretty simple: To learn from the mistakes of others. Or, to learn how a bad day was kept from becoming a worse day after something broke.
What Does This Have to Do With SQL Server?
Great question. Besides the fact that I think piloting airplanes and DBA-ing are the same job, just with different scenery, I wish we had this kind of transparency in the IT world when things went wrong. When a corporation has a big security incident, we’re likely not to hear a lot of details publicly about what went wrong and what was done to mitigate similar attacks in the future. This kind of information could help everyone. This is one of the things that cloud providers do quite a bit better: When something breaks, we get good information on what happened, why, and what’s going to be done about it. Of course, this is done because public cloud providers basically have to–if things went down a lot and we never heard why, that provider probably wouldn’t have a lot of customers for very long.
This brings me to T-SQL Tuesday.
Tell me (us all, obviously) about something recently that broke or went wrong, and what it took to fix it. Of course, the intent here would be for this to be SQL Server-related, but it doesn’t have to be. We can all learn from something going wrong in infrastructure-land, or how there was a loophole in some business process that turned around and bit somebody’s arm. It doesn’t even have to be all that recent–maybe you’ve got a really good story about modem banks catching on fire and that’s how you found out the fire suppression system hadn’t been inspected in years. Just spitballin’ here. If you’ve got an incident whose resolution can help someone else avoid the same problem in the future or improve a policy as a preventative measure, let us hear about it.
Here are the rules as set out for the T-SQL Tuesday blog party.
Contact the Author | Contact DCAC
- Your post should be published on Tuesday, 14 July, 2020 between midnight and 11:59:59 UTC/GMT/ZULU
- Include the T-SQL Tuesday logo in your post
- Link back to this invitation (usually done through the logo)
(this will get syndicated, so link back to the original on airbornegeek.com, please)
- Include a comment on the invitation post or a trackback link
- Enjoy the chance to be creative and share some knowledge.
SQL Saturday in Cleveland, Ohio is next week, on February 3rd. If you’re in the area or can easily make it there, I hope that you can come out for a great day of free SQL Server training. I enjoy presenting at SQL Saturdays; they’re fun and educational days for speakers and attendees, alike. Last time we were in Cleveland it had snowed overnight when it was time to leave town on Sunday morning. I’ve lived even longer in the south now, so if that happens again, it’ll be even more fun this time.
In addition to my session on Saturday, where I will talk about using database projects in SSDT/Visual Studio, I’ll also be presenting an all-day session Friday on Azure Infrastructure. Planning and designing your infrastructure is just as important in the cloud as it is when building new systems on-premises. As Azure continues to grow and expand around the world, more companies will be choosing to migrate (or deploy new) services to the public cloud. Understanding the underlying components is imperative to maximum-performance and highly-successful Azure deployments and hybrid migrations. In this session, we’ll cover infrastructure fundamentals with a bit of a focus on deploying and running SQL Server in Azure; however, there will be plenty of general background discussion that can be used for any workload.
Registration for this precon is available here, on EventBrite: https://www.eventbrite.com/e/azure-infrastructure-presented-by-kerry-tyler-tickets-41688096218, with information about the overall SQL Saturday event available here: www.sqlsaturday.com/708
Saturday is free, but tickets for the full-day precon are $150.
I hope to see you next weekend!
Contact the Author | Contact DCAC
The final post of my little series of fives for Seattle and PASS Summit finally focuses on the conference itself. This list is for five sessions/events that I think should be on your list to check out this week while at Summit. A couple of these will be difficult to get into, because they will be super-popular. In fact, people have been known to stand in line for the entire previous session in order to get in to one of these presenter’s sessions before. Therefore, like, plan accordingly and stuff.
Dr. Rimma Nehme Keynote
Thursday 8:15 AM
Rimma worked for a while at Microsoft’s Gray Systems lab in a certain midwestern town, with Dr David DeWitt. Back in the day, David–one of the best speakers you’ll ever seen in your life–would give the “tech” keynote at Summit, and everyone would show up to get their brains melted. It was awesome. What’s still awesome is that torch has been passed on to Rimma, and she’s every bit as awesome a speaker as David is. She also got her PhD from Purdue, which makes here more-awesome, obviously. It doesn’t even matter what she’s talking about (it’s here), just go. Thank me later.
Bob Ward: Inside SQL Server 2017 on Linux
Wednesday 3:15 PM
Like the tech keynote, whatever Bob’s talking about at Summit is something to go to if you’re a DBA. This year it is about SQL Server on Linux, one of the most important developments in SQL Server Land in a long time, and definitely one of the most compelling new “features” (obviously not the best word here) in SQL Server 2017. This should be a great presentation for SQL Server DBAs, even if you can barely spell “vi”, and you’ll want to get there early. Bob’s session is where people have stood around for half a day waiting for.
Itzik Ben-Gan: T-SQL Tips and Tricks
Wednesday 10:45 AM
Apparently you should just sit around in 6B all day Wednesday and you’ll have a great day. Itzik is to TSQL as Bob Ward is to the engine, or Rimma is to, well, everything data-related. A “tips and tricks” session may sound ho-hum, but if Itzik is giving it, you’re guaranteed to learn something and get your mind blown by what Itzik will be able to show you with three lines of TSQL. I don’t care how good at TSQL you are, I guarantee you’ll learn something from Itzik in this session.
André Kamman: Azure SQL DW Guidance for ETL Developers
Friday 11:45 AM
Andre gets the “token” BI mention here, and for good reason. Azure SQL DW is a pretty great, scalable, useful service for workloads and data sets that can leverage its enormous capabilities, but along with that capacity and capability come pitfalls to the uninitiated. SQL DW can look like a bit of an odd duck due to its weird load patterns and seemingly missing SQL functions, so content like Andre’s are a definite requirement for ETL architects and developers who are going to be leveraging this service. Even if you don’t utilize it now, learning about the under-the-covers massively parallel processing is useful, I think.
Sunil Agarwal: Maximizing Query Performance with Columnstore Indexes
Wednesday 10:15 AM
Alright, so I have a scheduling conflict here. Don’t blame me, I didn’t build the schedule.
Sunil’s going to talk about query performance with Columnstore indexes in SQL Server. Joey and I may-or-may-not have had input into this presentation’s content, so I know it’s going to be good. Kinda like Azure SQL DW, Columnstore Indexes provides some great benefits, but it’s not necessarily something that one can just throw into your existing data model and have your performance go through the roof–there is a little extra work involved to get there. Also, Sunil’s always one of the smartest people in the room, just the type of person I like to listen to talk. I’m thinking I’m not going to be able to make it to this session, unfortunately, although Sunil does have another columnstore session (“Strategies to Speed Up Data Load into Clustered Columnstore Index”) Friday at 11:00 AM.
Contact the Author | Contact DCAC