T-SQL Tuesday #128: Let’s Talk About Your Incident Reports

By Airborne Geek on July 24, 2020

TSQL2SDAY Logo

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… Deborah 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!

Posted in , Tagged Leave a Comment

T-SQL Tuesday #128: Learn From Others

By Airborne Geek on July 6, 2020

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.

The Rules

Here are the rules as set out for the T-SQL Tuesday blog party.

  1. Your post should be published on Tuesday, 14 July, 2020 between midnight and 11:59:59 UTC/GMT/ZULU
  2. Include the T-SQL Tuesday logo in your post
  3. Link back to this invitation (usually done through the logo)
    (this will get syndicated, so link back to the original on airbornegeek.com, please)
  4. Include a comment on the invitation post or a trackback link
  5. Enjoy the chance to be creative and share some knowledge.

Posted in , Tagged , 16 Comments

T-SQL Tuesday #36: What Does the SQL Community Mean to You (Me)?

By Airborne Geek on November 13, 2012

TSQL Tuesday Logo

T-SQL Tuesday #36: How rad is Community? Rad enough for me to say “rad.”

I hate doing this, but I’m throwing this post together at the last second, as with PASS Summit going on last week, I completely spaced that this was T-SQL Tuesday Week. I blame the fact that I dropped my #TSQL2sDay search column out of TweetDeck last week, but that wouldn’t even have helped, because I spent most of my time on the Surface, but that’s a different story/post altogether. Community is something pretty important to me, so I’m here trying to get this out the door by the deadline (I failed, see below).

T-SQL Tuesday #36 is being hosted by Chris Yates (blog | @YatesSQL), who chose this Community-related topic this month. It’s pretty fitting, considering a good chunk of us have just gotten back from PASS Summit in sunny (yes, really) Seattle this past weekend, where there’s a lot of “community” going on.

Hard to Avoid a Summit Story

Having been one of those that just returned from Summit on Sunday, it’s pretty hard for me to think about this without thinking about last week. I had a couple different things I wanted to say, but I’ve settled on the following, about being a and helping Summit FirstTimers.

Last year at Summit was our first time there. We’ve both been to a fair number of Tech conferences, so it wasn’t all  a new experience for us. This, combined with the fact that we already “Twitter Knew” a fair chunk of people, led us to not opt-in to the organized First Timers networking event (I’m sorry, Tom). Even with the fog machine, rock music intro the FirstTimers had heading into 6ABCD (which was pretty bad-ass), we were OK with this.

We’ve learned a lot about our Community since our first Summit, only a year ago.

This year, Tammy signed up to be an Alumni Mentor for FirstTimers. I was added as kind of an “unofficial” mentor to help her out, instead of having a group of my own, because, when you get right down to it, I’m a huge pansy. I was going to be OK just being there, but not being a mentor myself. That’s scary!

First Timers Sign for Groups 55, 56, 57

Groups on our sign. My rogue group became 57A.

As it turned out, there were a lot more people show up to the FirstTimers networking event than expected. I was standing there with our group’s (and two others’) sign, directing people which table to sit at, depending on which group they were in. At one point, Buck Woody, the guy with the microphone, and therefore the most powerful person in the room (turns out Buck Woody with a microphone is the best, but scariest thing ever), just told everyone to sit down anywhere, because it was taking too long to get everyone in. Next thing I knew, the previously-empty table I was standing next to was full of eager first-timers, along with Tammy’s table, and the other two groups on our sign.

Ohhhhhhhhcrap, I now have my own group of FirstTimers!!!

I had to get over being a pansy real fast. It did help by leading off by telling everyone sitting at my table that I guarantee I was the most scared person siting there. The time we had to sit there and listen to speakers and talk amongst ourselves actually went pretty fast. My group didn’t talk amongst themselves quite as much as I maybe would have liked, but they did have some questions about the conference, which I could answer and help out with. Plus, my head didn’t explode!

Where am I going with this? To me, “SQL Community” is sitting and talking face-to-face with people I’ve never met before…even though doing that scares the living crap out of me. After this experience, I’m sorry that we didn’t do the FirstTimers event last year. I’m going to make up for that in the future, though, by going ahead and volunteering to be a mentor of my own FirstTimers group in future years.

Timezone Fail

Bonus section!

Soooo, this post is late. I forgot that we’re GMT –6 now, because we’ve gone back to Central Standard Time. When I started writing this, I was shooting for 7:00p local. Then, at about 5:59, I realize the truth. Even then, this machine is showing 7:03, so I still failed.

