Re: What makes a Postgres DBA?

The bigger danger is hiring an *Oracle* Financials or *Oracle* Manufacturing
person to become a DBA because they have 'Oracle'
on their resume
This is the most comprehensive analysis of DBA requirements I have seen thus
far
For myself I'm not tied to any specific Database having worked in mySQL and
Postgres this year but I do lean towards Oracle as I know it has the raw
horsepower to accomplish distributed transactions in their entire suite of
DB Product offerings (also I was an Oracle DBA in years past)
The questions on a DBA should add
1)what is a cluster
2)what is a borken chain?
3)when are Btree indexes used
4)Tell me how to performance optimise a multiple condition predicate using
the principles of boolean logic

Thanks Greg
Martin--
----- Original Message -----
Wrom: DDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZ
To: "Kevin Hunter" <hunteke(at)earlham(dot)edu>
Cc: "Postgres General List" <pgsql-general(at)postgresql(dot)org>
Sent: Sunday, November 04, 2007 4:18 AM
Subject: Re: [GENERAL] What makes a Postgres DBA?

> On Sun, 4 Nov 2007, Kevin Hunter wrote:
>
> > Am I assuming too much already by not defining what a DBA is in general?
>
> Probably. I'd startby looking at the list of DBA duties at
> http://en.wikipedia.org/wiki/Database_administrator and considering which
> of those are database-specific for a second.
>
> Two examples of the extremes here. "Installation" is a very product based
> thing. I assure that even if you can know everything in the world about
> how to install every other type of database system, you might still fail
> miserably to bring a new Oracle system up. On the opposite side, most of
> the work for "data modeling" is very similiar for any SQL-based database.
>
> I like to think of this as a grid. Across the top I put the various tasks
> DBAs work on. Vertically I go from generic to specific knowledge at
> various levels. Consider the task of deleting data from a table. I'd
> classify understanding of that subject like this:
>
> -generic new DBA: can use DELETE properly
> -experienced DBA: understands how dead rows get left behind by deletes
> -generic expert DBA: can comment on whether the expected balance of
> insert vs. delete operations will impact the optimal B-tree fill factor
>
> -new PostgreSQL DBA: knows to run VACUUM to clean up dead rows
> -experienced PG DBA: tunes autovacuum and monitors/adjusts the FSM
> parameters to keep dead rows under control
> -expert PG DBA: runs reports against pg_stattuple to instrument vacuum
>
> > "what do I need to able to do to be able to honestly say that 'I am a
> > Postgres DBA' on my resume"
>
> Organizing things as above, this turns into a somewhat fuzzy question
> about how much of the grid one has to cover before achieving that goal.
> Consider this; who will be more effective as a PostgreSQL DBA:
>
> -A person with many years of large-scale DBA experience with another
> database, but who just starting using PostgreSQL a few months ago
>
> -Someone who has been using PostgreSQL for a few years but only on small
> projects
>
> There's understanding the breadth of this field, and there's knowing some
> depth about each of the topic, and the exact mix of the two varies from
> person to person. There's so many aspects to this type of work that
> drawing a line and saying "if you know X, Y, and Z you can consider
> yourself a Postgres DBA" doesn't make a lot of sense. You mentioned
> training and certification. Part of the value of going through either of
> those is that you end up with some baseline idea of what someone who has
> gone through the class/test has been exposed to.
>
> --
> * Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>