Mike Delaney wrote:
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.
That's why you do it during the night...
And on Solaris I do use snapshots, which takes indeed a few seconds
only, for all the DLE's, not only the oracle datafiles.
Never "File changed while reading" messages anymore.
A pitty snapshots on Linux LVM2 does not work (yet). On some
older systems still running a 2.4.18 kernel and LVM1, I use snapshots
too (and MySQL instead of Oracle: a magnitude or two less in footprint,
and still suitable for the tasks I need.)
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.
Need to study again, I see...
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.
--
Paul Bijnens, Xplanation Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
|