And I’m the guy always crabbing about people saying “EST” when they really mean “EDT” 🙁

Posted in , Tagged , , , , 1 Comment

T-SQL Tuesday #30: A DBA’s Ethics

By Airborne Geek on May 8, 2012

T-SQL Tuesday 30
#30: Deep T-SQL Tuesday or Deepest T-SQL Tuesday?

Chris Shaw (blog | @SQLShaw) brings us T-SQL Tuesday this month. His topic of choice is “A DBA’s Ethics”, which is a pretty deep subject! I feel like this post goes off the rails a little bit compared to the direction of the invitation post, but I had something happen last week that really made me think about this topic in a specific way.

Chris says, “Don’t consumers and business owners have to trust someone at some time with their data?” This is a line that I have clung to in the past; at some point, it has to come down to trust. Since I feel this to be true, it makes me somewhat crabby when regulations & whatnot seem to step in the way of that trust, possibly making it hard for someone like a DBA to do their job due to data or system access restrictions. I do believe that there are times and places for regulations like this, and after what I learned last week, I’m probably more on the side of these types of security regulations than I was before.

NPR to the Rescue

See, I wasn’t even sure if I was going to write a post this month or not. I wasn’t sure what I wanted to talk about or if I was even going to be able to get enough coherent thoughts together. But then, one day last week, I was minding my own business (more or less), driving home from work, listening to WPLN, as I am wont to do, when this story came on. To very roughly summarize for those not interested in spending 18:34 listening (I do recommend listening to or reading the story):

  • Father is upset as his son is convicted of bank fraud.
  • Asks younger son to promise to never get into that kind of trouble.
  • Younger son promises.
  • Younger son starts own business.
  • Realizes one day company is under water.
  • One thing leads to another and 22 years after The Promise, said younger son is convicted of same crime as older brother.

I was interested in where this story would go… I mean, why do otherwise “good” people do “bad” things? At the beginning, I thought that somehow research was going to say that doing bad things “runs in the family” (the older/younger brother angle). As the story progressed into the part where Toby Groves begins asking employees to help, and they agreed, I started to think about how there’s no way I would do such a thing…and how could these people?

When the story got to its punch line, it made me think about how this topic related to DBAs:

We like to help each other, especially people we identify with. And when we are helping people, we really don’t see what we are doing as unethical.

A couple questions developed in my head when I heard it, and as I thought about it more, the questions only got more complex:

  • Are we, as DBAs (or DBA-type folks) at all immune to this type of thinking?
  • Would a DBA be more willing to help another DBA specifically? If so, how thin can we split that hair?
  • What about supplying data for audits? Does that change the thought process?
  • Does having an ethics statement really do any good?

I don’t have answers to these questions—not sure anybody does—but they make for interesting things to think about.

If Only I Had a Psychology Degree

I know the first question I have listed there seems pretty pretentious, but I wound up there due to specific reasons. Of course DBAs like to help other people; that’s not what I’m saying. What I am saying is weighing “helping people” while still operating within “the rules” is kind of what we do. I’ve spent a fair amount of time working directly with developers both on projects and to get projects deployed to Production systems. Although it is nice to be able to tell coworkers “that’s all OK”, that isn’t what we get paid to do; instead, more often than not, we’re paid to say No. Not because we don’t like people or enjoy it, it’s because we are trusted (there that is again) to apply “the rules” objectively to everything we are involved in or are supposed to approve for deployment. These “rules” can be administrative procedures, architectural/design policies, or even something simple like scheduling. Because of the nature of what it is we do, we are used to taking a step back, away from the people involved, to ensure that we do the right thing.

Does making decisions like that on a day-to-day basis make a person able to apply that same objectivity to every situation they ever encounter? Who knows? What about if the situation was changed a bit? DBAs (and sysadmins, for that matter), tend to rag on developers a little bit; usually in a good-natured way. But, I believe that, for the most part, DBAs and Developers are fundamentally two different kinds of people—we tend to think and act differently (and that’s OK). So, what happens if a fellow DBA comes to us with a problem or the results of a mistake and are looking for a way to fix it quietly or sweep it under the rug? Since we identify with the fellow DBA more so than, say, a developer, are we more likely to go along with the cowboy fix, as is pointed to by the study in the NPR story? I mean, if one doesn’t truly stop and think about what is going and what is being asked of them, it’s easy to simply think, “oh, Jim-Bob’s a DBA over on the Production team, surely he wouldn’t want to do anything outside of policy…”

