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@xxxxxxxxxxxxxxxx ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
