Re: Media recovery when using an old controlfile

In article <3ef99fde$0$5429$afc38c87_at_news.optusnet.com.au>, Arcangelo wrote:

> As to the original poster's question, I can't tell. He says he did a 'sort
> of' shutdown abort, but that actually consisted of copying the datafiles!!

I'll try to describe what I did:

• On machine A, a database named prod1 runs, using raw logical volumes. Each raw logical volume consists of three copies on separate disks in the storage system. All the datafiles, controlfiles, online redo logs, etc. are on raw logical volumes.
• A copy of the controlfile is generated in /db/copy-controlfile
• The storage system splits off a mirror, reducing the 3-way mirror to a 2-way mirror. It does this by suspending I/O to all database volumes at the same time, splitting off the third mirror, and then resuming I/O to the remaining database volumes. This takes about a quarter of a second, during which the database keeps on running.
• The split off mirror is attached to machine B. This means that all the database files as they were at the time of the split are now available on machine B.
• The backup of the controlfile generated in step 2 is copied from machine A to machine B.
• On machine B, the control_file parameter is set to the backup controlfile from the previous step.

As I understand it, this results in datafiles that are further in time than the controlfile. I'd like to start the database on machine B using the backup controlfile. I failed to do this, with the symptoms as described in my original post.

> Don't even pretend to know how a copy can look like a shutdown abort.

You're right, I shouldn't. But, as far as the split-off datafiles are concerned, they could just as well be the result of a system crash: at time T-1, they were being written to/read from by the Oracle instance, at time T they were suddenly (and all at the same time) stopped being written to/read from by the Oracle instance. From the split-off copy's viewpoint, the Oracle instance just disappeared. My assumption was that this is equivalent to a SHUTDOWN ABORT. Since I don't *exactly* know what SHUTDOWN ABORT does, this assumption was not justified.

> Anyway: the error 'but OPEN RESETLOGS would get error below ORA-01194: file
> 1 needs more recovery to be consistent' invariably means that not all
> datafiles were restored for the purposes of an incomplete recovery.
> Therefore, a (or possibly several) datafile(s) is/are at a time ahead of
> where the incomplete recovery is halted, and since they can't be rolled
> backwards in time, the database is doomed to be forever inconsistent.

As I said above, I failed to start the database using the backup controlfile created in step 2 above. However, after I changed the control_file parameter (on machine B) to the split-off controlfile (the result from step 3 above), the database could be started with a simple STARTUP command, nothing else needed. With the backup controlfile the database failed to start up, with the current controlfile no problems whatsoever were encountered, with exactly the same datafiles.

-- 
Jurjen Oskam

PGP Key available at http://www.stupendous.org/