What about the audit situation? This can go both ways: on one hand, one wants to help the auditor do their job by getting them the data they’re asking for. On the other hand, you may be wanting to help your team (or yourself!) out by possibly not supplying everything involved in a request. It’s easy to sit here and office chair quarterback the scenario, but that’s the point—it’s easy when you’re not in the situation  yourself, in the same mindset (or lack thereof), staring the same consequences in the face. Thoughts and actions only count when…well…when they actually count.

This is where doubts about ethics statements begin to creep into my head. It’s easy to read through SANS’s Code of Ethics that Chris pointed out on this fine Tuesday and laugh, being like, “yeah, like I’d ever knowingly hurt someone’s reputation or look up the boss’s salary in the HR DB.” The problem is that opportunity or request might not come up on a Tuesday morning while we’re sitting around reading blog posts over our second cup of coffee—it might come up while you’re having an exceptionally bad day, and all you want to do is make at least one person happy. Before you know it, you might have gone off and done something illegal, or at the very least, ethically questionable.

Does having a company, community, or personal code of ethics keep this from happening? The way I interpret the reported study’s results, I would have to say no. Of course, that’s not true for everyone or every situation—it depends! It depends on a lot of things. So many things, in fact, that it’s completely within the realm of possibility that having such a code and reading it regularly to remind ourselves of the covered items could just cause the right synapse to fire in the right situation to keep us from doing something stupid. Does that make it worth the effort? Probably.

I have to say, though, historically, I’ve gotten crabby about things like this that get formalized. I always ask “Really?!”, because I feel like I’m pretty hard-wired in this department and get a little offended by having a code of ethics thrust upon me. I have to say that I’m a a little afraid after hearing the NPR story that there’s a chance I would let things get out of control before I realized what’s going on. At the same time, though, I realize that having that fear and being alert to it is probably about the best way to safeguard against doing unethical things in the first place.

But…

There’s still a problem here. The problem is that we’re not perfect. Insidious things creep in at the corners without us noticing. Even though we’re trained and practiced in recognizing when something abnormal is going on and to see through the glossy surface down to the gritty details, things can still go horribly wrong due to being stuck in those details and missing the big picture.

I don’t know about you guys, but that NPR story freaks me out a little bit. Do I believe what I said above, about DBAs being used to making similar decisions, makes us immune to this type of “sympathy think” (pardon me while I make up words again)? No! I’m worried I go around every day a hair’s breadth away from starting something highly unfortunate just because I wasn’t paying enough attention or thinking the right way about a task.

Sure, talking about a DBA’s ethics is a little bit different than talking about mortgage fraud, but the fundamental decision is the same: Could what I am about to do hurt myself or someone else? It’s hard to think about that question at every turn throughout the course of the day, but apparently we need to, because once again, our animal brains are being a pain in the butt.

Posted in , Tagged , 1 Comment

T-SQL Tuesday #28: Jack of All Trades Crew, Checking In

By Airborne Geek on March 13, 2012

T-SQL Tuesday—always a good option for helping to get back on the blogging horse.

TSQL Tuesday #28
T-SQL Tuesday #28

This month is hosted by Argenis Fernandez (blog | @DBArgenis), a SQL Server MCM & a #SQLFamily member that I have yet to meet. His topic of choice is “Jack of All Trades, Master of None?”, which is right up my alley, because for pretty much my entire IT career, that phrase has described me. It still does, right this second, but I’m trying to get over that. More on that coming.

Because I should be able to use them to frame out a good story (and because I’m cheap), I’m going to work with the list of questions Argenis has in his invitation post.

Are you specialized? On something? Or anything at all?

Am I anything at all? No, not really, thanks for asking! 😀

Anyway… it’s not really safe or fair to answer whether or not I’m specialized with anything but a firm “no.” I’ve been this way from day one. I don’t know that it’s been a conscious decision to get to this point more than it just happened as a result of being driven by a desire to know how everything works. Sometimes that leads to depth in weird places, which can come in handy while watching Jeopardy! on TV.

My non-specialization situation at the moment includes the capabilities of a decent SQL Server DBA, being what I’ll call “serviceable” when it comes to data modeling, and could still be a sysadmin if push came to shove, in a day job in which I have become the go-to ETL Developer. It’s a little weird, I admit. But, all of those other things help with the current focus. The ETL job is slow, you say? Well, is the server on the floor? Is the latency over the WAN link 700 ms per round trip? All of my other skills help, and that is what I think is the best part of being a jack-of-all-trades: It’s possible to know just enough to answer a lot of your own questions!

