Re: Media recovery when using an old controlfile

Hi!

Some thoughts:

1. If your array supports write caching, are the cached writes written to all splits?
2. Do you split *entire* database atomically, that means all datafiles, redos and controlfiles? If half of db is taken at one time and second half is taken 1/100 seconds later you could easily have inconsistencies.
3. I've always put datafiles to backup mode before splitting. There is a command alter database suspend / resume which should disallow any writes during set, but it has several problems (such corruptions causesd by direct writes), so I don't recommend it. One good thing with splitting files in backup mode, you can use them for recovery later on (if copied away before opening)

Tanel.

"Jurjen Oskam" <joskam_at_quadpro.stupendous.org> wrote in message news:slrnbfjf8d.b9l.joskam_at_calvin.quadpro.stupendous.org...
> In article <WdhKa.1167$p8.43445_at_newsfeeds.bigpond.com>, Richard Foote
wrote:
>
> [ excellent explanation snipped ]
>
> > One word of warning here though is that because you didn't (I assume)
put
> > the tablespaces into backup mode, your copy of the database doesn't
quite
> > equate to a shutdown abort scenario. This is because a block as it's
being
> > copied could have a portion of it copied but then have DB Writer come
and
> > overwrite the remaining portion of the block. When this remaining
portion
>
> This is point I admittedly oversimplified in my original post. As you may
> have read in my previous post, the storage system prevents this situation:
> all I/O to the entire database is frozen, the copy is made (in the form
> of a mirror being split off), and then I/O continues. From the DB Writer's
> point of view, the copy of the entire database is made atomically.
>
> > When you quite correctly run your recovery statement, you have stated to
> > Oracle that the controlfile is not current and hence can't be used to
police
> > the required SCN of the *current* database. In other words you wish to
> > perform an incomplete recovery and recover the controlfile as well.
> > Therefore Oracle investigates the headers of the datafiles and
determines
> > which is the oldest, non read-only datafile as described in the control
> > file. This is the point (and the redo log sequence) from which we wish
to
> > recover the database. Assuming that the last completed checkpoint was
> > performed during the previous log switch, this means it's the current
online
> > redo that Oracle requires. That is, log 49428 is the current online redo
log
> > and as such can not possibly be archived.
>
> That is what I understood as well.
>
> > To recover the database, you must therefore copy the current online redo
log
> > across and *completely* apply all changes associated with this redo log.
>
> The online redo logfiles were part of the copy-by-splitting-off-mirror, so
> those are available on the second machine. Are you saying that instead of
> pointing to log 49428 (which doesn't exist as an archived log yet, but
only
> in an online redo log), I should point to /dev/rredo_log_volume? Will that
> work? How can I tell which online redolog volume to use? In that
particular
> database, there are nine online redolog files. Will Bad Things(tm) happen
> if I try to apply the wrong online redolog?
>
> > Make sense ?
>
> Yes, very much so! Thank you, and thanks to everybody who takes part in
this
> thread. It's really nice of all of you to provide such helpful and
detailed
> explanations. I'm not a DBA, but I am responsible for backup/recovery so
all
> this is excellent information with respect to Oracle backup and recovery.
>
> --
> Jurjen Oskam
>
> PGP Key available at http://www.stupendous.org/
Received on Wed Jun 25 2003 - 11:59:43 CDT