Re: backup and recovery question

From: Jeremiah Wilton <jeremiah_at_wolfenet.com>
Date: 1998/10/14
Message-ID: <Pine.OSF.3.95.981014163324.12686L-100000@gonzo.wolfenet.com>#1/1

On Wed, 14 Oct 1998, Thomas Kyte wrote:
>
> A copy of this was sent to Tansel Ozkan <tansel_at_openix.com>
> (if that email address didn't require changing)
> On Wed, 14 Oct 1998 Tansel Ozkan <tansel_at_openix.com> wrote:
> >
> >I know that a backup of Oracle files for a open database
> >in NOARCHIVELOG mode will not startup the database. However,
> >I was not able to give a good explanation for the following
> >question:
> >
> >What is the difference between a
> >database started after a machine crash due to a power loss
> >and a database started with all Oracle files copied at exactly
> >same point in time for a database running in NOARCHIVELOG mode
> >and when the database is open.
>
> one of the differences is that you cannot INSTANTANEOUSLY copy all files at
> exactly one single point in time when the database is open.

It is possible on some filesystems, such as Digital's AdvFS, to make a point-in-time snapshot of data. This snapshot is valid with respect to a given point in time, and blocks are copied to this snapshot on write.

Also, many people break off a disk mirror and copy their database from
that, leaving their tablespaces in backup mode for only a brief moment. In
fact, it is conceivable that the brash among us could run in NOARCHIVELOG
mode, take such a snapshot of all datafiles, the online redologs and

controlfile, and call themselves done. Of course, they had better not want to recover that database beyond the newest online redolog in the snapshot, because there would certainly be no archived redologs for them to use. This would be like recovering from a machine crash at the time of the filesystem snapshot or raid mirror separation.

> A crash happens instantly. A copy is measured in somewhat longer timeframes.
> During the copy the files are getting horribly inconsistent with each other.
> Also, during this period of time, redo is being generated perhaps and if it
> wraps, we will reuse a redo file that perhaps one of the datafiles will need
> upon recovery (but we won't have it).

This is all true. In addition, block splits would result in inconsistent data blocks, and recovery wouldn't even know what point in time it should be recovering from, since a long copy process would read the file header at one point in time, then normal checkpoints would continue against that file as the copy progressed, leaving the user with datafiles with many baseline checkpoint SCNs, instead of one.

To be fair, the checkpoint and block split issue appliers during normal hot backups as well, but the full-block-image-logging and begin-backup-scn header entry resolve these problems during media recovery.

I don't even think a database in NOARCHIVELOG mode would ask for an archived redolog during crash recovery.

--
Jeremiah Wilton      http://www.wolfenet.com/~jeremiah

Received on Wed Oct 14 1998 - 00:00:00 CDT