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

Home -> Community -> Usenet -> c.d.o.server -> Re: Backup questions

Re: Backup questions

From: Howard J. Rogers <howardjr_at_www.com>
Date: Thu, 22 Mar 2001 20:18:59 +1100
Message-ID: <3ab9c390@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.

> 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 Thu Mar 22 2001 - 03:18:59 CST

Original text of this message

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