There are three valid recommendations, depending on your situation:
- If you have a period of relative inactivity, the simplest thing is to
check the log sequence, put all the tablespaces in hot backup mode, copy all
the database files, end backup on all the tablespace files, checkpoint,
switch logfiles, check the log sequence, copy all the archive logs required
to the backup set, backup controlfiles binary and to trace, and copy them to
the backup set.
- If things are flying during your backup, one tablespace at a time is
better but slightly more complicated.
- If you have complusive tuning disorder (or a really challenging situation
that needs everything it can get and for some reason you're not on RMAN
yet),
then you forecast activity within files at times of the day, begin backup on
each tablespace when activity is lowest on one of it's files, copy that
individual file, and get out of backup for that tablespace, and repeat this
for each and every FILE at the time you have forecast activity is least for
that file. Of course this adds significantly to the book keeping to track
what you need to recover a given file. I've never seen this level actually
materially useful compared to the extra complications, but I have measured
it. Usually it turns out that almost all the insert/update activity is in
the last file of a tablespace, so all you have to do is avoid maintenance
delete windows and the extra blocks for going tablespace at a time rather
than file at a time is minimal. (And try to pick the time when activity on
the tablespace overall is least, but even that is usually subordinate to
scheduling time slices on the tape drives. So the real answer is get enough
disk for two alternating online backups so you always have a recoverable
backup on line. Then the tape jobs are from backup to tape, so who cares
when, and those get shipped off site and you don't get the really annoying
problem of having to wait for tapes to be retrieved from off site before you
can start a recovery.) Oh -- if your management balks at the 2x, you can do
a magic trick with a little extra work and tell them you can get it down to
1x plus the size of the largest file and you should never need to reload a
tape other than testing your offsite recovery.
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Mark W. Farnham
Sent: Thursday, September 23, 2004 8:26 AM
To: oracle-l_at_freelists.org
Subject: RE: Online Redo Log During a Hot Backup
2. What is the recommended procedure of taking the database in backup up
mode, I mean put all tablespaces in backup mode at once or one tablespace at
a time?
--
http://www.freelists.org/webpage/oracle-l
Received on Thu Sep 23 2004 - 07:54:56 CDT
