Showing results for 
Search instead for 
Did you mean: 

Raw Partitions


Raw Partitions

HI there
I have worked with file systems and volume managers for Oracle on HP UX11.11.
Now I have been proposed to use 'RAW PARTITIONS' for oracle rac.
Could some one tell me how I could manage Raw partitions? Increase size / decrease size online etc. How complicated is this etc....Instead of Raw partitions can I still use file system concept.
steven Burgess_2
Honored Contributor

Re: Raw Partitions


You can use either and may find this discussion interesting

raw volumes are managed using the lv commands

man lvcreate
man lvreduce
man lvextend


take your time and think things through
Bill Hassell
Honored Contributor

Re: Raw Partitions

Raw partitions are actually easier in some ways to manage, especially changing size. Since there is no filesystem, you can increase or decrease the lvol at any time. HOWEVER: there is nothing that will question you about making a mistake! If you reduce a raw volume, there may be data that has just been chopped off at the end, so you'll have to use lvreduce (and lvextend) rather carefully (with your Oracle DBA's advise). Also, extending a partition often creates gaps in the lvol which can sometimes create a performance impact (no different than a filesystem though). And without a filesystem, it is often easy to 'lose' a production raw volume, especially if you use default names like lvol1 lvol2 lvol3... And finally, all of your backup choices just got reduced because tar, cpio, pax, fbackup, etc do not backup a raw partition. Don't tempted to use dd except for testing. You need a quality backup solution that can recover from tape problems and port to other systems.

Bill Hassell, sysadmin
Sridhar Bhaskarla
Honored Contributor

Re: Raw Partitions


If you drop the *fs* commands on LVM, then they are raw logical volumes. For ex., to create a raw logical volume only do until 'lvcreate' command. Don't run newfs on it. Similarly for increasing the size 'lvextend' alone is sufficient. I wouldn't suggest decreasing the sizes. To copy data from one raw partition to another, you can use 'dd' command. Make sure to change the permissions of your /dev/vgxx/r* files to oracle:dba and keep track of the permissions. Unlike filesystems, you cannot see data on raw logical volumes as it is directly managed by oracle. So, be extra careful while managing these volumes.

You may be disappointed if you fail, but you are doomed if you don't try
Volker Borowski
Honored Contributor

Re: Raw Partitions

I think the "ease of administration" for filesystembased oracle DBs is a myth.

Beside a Sandbox, where everything is mixed up in the same filesystems, you will not like to have i.e. a Webserver-Home-Directory on a disk where Oracle-datafiles reside. So you need to organize your disks in any way, no matter if you use raw or fs. May be raw devices force you a bit more to stay to it.

So instead of putting datafiles to filesystems, create a directory, where you create symlinks to the raw-devices as needed.


lvcreate -n lvdata2 /dev/vgdb1
lvextend -L 500 -n lvdata2 /dev/vgdb1 /dev/dsk/disk_to_be_used
ln -s /dev/vgdb1/rlvdata2 /oracle/DB1/rawlinks/data2
chown oracle:dba /dev/vgdb1/rlvdata2
chmod 600 /dev/vgdb1/rlvdata2

Now the symlink is ready to be used for a 500M datafile.

alter tablespace data add datafile '/oracle/DB1/rawlinks/data2' size 500M;

In case you want to resize, you need to extend the lvol first and resize the datafile after that. So autoextend features are a bit limited.

Hope this gives you an overview on how to handle it.
Karthik S S
Honored Contributor

Re: Raw Partitions

Refer to this thread,

-Karthik S S
For a list of all the ways technology has failed to improve the quality of life, please press three. - Alice Kahn
Steven E. Protter
Exalted Contributor

Re: Raw Partitions

There have been a number of threads on this topic, including one by me.

A. Clay Stephenson actually took the time to do performance testing raw versus filesystems.

Back on 10.20 and 11.00 there was a substantial boost going raw. Not enough to convince me to bother under 11.11 though.

For what its worth. The thread is on the first or second page of my itrc profile.

Steven E Protter
Owner of ISN Corporation
Brian Crabtree
Honored Contributor

Re: Raw Partitions

Managing raw partitions are not that hard. vgcreate, lvcreate, and lvextend are the commands that you will use.

However! When you are using RAC, the volume groups are set in a shared mode. So, any changes made to the volume groups have to be replicated to the other systems using vgexport/vgimport. Also, the volume group cannot be modified in a shared mode, it can only be done in exclusive (which requires the volume group to be deactivated and reactivated, so the DB has to be down for the volume group).

My recommendation is to use ALL of the space in a volume group when adding it to the database. Any space that is not used in a volume group will not be available for use in the database without downtime for the database.

There are some cooked filesystems that can be used with RAC. Veritas Cluster is one, and I believe there are a few others. The LVM partitions with HP-UX need to be raw to be used.


Robert Binkhorst
Trusted Contributor

Re: Raw Partitions


We did some performance tests recently, and these are the results. Keep in mind that this IS a test done with Sybase on HP-UX 11.11, rp5470 machine with a DS2300 disk system. These results won't be the definitive answer to your question as there's Sybase involved, but they can be used as an indication.

Blocksize raw fs
4096k 2,53 2,31
1024k 2,55 2,48
512k 2,08 3,55
256k 2,16 4,67
128k 2,63 0,32
64k 4,46 0,32
32k 8,12 0,32
16k 15,41 0,33
2k 117,67 0,71


linux: the choice of a GNU generation
Hein van den Heuvel
Honored Contributor

Re: Raw Partitions

Thanks to lvm (the lv/vg tools) Raw partitions are just about as easy to manage as files. Everything except Oracle's autoextent to grow datafiles automatically. You solve that by manually adding datafiles (pointing to raw devices) to tablespace where needed.
I woudl not think in terms of growing/shrinking. More adding/deleting.

If at all possible I like to do an initial load/setup with autoextent filesystems and then move (export/import, or dd copies) to reasonably sized raw devices when most data is available for ultimate performance or RAC needs. In such process I tend to retain the filesstem 'addresses' for the datafiles and just softlink them to the new underlying raw devices. This gives me a level of indirection I find useful, but which also can be obtained through smart/clean logical volume name choices.


Please explain a little more about your test output to allow us to appreciate the data provided. Is more better or worse? What is your conclusion for the specific test? filesystems mostly better? How would you characterize the test reported? Like a copy? Like and OLTP taks? Like a BI report task?
What are the units reported (seconds elapsed!?). Was there anything else worhth observing (like cpu/system time versus wallclock time).
Robert Binkhorst
Trusted Contributor

Re: Raw Partitions

Hi Hein,

You have a very Dutch name for someone living in the States. Are you an expat or do you have adventurous parents/ancestors?

Anyway, please see the following thread where this is discusses as well.


linux: the choice of a GNU generation
Hein van den Heuvel
Honored Contributor

Re: Raw Partitions

Thanks. That does explain it very well.
It makes it perfectly clear that the provided data is meaningless for the problem being discussed.

The deal with raw devices is NOT that they make IO faster. They don't (not directly). It is that they decrease system time, and buffer space wasted on bouble-buffering IOs (both in Oracle and the system).
A measurement of cpu(system) time might have shown that effect.

The better way to accomplish this is 'direct IO' currently available very nicely in Tru64, and being worked on to integrate with the AdvFS/Cluster filessystem in hpux (we have a very early version running since last week. Promissing, but still far out for customer usage).

Anyway it is all a moot point as for this discussion the customer just about _has_ to use raw devices to satisfy Oracle RAC requirements.

[Ja, geboren en getogen brabander. Ik was er vorige week nog. Ik moest tog naar de kapper, en het was carnaval en zo. Met vriendelijke groetjes, Hein)


A. Clay Stephenson
Acclaimed Contributor

Re: Raw Partitions

Let me give you one more hint when using raw devices with Oracle. Do not use the raw device nodes themselves (e.g. avoid /dev/vg02/rlvol1) but rather use symbolic links (e.g. /oradata/user01.raw) that point to the actual raw device nodes.

Thus, for example, from Oracle's perspective, you would use /oradata/user01.raw
but you would create a softlink
ln -s /dev/vg02/rlvol1 /oradata/user01.raw.

This little bit of indirection adds negligible overhead but it allows you to easily change the physical location of the data with no changes to Oracle. You simply change the link. It also makes it much easier to move the database to a new platform. The benefits are even greater if you are using actual physical disks rather than LVM. You also get a little bit of self-documentation via the ls -l /oradata command.
If it ain't broke, I can fix that.

Re: Raw Partitions

Some others have been telling me to use Veritas Cluster Volume Manager with RAW partitions. Any advise on this...