Meredith Ryan has been named as the winner of the Exceptional DBA Award 2012.

Meredith is a self-taught DBA with more than twelve years experience in IT, ten of them spent at the Bell Group, an international supplier to the jewellery industry. She has most recently served as a production Database Administrator, supporting MS SQL Server databases ranging from less than 50mb up to 1TB in size. Meredith grew up in the ranks of IT, starting at the Help Desk resolving as many issues as possible on the first call and moving rapidly to VAX/VMS and Windows Server administration.

In 2006, she took the opportunity to become a DBA and has since made it her mission to learn and share all she can with her co-workers and other new accidental DBAs. In her spare time she is the chapter chair for the Women in Technology Virtual Chapter of PASS, on the board for the Albuquerque NM PASS chapter, a mother of a five-year-old boy, an obsessive knitter, novice gardener, and an avid reader of any book she can find.

RM:

Meredith, you had a classic accidental route to becoming a DBA. Could you tell me a little about it please?

MR:

Sure thing! Not only was my path to DBA accidental, my path into IT was accidental – or at least not planned by me. In 1998 I was working as sales associate taking orders over the phone from our customers when the Operations team posted an internal opening for someone to run the internal help desk.

I was ‘strongly urged’ to apply by my manager at the time. I had no intention of applying – I didn’t have any formal qualifications – my only experience with computers was using them at work and spending too much time on old Bulletin Board Systems (BBS) and hanging with the local hackers – the type that make things out of other things, not the black hat, havoc-wreaking  kind.

I did apply though, and was hired by a great group of guys. I quickly learned why that manager pushed me so much – I had an aptitude for IT, and within 6 months of starting on the Help Desk was administering systems.

When the company migrated off of our VAX cluster to a SQL server based Enterprise resource planning (ERP) our DBA at the time asked me to be his backup person. I started shadowing him; taking on basic things like checking backup status, ensuring log shipping was working, and eventually chasing down blocking and locking chains when he was out of the office. I was hooked! Managing databases and all the moving parts involved in a stable SQL Server environment was where I wanted to be full time.

When our DBA left the company to move to the east coast, I gladly took over the responsibility of our database servers and I haven’t looked back.

RM:

Do you think the kind of people who can be successful DBAs has changed, and is becoming a DBA more of a career choice than an accident?

MR:

Hmm… that’s a great question. I don’t think that the core strengths and qualities that make a successful DBA have changed all that much. You need to have strong basic troubleshooting skills, have the ability to look at the data ecosystem holistically, the patience to drill into details, and have very strong attention to detail.

I think those traits are the same no matter what type of administrator you are – Exchange, Windows, General systems, or databases.

What I do think has changed over the last few years (for me at least) is that I need to be able to translate my technical knowledge to less technical co-workers. I have to be able to explain the reasons and benefits of my technical decisions in a business language. I have met a few folks at recent SQL Saturday’s that are there because they want to become a DBA – but those people are still a very small minority. In my experience, at least, most of us are still accidental. I do hope that is starting to change.

RM:

Why do you think it’s important the industry recognises the work DBAs do? And what has given you most satisfaction?

MR:

Some wise person, long ago, stated something to the effect of ‘If you are a great sysadmin no one will know your name’ and I think to a large degree that’s true. As my systems have become more and more stable my notoriety has fallen away.

I work with almost 400 other people, and if all 400 of those people knew my name because I’m the person that always fixes the system I wouldn’t really be doing my job as a DBA.

These days my immediate teammates know me well, but folks in the call center or warehouse have no idea who I am or what I do – because I’m proactively ensuring their systems function as expected, instead of rescuing the system in the middle of the business day. With that said, recognition of a job well done is very important. Without that positive reinforcement I think it’s easy to start to feel like you are taken for granted no one wants to feel that way. Having industry recognition of a job well done reminds us that the work we do does have impact, and that it is important work.

RM:

How much does trying to be an exceptional DBA matter to the job you do?

MR:

The company I work for is guided by a set of principles. Number 7 of these is ‘Exchange your best effort for the best effort of others’ If I weren’t trying to be an exceptional DBA every day I wouldn’t be living up to this principle and would be letting my co-workers down. Honestly, I don’t know that I would enjoy my job very much if I weren’t trying to be exceptional at it – why do something with half a heart?

RM:

You began to call out for queries at monitor #SQLHELP and help out at SQL Saturdays, why did you decide to share your knowledge in this way and what do you get out of it?

MR:

My first SQL Saturday was Number 41 in Atlanta (April 2010). I had heard a little bit of buzz about them at PASS Summit the year before and it was convenient to attend as it was the weekend before another conference I was attending in Atlanta.

I had been attending PASS Summit for years, but New Mexico was lacking the local SQL community that so many other areas had. I saw SQL Saturdays as a way to get a taste of the local community. After attending that year I was convinced of the value the offer and made it a professional development goal of mine to speak at and attend at least 4 SQL Saturdays each year – with a focus on the south western states.

