Re: What makes a Postgres DBA? - Mailing list pgsql-general

On 11/4/07, Kevin Hunter <hunteke@earlham.edu> wrote:
> Following up on a recent thread
> (http://archives.postgresql.org/pgsql-general/2007-11/msg00064.php) ...
>
> Next question and one that I'm not sure how to phrase: how does one
> become a Postgres-savvy* DBA?  Just by working with it as a developer
> and then moving "up the ranks"?  (i.e working with larger, more active
> setups/datasets?)  There's the training options listed on
> http://www.postgresql.org/about/eventarchive, but I'm personally
> skeptical at just how much one can retain from a 1-to-5 day course.

I would suggest that in order for someone to get that most coveted of
titles 'PostgreSQL DBA' on should:

Administration:
* Understand tradeoffs of autovacuum and scheduled vacuum
(increasingly, this question will morph into autovacuum configuration
and monitoring)
* Understand backups: when to use pitr, pg_dump
* Basic configuration: shared_buffers, etc etc
* Be able to do task specific tuning: understand difference between
oltp and olap environments
* Be versatile with psql shell (most of the best DBAs use psql almost
exclusively)
* No how to troubleshoot and deal with locking problems and runaway queries
* Should be able to setup postgresql manually without using packages
* Be able to implement a replication technology (Slony)
* Understand some of the specific challenges involved in dealing with
large databases, which I define as over 10 times the memory in the
server.
* Understand the challenges involved with 24/7 environments
* Understand the differences in low and high security environments and
how to set up for both

Development
* Should be very comfortable with pl/sql, pl/plpgsql (pl/perl or
alternative is bonus)
* Understand triggers, views, functions, rules, constraints, domains
and type and be able to give examples of when they should be used (or
not)
* Understand good normalization strategies
* Be able to discuss pros and cons of surrogate keys
* Understand MVCC
* C language experience
* Strong familiarity with bash or perl (preferably both)

Personal
* A DBA often anchors a development team.  'Works well with others' is
a cliché, but still applies.
* At least superficially familiar with the technologies that interface
with the database
* Be cool and calm under pressure
* Be established on the appropriate mailing lists and use good etiquette
* Understand that developers are out to get your database

merlin