How To Not Be a Commodity DBA – Part 1

A couple of months ago I wrote about the concept of the DBA as a commodity (DBAaaC), and how it can be so easy for management to consider any DBA as a basic, and replaceable resource within their organization. This got me to thinking (and it would seem that my thinking takes a long time) that maybe a little guidance would be in order to help prevent you from becoming a DBAaaC.

Not everyone is in the same situation, so I’ve broken this down in to a couple of parts, one for those of you that have the time, and inclination to get things done, and those of you that can barely find a half hour to themselves.

First up…when time for you isn’t a problem…

When you have the time

Enjoy that luxury while you can, because it will not last forever. While you have spare time then you are able to use it to greatly increase your knowledge of SQL Server and its various ancilliary components (plus underlying operating system). “But where to start?” I hear you ask. There are two ways you can go here.

 

What interests you?

Seeking knowledge, and finding it, is something that you would be able to do with any piece of SQL Server, so just pick something random and have at it.

Actually that’s not the best way to go. Think about what it is that you find interesting or exciting about SQL Server (or a related technology). When you have a keen interest in a subject it generally makes it easier to learn. Additionally, you will probably find the learning process for that subject to be fun, which makes you more likely to do it, especially when the going gets tough (it’s not all sweetness and light).

 

Build out your home lab

This can be as cheap, or expensive as you want to make it.

You can use free virtualization software like VirtualBox, along with evaluation editions of Windows Server, and SQL Server Developer edition. This will get you a long way as you’ll be able to spin up your own domain, build out your SQL Server instances, create Availability Groups, and generally do whatever you want. As an additional bonus you’ll get to learn lots about getting Windows working, and some of the quirks of Active Directory and DNS.

If you have spare funds then consider purchasing yourself a high powered laptop or desktop, or even hit up Ebay and purchase a second hand server. Purchase yourself a copy of VMWare Workstation, and a Visual Studio Professional subscription so that you are able to run your software without limitations and expirations .

 

Read as much as you can

Reading is fundamental. There is some amazing content out there, just blast through a couple of dozen blogs by people who know their stuff (right now I subscribe to 118 SQL Server related blogs, many folks post infrequently, others post regularly). Figure out the things that they are doing, and how they are doing them. Take any examples that they provide and work them through yourself. Learn the lessons that they are giving.

Going through all that content leads to the next step…

 

Start up a blog

As you grow in your area of interest, or as you pick up things that you’ve done at work, share them with the world. So many technical blog posts look simple to write, and can leave you feeling that the author managed to put it together in a couple of minutes. But when you start writing you’ll quickly find that you really need to understand things a lot better than you thought in order to start sharing that information with others (this post took about 6 hours total to write, but that’s not your yardstick). You’ll quickly start going down rabbit holes for strange side-effects, or patterns that don’t quite match what you thought was going on.

Does this impact what you are doing at work? Surprisingly yes, you’ll start to garner much more in-depth knowledge which will be helpful in everyday situations like troubleshooting.

 

Start presenting

If you think a lot of work goes in to creating a blog post, just wait until you get yourself geared up to give a presentation. You’ll really need to know your stuff inside and out, and then be able to be able to provide answers to some really esoteric questions related to the subject of your presentation.

Even when you know your stuff, it can easily take greater than 40 hours to create a presentation that is strong, and that people will want to see. But the learning and level of understanding that comes along with it is significant.

 

Help other people

I don’t mean going down and volunteering at your local hospice (although they could really use your help), rather get out on the various forums like SQLServerCentral, or StackExchange, where there are people that could really use some assistance. You’ll run into some strange problems out there (especially on dba.stackexchange.com) that you might decide are of interest, and you’ll spend a couple of hours poking through, trying to reproduce, or fix the posed question. Or you might even have the knowledge that you can just drop as an answer right away.

 

 

Contribute to an open source project

You’ll very quickly learn things that you had no clue about before by contributing to open source projects. A great example is https://dbatools.io/ which provides all kinds of PowerShell based commands for managing and migrating SQL Server instances. Even reading the code can take you a long way. I know that it took my PowerShell knowledge to another level, not to mention touching SMO, which I would not have done otherwise.

It doesn’t have to be that particular project, there are many out there. Create your own fork, make some changes, and then create a pull request to get your changes merged in. Heck, you could even submit changes to the SQL Server documentation through Github.

 

Putting it all together

So you’ve built yourself a lab, have the latest production version of SQL Server running on there, have a domain with AGs running. You now know how to script and set those up using PowerShell, and troubleshoot them when things go bad, and figure out what happens when you change owners of an endpoint.

