Re: Trajectory of a [Pg] DBA

On 10/04/2012 03:44 PM, Thalis Kalfigkopoulos wrote:

> Is it more common to start as a developer and change focus to DBA? In
> particular how does one go about starting as a Pg DBA? Is the most
> common case by migrating from another DBMS?

You've already gotten a bunch of good responses from this thread, but I
figured I could add an anecdote or two of my own, since I didn't even
really know what a database was when I graduated in 1999.

You're probably going to get this story a lot, but quite a few of us
started as plain old developers. Not every company has a budget for a
database department, so it's not infrequent for a dev who's working on a
database-driven app to take over care and feeding of the database
itself. In 2001, that's exactly what I did with our PostgreSQL and MySQL
databases.

And I got myself into a lot of trouble fairly often. Not just because
PostgreSQL 6.5 would crash at the drop of a hat and corrupt data on its
way down, but because I only knew UNIX from a user's perspective. The
other responders are right, that to be a good DBA, you have to be
something of a Jack of All Trades. One of those trades in a UNIX
environment, is that it doesn't hurt to be at least junior-level as a
systems administrator.

So like many here, I picked that up out of necessity. And like many
here, I didn't stop at just keeping the database alive, but learning
more about it. It wasn't long before I noticed there was no reindex
script, and it was badly needed in those days. So I wrote one and
contributed it. That utility has long since been deprecated, but one of
the reasons we turn down so many applicants, is that they're
point-and-click DBAs with little to no understanding of what their tools
actually do.

And this extends into modeling, reporting, query optimization, and any
DBA related field you can imagine. The more critical the database, the
higher the TPS or larger the size, the more important it is to
understand the "why" as much as the "how."

This is one good reason a lot of people here are glad to have Greg
Smith's book on PostgreSQL performance. For the first time in a long
time, there was a good resource to point to, and say, "That's a good
place to start." And it is. But it's not the end goal.

That's what we look for in potential DBAs. We've turned down countless
senior-level DBAs because they interviewed as complacent, or
button-pushers who couldn't operate outside of a tool. But on the same
token, we've hired basic newbies who may have only had exposure in SQL
Server and never even held a role as a DBA, because they displayed an
ability to understand as opposed to regurgitate.

I've found we're not exactly unique in that approach. Having a good
resume focused on relevant DBA exposure certainly helps, but it's not
critical if a candidate can prove they're adaptable and won't crack
under pressure.

I actually kinda like how Cisco used to (and may still?) test for their
higher level certificates. Put the candidates in a room, and break some
random configuration or hardware element of the network gear. Watch
their approach to fixing it. I wish there was some kind of industry
standard DBA equivalent. :)

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas(at)optionshouse(dot)com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email