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@xxxxxxxxxxxxx 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
