in reply to Sysadmin Aspects of DBMS

i've worked with PostgreSQL and MySQL extensively and lately i've been doing a lot with DB2.

i've never really had any problems with either postgres or mysql on linux. both installed easily and worked fine right out of the box. DB2 (on linux and solaris) has been a royal pain in the ass in every way imaginable.

as far as maintenance, pretty much all you should need to do for postgres is a nightly vacuumdb (for performance). also keep in mind that DBMS's often have special requirements for backups. sometimes just backing up the binary data files isn't good enough. to be safe, i run a pg_dumpall every night before the backup scripts run. this writes a copy of all the data out to a text file that you can use to restore things pretty easily. of course, i work with a bunch of really small databases; this might not be such a good idea on really big databases.

basically: postgres and mysql are both pretty easy to admin as far as databases go as long as your needs are fairly simple. if you're working with enormous databases under heavy load with all kinds of unusual requirements, i'm sure you'll spend a lot more time admining the DB than you'd like but that's going to be true no matter what DBMS you use.

(plus, i believe O'Reilly is coming out with a postgres book very soon. joy.)

anders pearson

Replies are listed 'Best First'.
Re: Re: Sysadmin Aspects of DBMS
by jlongino (Parson) on Nov 24, 2001 at 02:31 UTC
    Thanks Thraxil,
    This is just the type of info I was hoping for. I did some dbadmin stuff way back in '86 (?) for oracle on an IBM 4341 and it had similar maintenance requirements.

    My applications won't be large scale, but they will be moderately complex (employee demographic/deparmental info) requiring multiple related tables. The user load will be small (<=6 users). I will be exporting/dumping the composite data regularly to text files anyway since several applications hang off this data and it will take some time to convert them all to use the database. Most of the tables will be refreshed weekly from text files anyway.

    I'll be looking forward to the O'Reilly book.

    --Jim

      "[R]equiring server installations..." I can only imagine you're used to working with flatfiles from that line ;). I'm mainly going to mirror Thraxil here, I've worked with Oracle, DB2, and PostgreSQL extensively and PostgreSQL does have a rather light maintenance load.

      How much work needs to go in will of course depend on your load, dataset, and the equipment you're running on. For many the defaults will be sufficient. Personally, even for light loading, I like spending a bit of extra time on install and tweaking everything to the hardware. Obviously you can do quite a bit partitioning, managing tablespace, etc. but

      From the sound of your data/load setting up a couple cron jobs and applying the occasional patch will probably be all the sysadmin work you'll need to invest in it. VACUUM and VACUUM ANALYSE (or the command line wrapper vacuumdb as noted by Thraxil) and some backup cron jobs will probably be the extent of your involvement.

      If you're going to be the DBA as well then an occasional audit of expensive queries (using EXPLAIN) and indices maintenance will often prove fruitful; though not required unless you're experiencing poor performance. Again, this is based on what you've said of your application.

      To get a peak at the O'Reilly book before it's published (or to preorder), Command Prompt (the writers) have it online here. Bruce Momjian's PostgreSQL: Introduction and Concepts is also available online. And you can of course always read the official Administrator's Guide.

      P.S. You may want to ask the editors to put an [OT] in the title of the post.
        Actually that does seem a silly question in retrospect if talking about DBMS. And you're somewhat correct in assuming most of my Perl/database work has been with flat files, but I have done quite a bit of work with pure MS Access (regrettably). I was thinking of cases like Access where you can do what's necessary via ODBC/DBI without needing MS Access installed (provided your database file is already created).

        Thanks for the links.

        --Jim