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

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.

As others have mentioned you should at first concentrate on backup/restore procedures, and then on the general system maintenance (such as space usage, index maintenance, etc).

I don't know PostgreSQL, but for Sybase there are a few "standard" operations that you'd need to do, such as full db dumps, transaction dumps (i.e. incremental dumps), index statistics maintenance, database consistency checks, and table reorg operations.

All of these can be easily automated via simple perl (or shell) scripts.

Michael

I administered a SQL Server 6.5 system for a while. The built-in archiving tools were adequate, and our database fit on a single DAT tape, allowing archiving to run fully automated. All I had to do was remember to swap tapes.

I think you've just discovered why there are people who's job title is "Database Administrator". MySQL and Postgresql are relatively easy to administer, but all the big commercial databases can get fairly involved, as you tune performance and try to get smoother backups (you can get fairly deep into the free ones, too).

I'm a developer and sysadmin who's gotten dragooned into being the DBA, and I have to say that DB2 is just as complex as the OS it runs on - only the defaults aren't as good. Having watched the DBA's at other places, and talked to people using other RDBMS's I'm pretty convinced that all the commercial ones are fairly rough in their own way.

As for having to tweak the OS, well, it seems to me that Un*xes tend to ship configured for people running lots of small programs, so you end up doing a bit of reconfiguring in order to run something big like an RDBMS. And the more you try to do with it, the more tweaking you need.