You’ve written some posts on the topic, and contributed to an open source project with a script that handles changing the owner of an endpoint that stores the old endpoint permissions, changes the ownership, and puts those permissions back again.

Then you added the missing information to the Microsoft documentation about how endpoint changes are handled, and you gave a 20 minute presentation to your local SQL Server user group.

Now what? How does this make you more valuable in your job, and stop you from being a commodity?

You have already proven that you are capable of learning and getting up to speed with new things, and troubleshooting some strangeness (think changing endpoint owners is cut and dried?). You’ve presented, and written about what you know. The next step is sharing some of that information internally.

How about creating a series of brown-bag lunch sessions, just once a month, to teach other DBAs and developers some concepts in SQL Server? They can be lighthearted, and not super indepth at first, with you working on some more basic concepts and then building those up over time.

As an example, think about what you know as regards indexing, and what needs to be done in order to index a table properly, how the data types used, and how often a table gets updated can impact fragmentation levels on those indexes, and the ways and methods that you can work to ensure that performance is maintained on them.

That example alone provides enough to do at least 3, if not more, sessions:

  • How to create an index
    • What the various index options are:
      • CLUSTERED vs NONCLUSTERED vs FILTERED vs COLUMNSTORE (clustered and nonclustered) vs XML vs SPATIAL
      • ONLINE or OFFLINE
      • SORT_IN_TEMPDB
      • DROP_EXISTING
      • STATISTICS_NORECOMPUTE (worst naming convention of all time)
      • ALLOW_ROW_LOCKS
      • ALLOW_PAGE_LOCKS
      • DATA_COMPRESSION
        • PAGE vs ROW vs NONE
      • FILLFACTOR
      • PAD_INDEX
      • MAXDOP
  • How to identify the columns to use in an index
    • Query predicates and join conditions
    • Columns returned from the query
    • How the clustering key is included in all of the other indexes
    • The hidden costs of not clustering on the primary key and having duplicate clustering keys
    • The cost of wide indexes vs the cost of key lookups
  • Maintaining indexes
    • The things you have to worry about with indexes:
      • Fragmentation and how fillfactor can impact this
      • Outdated statistics
      • Locking (and blocking) calls
      • Rebuilding or reorganizing indexes (and how that can impact production performance)
      • Strategies for moving nonclustered indexes off to secondary filegroups
      • Strategies for moving tables to secondary filegroups by rebuilding the clustered index

As you start to share this knowledge amongst the team your cachet will increase, you’ll become recognized as someone who knows their stuff, and you can use the things you learn, and questions you answer to continue building out your blog, and external presentations.

As you keep progressing down this road one of two things will happen:

  1. you’ll stop becoming a commodity DBA and become a force multiplier, or
  2. you will have built yourself a great reputation, and added things to your resume that companies love to see, so you’ll able to use them to find yourself a job somewhere that you won’t be treated like a commodity

All in all, it’s a complete win.

 

The luxury of spare time is not something that everybody has, so in part 2 I’ll cover how to stop being a DBAaaC without spending your nights and weekends messing around with SQL Server.

,

3 Responses to How To Not Be a Commodity DBA – Part 1

  1. Andy B 2017-08-28 at 09:00 #

    Love the post, just a question about the blogging. Would you recommend making a blog, even if the information you are interested in/blogging about is already in abundant supply? One of the reasons I shied away from blogging in the past is that what I might be writing about (maybe something I’ve struggled with myself) people already write about, indeed, 50% of the problems I come across can be resolved by reading somebody elses blog.

    • sirsql 2017-08-28 at 14:55 #

      Yes, absolutely. You have your own voice, your own take on things, and your own way of explaining something. Just because somebody writes something that does not mean that it either
      A) is read by someone
      B) is understood by someone who read it
      C) resonates with that person so that they truly get it
      Having a different voice means that the information might be accepted and understood by someone who may not have gotten it previously. That’s why there is no true master of presenting any of this stuff. While someone may have all the knowledge in the world, unless what they are saying it understood, and accepted, it doesn’t matter. And things will never be understood by everyone.

      You also mentioned that 50% of the problems you come access you could resolve by reading someone elses blog, sure, but what about the other 50% that you couldn’t resolve? Or of the first 50%, what if your situation and setup is a more unusual than the typical? After all every setup is unique. There are nuances all over the place.

  2. Eugene van den Bergh 2017-08-29 at 09:50 #

    Great post thank you 🙂 much appreciated. I absolutely agree with how easy it is to go down those rabbit holes. You need to learn to focus your attention on what really matters and interests you. (if you have time available)

Leave a Reply

%d bloggers like this: