Oracle-files (UNIX): raw devices VS filesystems

At the moment I am working on the configuration of some Oracle database (size 20-300 GB) on a UNIX-platform.

Till now I only worked with Oracle-files on filesystems. I'm wondering if it's wise to implement the new databases on "raw devices" (raw partitions).

I am familiar with the main advantages/disadvantages of raw devices. But it is difficult to make a decision (without practical experience).
Who is Participating?
mshaikhConnect With a Mentor Commented:
Sorry, if I came accross too strong. That was not my intention. No offence intended.

"I don't understand why Oracle Corp create "the raw way" if it is so bad as mshaikh says."

It was done to overcome:

1..  unix's inability to support large files in most earlier versions. Many unix
      OSs have added large file support but not all. With earlier hardware
      there was a 5-15% increase in performance. These days the hardware
      and OSs are much more efficient and the performance advantage of raw
      FS has decreased. These days, most hardware and OSs do file caching
      and thus can acctually cause diminishes performance with raw. Let me
      give you two situations.

      a..  Your i/o controller/subsystem does not have any cache and your OS
            does not handle file caching. Your processor is not very powerful and
            tends to peak often during high i/o activity. This is an ideal situation
            from raw FS to increase performance.

      b..  Your i/o controller/subsystem is loaded with 64 Megs or more of
            cache (split between read cache and write cache). You are reading
            and writing from cache: very, very fast. Data transfer to disks are
            handled by the subsytem (example at regular intervals or, when  
            the cache is full). Your OS also, does file caching (example solaris).
            Raw filesystem in this stiuation can acctually hurt you performance.

2..  To support parallel server as unix can't mount a partition on two

3..  To compete with Informix, which supported raw files. So that, Oracle can
      say "We have it too!"

I hope this explains why Oracle had to create the "the raw way"

As a DBA you will have other thing to worry about and keep you busy.

You are right about EBU. But, I personally don't prefer it. It is too slow backing up and too slow restoring. We have it. We switched to Veritas Backup Utility. Very fast, especially the incremental backups, so you don't backup everything everyday. Only the changes.
And yes you can add raw files to tablespace. But, again it is a limitation. Your choices are reduced. I guess if you plan well you would be okay. But, the way it often works out is increase this tablespace by a 5Gb today and if you fill it up I will give you more, otherwise I will save it for other tablespaces that might run out of space. I can't do that with raw files unless I shut the database down and mess this the partition table(risky stuff).

I think its factor of your work load.  Both you and the application.
From what I've read, you may get a 10-15% performance boost, but you have to manage the raw files, increasing you work load while lighten the servers.  If your running a data mining operation were transactions are running hours, 15% might be worth it.  I guess another example would be where 15% would give you a business advantage, stock exchange, save a life, ...  but it a tuning choice of last resort.  The increased manpower/risk has never been worth it for us.  We throw hardware at our preformance problems, after we grow tired of tuning the application.  Simply put, not enough bang for our buck.  

P.S. I assume you know you are I/O bound?
In my experience with raw devices, I have had two reasons to avoid them:

1.. It make database backup administration extremely difficult. Since, the OS cannot see these files, you can use any of the several backup tool out there. You cannot even use tar. You will have to use a command like dd to backup the filesystem.

2..  Management of files is extremely difficult as you cannot list, move or copy them. Also, you will have tough time if you want to resize the partition.

Depending on the version of your database and OS, you may find another way besides raw, if you don't intend to use parallel sever.

Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

Also, the issue of I/O speed is addressed in modern file-systems.

Take a look at:
vroedjeAuthor Commented:
Thanks for the reactions.
Till know I did not read new information.
Some more information about the system/application:
- I don't know if I'm I/O bound.
- I use a "fast" disk-configuration (FCAL, mirrors).
- My application is a mix of large reads, large writes and simple queries.
- My server is "big" (in memory and cpu).

I think I want to use raw disks to prevent an potential disk I/O bottleneck.
Okay. But remmeber, if you are using solaris, you probably won't get much out of going to row filesystem, especially if your Disk Array has caching capability. Actually, you performance can deteriorate. Also, I have been there done that. Trust me, it is not worth the headaches. Just think of the following things.
How are you going to resize your tablespace if runs out of room?
  Can't do it on the fly as in cooked partition. You will have to shut the   database down. Resize you partition at the hardware level and restart the

Moreover, How are you going to make backups?
  Can use any backup utility out there. You will be reduced to using unix's   'dd' command, which is painful.

Let's say one of your disks failed. Think of the steps involved in rebuilding the partitions. Are you going to remmeber the details of how the disks where partitioned and setup?
   With cooked files only the mount point and partition size matters so
   restoring from a lost drive is easy. Restoring to a cooked filesystem will be
   a lot faster

Your question was:
"I'm wondering if it's wise to implement the new databases on "raw devices" (raw partitions). "

The answer is no. The most compelling reasons are reduced managability as discussed above.

Raw partition make sense if:

1.. You want to run Parallel server, or,

2.. You are on a Unix flavor that does not support large files and want to have large files.
Sorry, in the previous comment

"Moreover, How are you going to make backups?
   Can use any backup utility out there. You will be reduced to using unix's
   'dd' command, which is painful."

should be:

"Moreover, How are you going to make backups?
   CanNOT use any backup utility out there. You will be reduced to using
   unix's 'dd' command, which is painful."
vroedjeAuthor Commented:
Some more facts:
- Operating System = DG/UX (DataGeneral) (which supports large files)
- Disk Array = EMC-CLARiiON (full Fibre Channel with cache)
- I don't use Oracle Parallel Server

Mij reaction on the remarks from mshaikh:
- resize tablespace: by adding another datafile on a raw partition I can enlarge a tablespace
- backups: with the Oracle Enterprise Backup Utility (EBU) (this utility doesn't have problems with raw devices)

I don't understand why Oracle Corp create "the raw way" if it is so bad as mshaikh says.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.