T-SQL Tuesday #128: Learn From Others - July 2020 - Part 2

So I thought about this one a little more, and I think I'll make it into an unintentional two-part T-SQL Tuesday post. In my initial post, I expressed my gratitude to AirborneGeek (t/w) for bringing me into the madness that is databases. But I didn't really tackle the intent of his topic for the month. 

Kerry, you know where I came from. You know my aviation background. So you know that I 100% believe in the importance of being able to learn from other people's mistakes. It's a big part of how pilots learn not to break things. 

I didn't set out to be a database person. I didn't intend to be in this place. But I can't exactly say that I didn't ask for it. I'm apparently more masochistic than I thought. I mean, when I met you, I was a ColdFusion developer...... Now I'm a DBA. I could have had a much lower-stress life if I'd just stuck with being a pilot. Sometimes I question my life choices. But it is what it is, right?

I submitted late this month, and I wish I hadn't procrastinated. I think your topic was excellent, and it is something that I completely understand. The global airline industry had to suffer some very hard lessons before they realized that knowledge-sharing, especially of the bad stuff, was actually an extremely good thing. 

I spent years as a Flight Instructor. You don't learn from perfection. There have to be mistakes. That's what "learning" is. But, sometimes, it's better for you if someone else had to learn the hard lessons first. Just so long as they tell you about them. And if you listen to what they did wrong, maybe you won't go down the same path. 

I could probably write pages about how to assess a risk and how to manage that risk after you've assessed it, but it always starts at the same place: you have to be able to IDENTIFY that risk first. And no matter what the topic is, you don't know what you don't know. Murphy understood that. And I'm willing to bet that anyone who has worked with any sort of system for longer than a few months understands that sometimes things break unexpectedly. Most businesses that I've ever been associated with work at a pace that's much more appreciative of your ability to quickly find the solution on Stack Overflow. I'm willing to gamble that most people would prefer not to be the first person to write a blog post about what they found out and how they fixed it.

Honestly, off the top of my head, I can't think of any unique problem that I've run into that I haven't been able to Google my way out of. I'm also fortunate to have an exceptionally good team that is able to cover the subject areas that I'm not an expert in (like the network). I got a rather late start in the DBA game, so I don't have Bertrandian levels of experience as the Guardian of the Databases. But when I was primarily a programmer, I was grateful that I wasn't that person when a database went sideways, and I've also come to appreciate that I used to be an extreme database abuser. I never really would have had the opportunity to ask Kerry silly questions if I hadn't been. 

In answer of this month's T-SQL Tuesday, I don't really have my own individual story to share, but I can affirm the importance of both sharing information that you probably wouldn't want other people to know and of accepting that information without any sort of judgement. There's a reason that people warn about making sure that you have a WHERE clause when you DELETE something, or the joys of accidental Cartesian JOINs on large tables. At some point in a career, everyone has done it. Or they will. 

It's really hard to top a willingness to talk about what went wrong when your error cost millions of dollars and possibly hundreds of lives. But, if an airline can talk about how they screwed up, then no company should have even a tiny problem recapping the decisions they made that caused a multi-terabyte database to go poof at 4PM on a Friday. 

And no DBA should be too remiss to learn from (and not repeat) those mistakes.

T-SQL Tuesday #128: Learn From Others - July 2020

I don't write enough here. I let myself get too busy, and I often miss things that I want to write about. I have several articles that I've started and dropped and several ideas that I never even started. I do a great job of lurking and not a good enough job of participating when I should. So it's no surprise to me that I've been sitting on this post for a week and missed the deadline to officially participate. 

T-SQL Tuesday #128 for July 2020 was hosted by a friend of mine; someone I worked with a few years; and the person who is directly responsible for my transition from just a ColdFusion Programmer to also a SQL Developer (and now a DBA). 

When @AirborneGeek came to work with me, I was primarily a programmer who knew just enough SQL to literally be dangerous. I could get a query to return the data I wanted, no problems there. I had fallen into the normal trap of "My queries are slow. It's gotta be the database's fault." Or Network. But we all know the network is the cause of 99.9% of all problems, right? 

I think one of the primary reasons we even created his team was because we were an application running off of millions of records, with NO database experts, and our applications were slow. 

Specifically the reason why I became somewhat fascinated with SQL was because I ended up being responsible for an internal report that had to be run overnight because it ran for HOURS. I can't remember if I was the original author of said report or not (wouldn't be surprised), but it didn't really matter since it was my responsibility now. I thought it could do better, so I approached our new database team to see if they were smarter than me. Everyone knows that programmers are smarter than DBAs anyway, but I figured "What the heck?". I gave him my query. 

He held onto it for a couple of days, and when he handed it back to me, it looked nothing like what I had given him. But it gave me the same data and ran in only a few minutes! 

It may have been Voodoo, or it may have been Black Magic. Regardless, if not for my silly internal fault of always wanting to know "Why?", I'd be on a MUCH different career path.

Over the next couple of years, I had plenty of questions for him and the rest of the Database Team. The more I learned about how the database was supposed to work, the more I came to realize how wrong I had been doing things. That team taught me about how to do proper JOINing, proper indexing and generally how to make things faster and much more efficient. Also about how important it was to not accidentally write a Cartesian JOIN on a 10M row table.  ( Just FYI: That can apparently discover the memory limits of your SQL Server and earn you a desk visit from the DBA.) 

I know that my questions for @AirborneGeek probably seemed very basic to him. He always showed me patience when he answered my questions. He never treated me like an ignorant programmer, though in hindsight, I realize now how basic some of my questions must have seemed. So, What Can I Learn From Others?

As another pilot, I completely agree with the premise that piloting and DBAing have a LOT of similarities (disasters differ in magnitude, but are very similar in remediation, and a lot can be learned from other people's "Uh-oh" moments). 

My post really isn't so much about how I've learned to deal with SQL disasters, but about how I've learned to be grateful for the people who got me here. 

I can't say it enough, "Thank you, Kerry."

Though I guess I should also point out that the curiosity that was sparked has also led me to learn more about certain types of disaster remediation and recovery than I ever really wanted to know. So "Thanks again, Kerry."