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
