For our first feature on working DBAs and their lives, we chose Grant Fritchey, the self-styled Scary DBA, who has been so successful in the past year with his books and presentations. How does he manage to pack so much into his life? We sent Richard Morris to find out.

With twenty years experience in IT, Grant Fritchey has been spent in technical support, development and database administration. For the last seven years he’s been working as a DBA at a major insurance company, in between time, he writes for SQL Server Central, Simple-Talk and SQL Server Standard.

Grant has published several books including, Dissecting SQL Server Execution Plans and SQL Server 2008 Query Performance Tuning Distilled. He is one of the founding officers of the Southern New England SQL Server Users Group and its current president. In April 2009 Grant was awarded Microsoft SQL Server MVP status.

---

RM:

Where do DBAs come from – are they born an admin, achieve adminhood or have it thrust upon them?

GF:

I think most DBA's have adminhood thrust upon them. I think the ‘accidental’ DBA is the most prevalent path into becoming a DBA. I became a full time Admin by opening my mouth once too often.

I had been working for a dot com as a full time VB developer. Our DBA had quit. Over time we ran into more and more problems with the database. One day, after having dealt with another problem, I went into the boss’s office with a list of things that needed to be fixed. He asked me which one I was going to do first, and a DBA was born.

I don't think everyone comes into it as simply as that but, in my experience, the person that became a DBA because that was their absolute goal is a pretty rare beast. Many other people I know stumbled into the DBA role from development, tech support or other roles, frequently without a plan. The best of them embrace the role and try to turn themselves into the best DBA they can be.

RM:

Do you still get to do much programming? Would you agree that programming languages today are more diverse and engaging than at any time since the early days of computing?

GF:

Yes and no. The problems are the same as they've always been: "Here's some real world process that needs to be turned into ones and zeros. Here's a grossly inadequate mechanism for expressing it. Go have fun". You can do more things than you ever could and you can do those things faster than you ever could, but sometimes that just means you dig a much deeper hole, much faster.

Having said that, I love the new languages! Powershell is pretty cool. C# is so much better than VB or Java. Object oriented programming, while more than a little bit of a pain, is simply incredible, especially when compared to the old serial languages. It's a great time to be IT and it just keeps getting better.

RM:

How did you learn database administration – from books, colleagues, websites, official training, hands-on practice? How best do you think it can be taught?

GF:

I mostly learned how to be a DBA from books, lots of books. I still mostly learn from books. Right now, I'm reading a book on PowerShell, another on SQL Server 2008 XML and I've got another on CLR sitting on my desk, waiting to get cracked open. I'm a big proponent of books. While I prefer having the dead-tree version, I've started using a Kindle now and am finding out how handy it is to have the ability to really search within a book, rather than just relying on the index and a whole bunch of post-it notes hanging out of the edges.

I've only attended a few official training courses and didn't find many of them that useful, although the one taught by Itzik Ben-Gan, Advanced T-SQL, is worth five times what you pay for it. I do read a lot of articles online and find them an excellent resource for learning details, but not broad areas.

Testing is probably the very best way to learn. Try something out, get the results, record them, and then modify the code and try it again. Repeat as necessary until you understand what's going on.

Technical summits or conventions are also good places to pick up knowledge. The next SQL PASS summit is in Seattle during the first week in November and the event is always is a great place to learn new things and, more importantly, meet new people. When you're searching for that final piece of the jigsaw, that last bit of information you need to accomplish the task in front of you, the best resource is usually a fellow DBA. It makes a huge difference to be part of a good network of DBAs and programmers with whom you can interact. You can also do this online at places like SQL Server Central.

RM:

Who do you regard as your Zen master, the person who has taught you most about what you know today?

GF:

I'll pick three, not one. First up: Kalen Delaney. I've read, I think, four versions of her Inside SQL Server books. It's really hard to stress just how useful that series has been to me, over the years. I've also attended her sessions at conferences. She's as good a teacher as she is a writer.

Second, someone I'll never get to learn from ever again, Ken Henderson. He wrote books that were every bit as useful as Kalen's, but they covered different topics, or had a second point of view on similar topics, and so were an excellent complements to Kalen's work. I never got to hear him speak, but I've read his articles, as well as his books. He really made an impression on me and it's a damned shame he died so young. I could use his help with SQL Server 2008.

Finally, and I've mentioned him before, Itzik Ben-Gan. I often joke with people who have attended his class that ‘the bleeding from the ears stops in a few days’. Sitting in his class is the mental equivalent of drinking from the firehose. You get quite a lot of information, usually more than you bargained for but, happily, it's all useful.

Between those three, I'd say I've received the foundation to be able to do the things that I've done.

RM:

What would you say are the three characteristics of an exceptional DBA? Why do you think these qualities are so important?

GF:

