Search Postgresql Archives

Re: What makes a Postgres DBA?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Merlin Moncure wrote:
On 11/4/07, Kevin Hunter <hunteke@xxxxxxxxxxx> 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.)


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
      message can get through to the mailing list cleanly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux