Обсуждение: Trajectory of a [Pg] DBA
Hi all. I'd like to tap into the list's experience regarding the job of a DBA in general and Pg DBA in particular. I see that most of the DBA job posts ask for Sr or Ssr which is understandable given that databases are among a company’s most valuable assets, but it is also an obvious catch-22. So I'd like to ask the list's part- and full-time DBAs, if it's not too personal, how they landed their jobs. Is it an easier and more common entry point to be a part-time DBA e.g. perform DBA duties as part of being a U**X sysadmin? 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? TIA, Thalis K.
On Oct 4, 2012, at 1:44 PM, Thalis Kalfigkopoulos wrote: > Hi all. > > I'd like to tap into the list's experience regarding the job of a DBA > in general and Pg DBA in particular. > > I see that most of the DBA job posts ask for Sr or Ssr which is > understandable given that databases are among a company’s most > valuable assets, but it is also an obvious catch-22. So I'd like to > ask the list's part- and full-time DBAs, if it's not too personal, how > they landed their jobs. > > Is it an easier and more common entry point to be a part-time DBA e.g. > perform DBA duties as part of being a U**X sysadmin? > > 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? As somebody standing guilty of looking for a Postgres DBA for a while now and passing on many people, I think it's prettysafe to say the following..... We don't really care if you've worked as a DBA professionally or not, senior or otherwise. We do want to know that you canwork as a member of a team, under pressure, and understand about the evils of downtime, but you can get that from a lotof jobs. And obviously it's important to know the basics of being a DBA. You know, why we have indices, and when not touse them; why we have transaction logs and how they work; how a database might drive load on a system and how to choosehardware that will cope with that... basically, the stuff talked about on this mailing list all the time. :) But mostly what we care about - and this is where most people fall down - is how you learn. Do you absorb the minimum ofwhat it takes to get your task done, and then follow that procedure as long as you can? Or do you figure out the underlyingprinciples at work, so you can effectively go off-script? I can't tell you the amount of times people have toldme, "Yeah, I like to keep my server's load average under 3 as good rule of thumb" without any understanding of why. Whynot 10? Why not 0.5? They just don't know, and being a DBA is all about being ready to go off-script when something blowsup. So if you're looking to be a good DBA, read this list, and learn to understand things you don't understand. That should getyou further than most in an interview.
On Thu, Oct 4, 2012 at 2:44 PM, Thalis Kalfigkopoulos <tkalfigo@gmail.com> wrote: > Hi all. > > I'd like to tap into the list's experience regarding the job of a DBA > in general and Pg DBA in particular. > > I see that most of the DBA job posts ask for Sr or Ssr which is > understandable given that databases are among a company’s most > valuable assets, but it is also an obvious catch-22. So I'd like to > ask the list's part- and full-time DBAs, if it's not too personal, how > they landed their jobs. > > Is it an easier and more common entry point to be a part-time DBA e.g. > perform DBA duties as part of being a U**X sysadmin? > > Is it more common to start as a developer and change focus to DBA? That's what I did. Way back in the days of pg 6.5 I helped build a corporate intranet and as the senior architect of all of it, I had to learn both how to admin unix boxes and keep a postgres db happy. I later learned other dbs (Oracle, db2, and a few others) because we were constantly interacting with them as the corporate intranet system. While it's common for dbas to specialize a lot on dbs like Oracle (just performance, or development, or 24/7 operation and so on) most pgsql dbas are, by necessity, generalists. Management often hires a large team for a database with $500,000 in licensing without batting an eye, but when the db is free, figure they can get by with 1 or 2 DBAs max.
On Fri, Oct 5, 2012 at 6:44 AM, Thalis Kalfigkopoulos <tkalfigo@gmail.com> wrote: > Is it an easier and more common entry point to be a part-time DBA e.g. > perform DBA duties as part of being a U**X sysadmin? > > 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? I work for a (very) small company, so by nature we're all generalists. I basically got the DBA job charlieocratically[1] - that is, I was pushed into the position, having been the primary apologist/evangelist for Postgres. My main job is software developer, but of the team who write database access code, I'm the one who generally (a) is the go-to guy for schema advice, and (b) gets asked to ensure that the database will perform adequately under crazy load on crazy hardware. (And just FYI, everything said on this list about Amazon EC2/EBS performance is right; a mid-range Dell laptop can outperform an Amazon Micro instance, and the fatter instances still don't do all that well, bang-for-buck.) Be good at databasing, then get any sort of IT job, and you'll likely end up being or helping the DBA. [1] See my blog for a definition of that term: http://rosuav.blogspot.com.au/2011/11/world-is-full-of-charlieocracies.html ChrisA
On Thu, Oct 04, 2012 at 05:44:54PM -0300, Thalis Kalfigkopoulos wrote: > I see that most of the DBA job posts ask for Sr or Ssr which is > understandable given that databases are among a company’s most > valuable assets, but it is also an obvious catch-22. So I'd like to > ask the list's part- and full-time DBAs, if it's not too personal, how > they landed their jobs. > > Is it an easier and more common entry point to be a part-time DBA e.g. > perform DBA duties as part of being a U**X sysadmin? That's an excellent way to become experienced in any database system, but particularly Postgres. I'm not a DBA these days at all, but I guess I was a fairly senior one when I still had that sort of job. I landed my job (at what became Afilias) by having a clue what a Postgres was. Before that, I'd worked on some projects in other jobs where I'd used Postgres, so I had a little bit of knowledge about how the system worked, and I had a reasonable depth of knoweledge about how its environment worked. It's this combination that is rare. A difficult thing about hiring DBAs to work on Postgres, I found, is the frequency with which people with database backgrounds want the database engine to be in charge of everything. Postgres is really dependent on the services of the underlying operating system in a way that many other comparable RDBMSes are not (or try not to be). It's this sort of understanding of the way multiple parts of the system can work together that I was always looking for in a hire. I usually had to hire people who'd mostly worked with other RDBMSes, but who liked Postgres for some reason and could tell me why. I never used automatic tools to match employees to my job descriptions, however, because I thought that they depended too much on keywords. It's easy to use keyword whittling on Oracle DBA hires: you just look for a magic number of years and the right certification, and you probably have a competent (but likely not stellar) candidate. If you try to find people with 5 years' Postgres experience, well, come to this list :) The shallow pool of qualified Postgres admins remains one of the costs of using Postgres today: you add cost to your administration. I think the cost is worth it, note. Hope this is helpful. Good luck, A -- Andrew Sullivan ajs@crankycanuck.ca
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@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email