Re: Backup questions

Howard J. Rogers <howardjr_at_www.com> wrote in message news:3ab9c390_at_news.iprimus.com.au...
>
> <vikasa_at_despammed.com> wrote in message
> news:sl2ibt4pm54th4q8ig5be9jlcghs3luppb_at_4ax.com...
> > Would appreciate help with the following backup/recovery related
> > issues:
> >
> > 1. During online backup, when a tablespace is marked as BEGIN BACKUP,
> > any changes to that tablespae are recorded in the redologs. When the
> > END BACKUP is issued, does Oracle read the redologs and apply these
> > changes to the actual datafile(s) of the tablespace? Or does it just
> > stay in the redolog?
>
>
> I can't think why this one persists. It's utterly untrue. When a
> tablespace is in hot backup mode, only two things happen: CKPT is
 instructed
> not to update the header of the file in the tablespace with the latest SCN
> number (ie, the sequence number is artifically locked). That's so that
 the
> resulting image of the file, however the disk head grabs it, and in
 whatever
> order, nevertheless will appear to come in its entirety from the time of
 the
> *earliest* SCN extant when the backup began.
>
> Secondly, it's an instruction to generate before and after images in the
 Log
> Buffer of entire database blocks, so that block fracturing can be dealt
> with.
>
> In no way, and at no time, is it an instruction to prevent normal access
 to
> the datafiles themselves by the likes of DBWR. Updates, Inserts and
 Deletes
> take place absolutely AS PER NORMAL! The contents of a datafile in hot
> backup mode are therefore in constant, ordinarily flux. It's just the
> header of the file which is locked from updates.
>
> >
> > 2. After issuing a BEGIN BACKUP and during copying the tablespace's
> > datafile, there is a disk failure and the datafile is lost. How does
> > one recover in this case?
>
> One recovers as one normally would. By restoring the same datafile from a
> previous backup and applying redo to it via the 'recover datafile'
 command.
> I've never tried it myself, but theory suggests that before applying redo,
> one would also have to reset the bit in the Controlfile that thinks that
> tablespace is in hot backup mode by issuing an 'alter database datafile X
> end backup' command.
>
> >
> > 3. If I need to recover only a few datafiles and not the entire
> > database, I would do RECOVER DATAFILE <datafile>. What happens in this
> > case? Does Oracle ignore the redo entries which pertain to the other
> > datafiles?
> >
>
> Yes. But Oracle ignores the other datafiles anyway when they are not in
> need of recovery. Use 'recover datafile' to recover single files in need
 of
> recovery, and use 'recover database' when two or more files are in need of
> recovery. At the end of the day, both will work -but if two files are
 down,
> you will have to issue two 'recover datafile' commands before the database
> can be opened.
>

Compare to run 'recover datafile' twice with 'recover database', which way may be quicker?

> > Under what situation would I need to do ALTER DATABASE DATAFILE <file>
> > OFFLINE DROP?
>
> When the tablespace that's been stuffed is the TEMP tablespace, or when it
> is the INDEX tablespace, and you have determined that it would be easier
 for
> you to rebuild your indexes than to have them recovered. It's a way of
> saying "I want you to offline this file so I can get what's left of the
> database open, but I don't intend attempting future recovery on it, so get
> rid of it out of the controlfile whilst you're at it". It doesn't drop
 the
> *tablespace* entry, however, so that still needs to be dropped once the
> database is opened.
> >
> > Once I do this, how can I bring the datafile online again?
> >
>
> You can't. That's what "drop" means. If you simply want to offline a
 file,
> so that the database can be opened, and so that you can then perform
> recovery on a tablespace whilst the database is opened, just use the
> "offline" command. "offline drop" means you have no intention of
 recovering
> that file.
>
> Regards
> HJR
>
>
>
> > Thanks...
>
>
Received on Sat Mar 24 2001 - 11:54:49 CST