I’ve said it before, but another thing I like about knowing a little bit about a lot is you can make friends/commiserate with almost everyone in the IT department.

Are you the SQL Guy at work? Or the one who does everything?

Due to the size of company that I work for, there are very few “Guys” at work—everyone has a specific job (or sometimes jobs) that they do. Basically…near-insect-grade specialization. There’s not room for a jack-of-all trades at larger organizations, in my experience, with the possible exception of smaller, autonomous groups.

Having spent time in one of those smaller, autonomous groups within a larger organization, I was a little bit of the guy who does everything. My whole team was, actually. We were “Windows System Admins”, who ran just about everything except Exchange and the MSFT monitoring platform du jour, plus Citrix to boot. Although each of us had our strong points, pretty much all of us could get through whatever needed to be done and have things work when we were done. I think that just goes along with being a “sysadmin”—being a jack-of-all-trades is almost a necessity. Need to know hardware? Check. Security theory AND implementation? Yep. IIS (Apache as necessary)? Probably. Networking? You betcha. SQL was just one of the things that I did while there, although I did do a lot of it.

Do you code? And configure wireless routers at work also?

Hell no. I mean… not if I can help it. See, when I started in IT for real, I knew one whole programming language: Visual Basic 6. Two classes in school on it, and that was it. I wrote a little print queue viewer/management app while a student (hey, it was deployed on 2000+ machines!), but no real experience. To this day, VB6 is the only real (“real”) programming language I know. Not having a strong coding background does cause some problems occasionally, especially when talking to Developers who are used to DBAs coming up through those ranks. I definitely don’t know much about software engineering theory, and that’s where it shows up the most.

As part of the afore-mentioned sysadmin gig, I wrote a command-line only VB app as an automated interface between a couple of systems, but I’m not exactly proud of that moment, for a number of reasons. The one that applies here is one of the downfalls of being a jack-of-all-trades: it’s easy to cowboy up and do quick-and-dirty things off to the side, because you can. Perhaps even more dangerous: because no-one else can.What happens as soon as you’re done? Well, if you’re not careful, it winds up in Production, and then it becomes a support nightmare; if not for you, it will be for a coworker or the next guy. Either of which may some day hate you when their phone rings at 0300 because the wrong piece of duct tape fell off your masterpiece. I think being a jack-of-all-trades can be a good thing, as long as one of those trades is holding onto whatever processes and standards are in place…and if there aren’t any of those, hopefully one of said trades is coming up with some good organizational processes and standards!

As for the wireless router configuration bit—I try to keep that at home. Pretty sure the network guys wouldn’t like me messing around with those things. Just because I [used to] know Cisco IOS, doesn’t mean I should use it. That brings us to another good specific skill that a jack-of-all-trades should have: Knowing when to sit quietly. This goes for both wireless routers and writing anything in VB6 that has a prayer of ever seeing real, actual production use.

If you had to pick one thing to specialize on, what would it be?

Yeah, about that… All the above said, I actually am going to try to specialize on something. Of course, it isn’t enough to say I’m going to specialize on SQL Server. There’s too much in the product now. I’m going back to the thing that got me truly interested in the prospects of becoming a Data Pro in the first place: Business Intelligence. Unfortunately, I don’t think it’s safe to make that a goal, either. Just the BI side of the SQL Server platform is becoming too broad and too feature-rich to come to grips with. I’m going to have to be content with possibly not knowing anything at all about Reporting Services to focus on what I really want to do: Analysis Services. I actually want to be able to do most of the architecture work surrounding big BI projects, from start to finish (except for SSRS!), but I’m afraid that even just SSAS, including all of its new related technologies, could turn out to be too much.

That, though, is a journey that I hope we can all share in. Because I’m nice like that.

Other Thoughts

Being mechanically wired more than anything, it’s not quite as easy for me to tear down a piece of T-SQL as it is, say, the battery operated toys I used to take apart…Or a carburetor. But thanks to the Internet, it’s easy for me to read about and learn from someone who is more adept at doing that sort of thing. This shows two more helpful skills for a jack-of-all-trades: Being able to read and learn is a really important one, and being able (and willing) to share back out is another good one. You never what kind of DBA trying to configure Exchange you’re going to help out.

Posted in , , , Tagged , 5 Comments