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

Merlin Moncure wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>
An excellent summary !

I would add that the core of being a DBA does have some platform
independent aspects. I took some introductory Informix classes years ago
on data normalization and the like, which combined with some long-ago
computer science classes (data structures, mostly) at UCB to help
broaden my understanding. And a lot of OJT and other classes since then,
of course.

Some of the issues that are general (but which require understanding of
each platform's unique aspects). All of these tend to be more meaningful
the more you understand about the domain as a whole. Merlin noted them
but they are pillars on which a lot of useful databases can be built.

* data normalization -- what data goes where

* indexing -- what it does, what it helps, what it doesn't help

* referential integrity and why it matters (and when it doesn't)

* authentication and access issues

* locking and related issues

* backups and safety nets

I particularly like your last points, Merlin, on developers. I've been
on both sides of the fence and databases are a specialized animal that
usually needs specialized care. Being able to work well with designers
and developers is crucial in delivering a useful end result.

Greg Williamson
Senior DBA
GlobeXplorer LLC, a DigitalGlobe company

Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information and must be protected in
accordance with those provisions. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

(My corporate masters made me say this.)