On Fri, Mar 04, 2005 at 06:07:19PM +0100, Paul Bijnens wrote:
> Last time I looked at doing backups of Oracle (Ora 6-7-8), I
> approached it as follows:  first set each tablespace in hot backup mode
> (alter tablespace TS begin backup) then doing a filesystem backup
> of all the directories with datafiles, using plain amanda DLE's,
> then setting each tablespace out of hot backup mode, (alter
> tablespace TS end backup);  then force a redo log switch (alter
> system switch logfile) and then doing a backup of the archived redologs.
> 

Ouch.  If that database is seeing any signifigant activity during the
backup, you're going to be generating *alot* of redo with that approach.
Putting the whole database in backup mode at once is typically frowned
upon unless you're using something like mirror splitting or snapshots
so you can turn backup mode off after a few seconds.

> Is Oracle 9-10 any different for "hot backup mode" (i.e. more
> complicated than it need to be?).

Not that I'm aware of.  alter tablespace begin backup is still there, and
reportedly they've added an alter database begin backup to put all tablespaces
in backup mode at once for the snapshot crowd.  RMAN is, however, the
preferred backup method these days - it's typically much faster than copying
the datafile, either cold or in backup mode, and doesn't cause the database
to generate additional redo the way backup mode does.

Currently, I run RMAN backups of our databases to disk, and let Amanda
pick up both the RMAN output and the archive logs.  I keep the last
three RMAN runs around, plus all archive logs that RMAN hasn't backed
up at least 3 times.  That way, even if the Amanda run overlaps the
RMAN run and a disaster occurs before the next time Amanda runs, I can
still restore from the previous RMAN run + archive logs.  Unfortunately,
this doesn't scale too well, since you need anywhere from 2-3 times
as much space for the RMAN output as your database + archive logs require
(and I've got nearly as much space taken by archive logs as I have datafiles).

For larger databases, I be inclined to go the alter database begin backup +
snapshot route.