The first one that comes to mind is grace under pressure. At some point in your career, you'll have a substantial number of managers, probably going very high up the chain of command, standing inside your cubicle. Typing will be difficult because they'll be jostling your elbows to get close enough to read what you're typing, even though they don't understand a word of it. It's all because, for some reason, one of the most important databases in the company is offline or inaccessible, or in an unknown state. You need to fix it quickly and competently, all the while explaining what you're doing in plain English, no techno-babble allowed, and suggesting ways to prevent the problem, whatever it is, recurring in the future. If you can do all this at the same time with those managers in your cube, then you're on your way to becoming an exceptional DBA.

Next is a willingness to learn. Picking up the new TSQL syntax is only a small, although important part of that. The larger part is an understanding that things change, and a willingness to adapt as necessary. You might need to learn how to work with an agile development team, or implement a third party software package that requires 'sa' privileges, or move your database out into the cloud. It's a willingness to embrace the change, to learn, not just new processes, but new paradigms that will make you more successful as a DBA.

Finally, I think a good DBA has to have a strong backbone. You need to be able to say no. You need to be able to say that the choice made on this database, if implemented, will cause problems, explain why the problems are going to occur, and offer a more-suitable alternative. You will often be under pressure to accept the solution "as is", but if you simply roll over, you're going to pay the price. It won't just be you though; it'll be your database and possibly your company.

There are certain issues on which a DBA must never compromise. For example, there's a good reason why you should do backups before a major modification of the database, and just because someone within the organization thinks it's a silly waste of time to run one, and doesn't want to wait the extra 45 minutes, tough. It's your charge as a DBA to ensure the integrity and protection of the databases under your control.

If someone asks for something silly, say no. You may have to do it anyway but get out there and make sure people understand why you said no. And it shouldn't just be because you want to be able to say "I told you so." If that's why you're doing it, stop being a DBA. You do it so that maybe, the next time, they'll listen.

RM:

Who do you think from history would have made a great DBA? Leonardo? Or the Danish astronomer Tycho Brahae? Truman or Nixon?

GF:

I'm not sure any of those people, except maybe Tycho Brahae, would have made good DBA's. Well, possibly Truman too. Some of his attitudes would certainly make him a good DBA. One figure that comes to mind from history is Major General Erich Ludendorff, the chief of staff to General Hindenburg during the battle of Tannenburg, in 1914.

Ludendorff not only helped Hindenburg plan the battle, but was also responsible for managing the supply chain, the railroad schedules, and all kinds of other support staff to keep the army running and to help win its, fairly spectacular, victory over the Russians. Given the way he attacked the data with the tools of the time, I think he might have made a heck of a DBA.

Another general from history that spent a lot of time assimilating data as a means to victory was the Duke of Wellington.  He wasn't one of those "lead from the front, dashing about on a horse" kinds of guys; you know…a developer. No, he spent most of his time behind the lines, worrying about lines of communication and choosing when and where to hold most of his battles, and winning them too. I suspect in today's world he would be one of those top flight BI guys that knows a hundred different ways to slice data and retrieve vital company information.

RM:

What's the hardest part of being a DBA?

GF:

I've been on call 24/7 for about six years now. It's wearing a bit thin, especially since I haven't been trading off with other people. But, I get extra pay for being on call and if it makes the wife happy, then who needs to be asleep at 3AM each morning?

RM:

What do you see as the future of automating database administration? Will Powershell come to rule all or do you think Python will still have its fans?

GF:

PowerShell is going to take over. Microsoft is positioning it across all of its platforms and its various products such as Exchange and Operations Manager.

While there's always going to be other languages used, like Python or Perl, they're going to be marginalized under a PowerShell juggernaut.

RM:

What things in your career would you have done differently? And what achievements are you most proud of?

GF:

I don't think I've made too many gigantic errors in my career, although learning Gupta SQL Windows ended up being some pretty serious time wasted.

Given what I've said previously about the value of books in learning, I regret not spending more time with books earlier in my career. Instead, I tended to assume that the fact that I was writing code and designing databases meant that I actually knew what I was doing. There are many applications, a few still in use today, which would have benefited greatly from harder study on my part. It's tough unlearning bad habits. Also, if I could go back, I would develop earlier in my career the habit of testing performance.

The two achievements that I think best indicate what I've managed to achieve are my books, and the MVP award I received just this year. Writing books is a heck of a challenge. You can get so much right, but it's the mistakes that seem to stand out. You get so much support from the editors and the technical reviewers, without whom you wouldn't have a book, at all, but in the end it is your name on the front cover, so you get to take full responsibility for the good and the bad.

Microsoft's MVP award was something I had considered a couple of times, years ago, but after meeting a number of different MVPs I realized that maybe I wasn't ready for it. However, eventually my work got noticed and it came through. I was so excited to receive the award that I started working harder in the community, so that I could feel worthy of it.

However, the best thing about the books and the MVP award are what I had to do to achieve them. I've had to learn things I never would have otherwise. They've forced me to stretch my skill set well beyond where it was previously.