Raw DB Storage & Split Mirror Backups

[Alzhy]

A client is contemplating heeding an advice to convert to RAW. Split Mirror Backups are currently the norm wherein the split filesystems are mounted on to a backup server and pushed to tape periodically.

The split mirror process I envision will change very little - the DB instance (Oracle) will need to be shut down or in hotbackup mode and mirrors split. Tthe only difference is that since there's no filesystem on top of the raw volumes - there's no fscking or mounting - only importing of the raw volume elements onto a backup or diffferent server.

The DBA team however is skeptical - specially in a hotbackup/split scenario -- claiming the raw volumes after split are very susceptible to corruption (because "there is no filesystem on top and fsck will not work"!?).

For those who actually using RAW and split mirrors - are the DBAs allegations true? How do I actually convince them that it is safe since during hotbackup -- the raw storage are litereally read only so are unchangng. We have not gone ahead to do tests yet.


Thanks.

[Ninad_1]

Nelson,

The key to having a valid backup is dependant on the time when you split the mirrors and not if the data is on filesystem or not. If you split the mirror suppose when the data on filesystem is still not fully synced to the mirror then also you will have corrupt filesystem and I dont think that even fsck can correct such a problem.
So the key is to have a quisced volume - filesystem or raw so that the mirror can be split to have a valid data. Two methods are possible as you have mentioned - put tablespace in backup mode, split mirror
OR
shutdown database, split mirror.

Also depending on the backup software you are using you may not even need to mount a filesystem for taking backup, just import the VGs/ disk groups. so the fsck bit will only be useful if you are splitting filesys, mounting them and then taking backup - while mounting only if there is prob with filesys it will report whereas in raw you are assuming that everything is OK.

Regards,
Ninad

[Alzhy]

Thanks Ninad...

That's precisely my experience as well but you know how DBAs are and the fact that I am dealing with DBAs who do not really understand storage and filesystem and the OS and who do not even have any experience working with RAW.. (Ah.. the conversion process via dd is another hair-raising adventure...!)

Filesystem or not, DB storage needs to be quiesced by placing the instance in HotBackup, or suspend mode or cold.

I guess my only course is to prove and go through several gyrations..

BTW, what are your experiences with System Crashes and RAW Oracle storage.. that's another issue the DBAs are raising? In my experience, their susceptibility to corruptions are practically the same as Filesystem based...

[Pete Randall]

Nelson,

How is this going to be mirrored? And how, then, is it going to be split? Without file systems you can't use MirrorDisk so that leaves you with some form of hardware mirroring which has to provide some means to split the mirrors. I'm sure you've got this all worked out, but I'm confused.


Pete

[Alzhy]

VxVM. FlashSnap

or

HW Based Ones.. BusinessCopy, BCV, or trueCopy...

[Pete Randall]

OK, thanks - I knew you had it covered!


Pete

[Duncan Edmonstone]

... and the response to these DBAs is:

"so what happens when your server crashes? As your Oracle data is on raw partitions, does this mean they are corrupted? Obviously no, as Oracle is able to recover to a consistent state using redo - just the same as an fsck on a filesystem"

Of course this can be made to work. It's documented as working with Data Protector with RMAN and either XP, EVA or Symmetrix:

http://ovweb.external.hp.com/ovnsmdps/pdf/dataprot_55_allos_zdinteg.pdf

And I've done it myself the old fashioned way...

alter tablespace begin backup...

split the disk(s) that contain that tablespace

alter tablespace end backup...

for all tablespaces, then backup the splits somewhere else...

then backup archivelog, controlfile and pfile/spfile in usual way.

HTH

Duncan