Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: tablespaces in backup mode

Re: tablespaces in backup mode

From: D. Alvarado <laredotornado_at_zipmail.com>
Date: 18 Mar 2004 07:45:34 -0800
Message-ID: <9fe1f2ad.0403180745.5d43481f@posting.google.com>


Thanks for this thorough answer. -

Brian Peasland <dba_at_remove_spam.peasland.com> wrote in message news:<4058D122.5D48E5F2_at_remove_spam.peasland.com>...
> D is the correct answer because you want to take tablespaces out of
> backup mode, then switch the redo logs. After you switch the redo logs,
> the archiver will archive that recently-active redo log. You can then
> copy all of your archived redo logs off to tape along with your hot
> backup files.
>
> Think about it the other way, what does switching the online redo logs
> do for you if you do it before you take the tablespace's out of backup
> mode? It does nothing as log switches can (and sometimes will) occur
> which the tablespace is in backup mode anyway! So forcing another log
> switch while the tablespace is in backup mode doesn't change a thing.
>
> You don't have to force a log switch. It is not a requirement. It just
> makes things "cleaner".
>
> > A. Switch online redo logs, back up control file to trace, and take
> > tablespaces out of backup mode
>
> Not correct because the log switch is forced before backup mode changes.
>
> > B. Back up control file to trace, switch online redo logs, save backup
> > control file and redo logs to tape
>
> Not correct because you never take the tablespaces out of backup mode.
>
> > C. Take binary copy of control file, take tablespaces out of backup
> > mode, dismount database
>
> Not correct because you would not dismount the database. In fact, you
> can't issue a command like ALTER DATABASE DISMOUNT.
>
> > D. Take tablespaces out of backup mode, back up control file to trace,
> > switch online redo logs
>
> All that is left.
>
> The backing up of the control file to trace in this case is a
> red-herring. You can backup to trace at any time since the trace file
> doesn't contain any information about the current SCN, etc of the
> database.
>
>
> HTH,
> Brian
>
>
>
>
> --
> ===================================================================
>
> Brian Peasland
> dba_at_remove_spam.peasland.com
>
> Remove the "remove_spam." from the email address to email me.
>
>
> "I can give it to you cheap, quick, and good. Now pick two out of
> the three"
Received on Thu Mar 18 2004 - 09:45:34 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US