I’ve met that goal for the last two years, and don’t plan on calling it quits anytime soon. I learn something new and different at each event I attend, and by speaking I find that I quickly discover what I truly know and what I only think I know. At least once in every session I present, I tell someone that I don’t know an answer and will have to get back to them. That in itself makes me a better DBA. #SQLHELP and twitter in general is just an extension of the community for me. I mentioned earlier that I cut my technology teeth on BBSs in the early 90s. Twitter reminds me of those. I lived in the chat rooms on my local BBSs, and the twitter stream takes me right back there. It’s just another way for me to measure my knowledge and share what I have with others.

RM:

What are the biggest lessons you feel you’ve learnt from the SQL community in the time that you’ve been answering questions?

MR:

The biggest thing I’ve learnt is that no one is an expert in everything, as Paul Randal is fond of saying. It’s completely okay to not have expertise in some area or another. For instance, I don’t know much more than how to install Analysis Services, and that’s okay – I know who to ask for help if I need it.

RM:

What are the commonest mistakes and assumptions which crop up again and again?

MR:

Backups, backups, backups! Actually that’s not the whole story – restores, restores, restores! It’s the same old thing every time.. Server went belly up and restores were never tested. Lo and behold, the backups haven’t been running/files are bad/can’t be found… I’m right there with Grant Fritchey – you can never test your backup/restore plan too often.

RM:

With SQL Server, there comes a time when you think “this would be a really useful, feature, if only they had bothered to finish it”. What are the features you think could be improved on?

MR:

Wow! This is a tough question for me. I tend to default to the mind-set that I am missing some key piece of information about any given feature that isn’t working the way I expect rather than that the feature wasn’t finished.

I guess the one thing that jumps to mind is the Missing Index feature, although I know that it was designed as a light weight suggestive feature rather than a way to fine tune your indexing. Unfortunately, those missing index suggestions are easy enough to find that some less experienced developers/DBAs see them as gospel without digging into what the impact of the suggested index will be. I’m not a huge fan of the activity monitor in 2008 either – the graphic display is nice, but it seems super slow to load in my environment, and its quicker for me to launch a third party tool or run a few queries to get a quick health check on my systems. I’m sure there are others, but like I said, I tend to chalk it up to gaps in my knowledge rather than gaps in the toolset.

RM:

Which aspects of working with SQL get you really excited?

MR:

I like solving problems. I love sitting in a meeting or being part of an email thread and having that eureka moment when I see how some feature of SQL will solve a business challenge. Being able to use a tool that we’ve already invested time and money into to solve new challenges for the company really makes me feel like I am bringing value to the company. I also really enjoy knowing that no matter how much I learn there is always something else to dive into. I get very bored and discontent when I feel like there’s not something new for me to learn.

RM:

Is there any feature with SQL that you would like to take a hammer to?

MR:

I would happily take a hammer to SSIS sometimes. Specifically, the lack of 64 and 32 bit interoperability makes me crazy sometimes. I am constantly reminding my SSIS developers about all of the little caveats you have to remember when using a 64 bit install of SSIS. Unfortunately, due to other requirements most of our SSIS packages are run on SQL 2005 boxes, and the lack of 64 bit drivers is really painful.

RM:

Do you think people recognise the role of a development DBA?

MR:

I think some folks do – I know as a production DBA I certainly do, and have a ton of respect for good development DBAs. They can make or break an application in my opinion. A good development DBA can act as a bridge between operations folks and development folks – which isn’t always an easy task.

RM:

How would you make money from your skills if you weren’t in the job that you now?

MR:

I’ve always said that if I could make money reading books I would be happy for the rest of my life. I’ve been helping out with the Tribal SQL project that Jen McCown put together as an editor and I’ve really enjoyed it. I could happily work as an editor. Next up would likely be in a teaching role of some sort.

RM:

Who would you say has taught you most about SQL? Your mentor and guide if you will?

MR:

This is another tough one! Early on in my career this would be an easy question to answer – my only teacher was Dallas Orndorff, who taught me the basics and made me his backup DBA. These days I learn a ton from just about everyone I meet in the SQL Community. Some of the folks that have really made an impression on me in the last couple of years include Jason Strate and Ted Krueger who encouraged me to blog and present, Denny Cherry who is just a wealth of knowledge, Grant Fritchey who is one of the most humble and smartest guys I’ve met, Kathi Kellenberger who showed me that when you find your passion success is a natural outcome, Jes Borland whose excitement is infectious, and the list just goes on and on and on.

Now, even though I didn’t call it out specifically, each one of those people I mentioned taught me something about SQL Server – most often how to teach myself about one specific thing or another. I don’t think I’ve had a single mentor – I’m blessed to have an entire community of mentors and teachers.