Re: Backups using storage system mirroring/splitting

"Jurjen Oskam" <joskam_at_quadpro.stupendous.org> wrote in message news:slrnc1fi64.fa9.joskam_at_calvin.quadpro.stupendous.org...
> Hi there,
>[long snip]

> This works, and the only question I have about this part is why the
recover
> database command stops with the message "media recovery complete" after
> applying the appropriate online redolog file. I did say "until cancel"
after
> all?

It always says that at the end of an incomplete recovery. I suppose it should more properly say "The media recovery that you asked for is now complete", but it makes no difference in the end. It's not a problem, and isn't an issue.

[further snip]
>
> And now the problem that has me puzzled. In the above scenario, I
successfully
> recovered the split-off database by applying online redologs. The original
> database kept on running, on system A. This means, that sequences #5005
and
> #5006 would eventually be archived on system A. So, I think, the following
> sequence should work:
>
> 1 Perform the steps 1,2,3 and 4 exactly as shown above.
> 2 Wait until prod1 on system A generates the needed archived logfiles.
> 3 On system B, again issue "recover database using backup controlfile
until
> cancel", but now, instead of using the online redologs, use the archived
> logs from step 2.
>
> However, this doesn't work. I can apply the files, but it won't say "media
> recovery complete". Also, if I cancel the recovery and try to open the
> database (with resetlogs), it says that datafile #1 needs more recovery.
>
> I don't understand why applying the online redologs from system B *does*
> work, but applying the archived logs does *not* work.

Because how is system B's control file supposed to know that System A has generated 2 or 3 more archives?

If you were to produce the control file backup from system A after those archives had been produced, and if you then opened system B with that control file backup, and perform recovery, you stand a reasonable chance of getting system B to apply those 3 or 4 extra logs. But what you can never logically do is to get system B to apply the online redo from system A, because to be in the position to try, system B must be mounted (for recovery), and that means you have to have a control file, and there are always going to be some transactions generated in system A for a time after you copied the control file needed to get system B into the mount state.

I have to say as well that you are dicing with death by splitting mirrors like this (although I don't know the specific product you're using). The question is not one of data file inconsistency, which as you realise can be made good by applying redo. It is also one of data block consistency: if one part of a block changes whilst your splitting is taking place, then your mirror may have its image of one part of a block at a time different from the rest of that block. That's a fractured block, and can't be recovered.

One of the things 'begin backup' does is to say 'if you are the first to modify any part of a block, I will dump the entire block into the redo stream'. That way, there is a consistent block image in the redo on top of which subsequent normal redo change vectors can be applied. But you are forgoing that little bit of technology, and praying your splitting gets lucky.

So, what I'm saying is: logically, what you ask [about the online redo from A being applied to B] cannot happen. And secondly, I hope this isn't a production system because this is not a valid hot backup method.

Regards
HJR

-- 
------------------------------------
Oracle insights at www.dizwell.com
------------------------------------