Some guidance on RAW partition backup

[Nagarathinam]

Dear Hp experts,
I have HP-UX running with oracle8i OPS ( 8.1.7 ) running on my two node cluster. I am about to use the same for application deployment.
My questions are
1. How can I port the already functioning oracle applications which include datafiles, forms, reports,procedures,triggers etc., into raw partition ?
2. How I can do the backup of these on a regular basisin raw partition ?

Any help is welcome.
Thanks in advance

Naga

[Steven Sim Kok Leong]

Hi,

1) I am not sure you can port existing oracle datafiles on OS filesystems to raw devices/partitions at the OS level. You can however create datafiles on raw LVs/partitions ie. /dev/vgXX/rlvXX. Subsequently, perhaps you can just transfer the data over at the Oracle level.

2. HP Openview Omniback allows backing up of raw devices/partitions. I prefer to use it because it performs media management. At the OS level, you can use dd.

The caveats with raw devices/partitions are that:

1) at the OS level, they look like any other "unformatted" LV. Don't accidentally overwrite the raw partition by newfs'ing it.

2) To restore a file, you have to restore the entire raw partition. You cannot select a specific file to restore.

The advantage of course is the tremendous increase in I/O throughput.

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com

[David Navarro]

Hi.
1.I'm not an expert in Oracle, but I know that you can work with RAW datafiles, I don't know if that includes reports, forms, etc or not. I think, you need do an export then reconfigure oracle for use raw devices, then import into new devices.

2.Yes, you can do a backup from a raw device. If you have OmniBack, there's an option for do that. If you haven't any tool for backup's, then you can do this:
dd if=/dev/vg01/rlvol1 of=/dev/rmt/0m

That command read's the raw device, be carefull in using device file that begins with r, and then sends it to 0m tape or the tape you have. try with a different block size with option bs, backup would be faster.

I hope it help you

[Santosh Nair_1]

I don't believe there is any way to convert the existing datafiles on the cooked filesystem to raw filesystem. You'd have to export your data and then re-import them into a new database with the raw filesystems.

As for backing up, if you're doing cold backups, one approach would be shutdown the database and then dd all the raw filesystems. Alternatively you could use one of the commercial backup utilities. They all have hooks into Oracle for backups.

Hope this helps.

-Santosh

[Steven Gillard_2]

I've never looked after a database that used raw partitions, but I recommend you look at using RMAN for doing the database backups.

Simply backing up the raw partition with dd is going to require some significant downtime and space on your backup media. RMAN can be used to perform an online backup and will only backup Oracle blocks that are actually in use. I believe Omniback and Netbackup have some hooks into RMAN, or you can write some scripts yourself. Its not as hard as it first seems, trust me!

Cheers,
Steve

[Marco Paganini]

Hello,

You can easily convert your datafiles into raw devices. Just create a raw device that is the same size (or a little bigger) than your datafile. Copy your datafile to the raw device using:

dd if=datafile of=raw_device bs=block_size

This operation has to be done with Oracle shutdown!

After the operation, you can rename the datafiles using in oracle to point to the raw devices.

Backing up raw devices is a great pain in the neck. You have to use DD or a commercial product of some sort. You can always use oracle's export, but that's not exactly a physical backup.

Normally, raw devices give you a good increase in performance, however it may not be as much in some cases. I remember a very heated argument about raw-devices vs pre-allocated files. We ran a lot of tests on both situations and (at least at the time, in our architecture), the difference was 12% in favor of raw devices in *very specific* situations (average was only slightly faster). You may want to consider doing similar tests too to see if (in your case) it justifies.

Regards,
Paga

[Marco Paganini]

Geee...

Just re-read my last posting... Full of grammar errors... Awful! :) That's what posting in a hurry does to you boys! :)

Sorry there.

Regards,
Paga

[Nagarathinam]

Thank you all for your instant response.
I will come back to you after trying these .

Bye

Naga