Oracle-files (UNIX): raw devices VS filesystems

Posted on 2000-03-17
Last Modified: 2010-05-18
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).
Question by:vroedje
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Expert Comment

ID: 2628722
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?

Expert Comment

ID: 2629224
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.


Expert Comment

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

Take a look at:
Creating Instructional Tutorials  

For Any Use & On Any Platform

Contextual Guidance at the moment of need helps your employees/users adopt software o& achieve even the most complex tasks instantly. Boost knowledge retention, software adoption & employee engagement with easy solution.


Author Comment

ID: 2635201
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.

Expert Comment

ID: 2636456
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.

Expert Comment

ID: 2636469
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."

Author Comment

ID: 2636578
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.


Accepted Solution

mshaikh earned 90 total points
ID: 2637150
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).


Featured Post

PeopleSoft Has Never Been Easier

PeopleSoft Adoption Made Smooth & Simple!

On-The-Job Training Is made Intuitive & Easy With WalkMe's On-Screen Guidance Tool.  Claim Your Free WalkMe Account Now

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Working with Network Access Control Lists in Oracle 11g (part 2) Part 1: Previously, I introduced the basics of network ACL's including how to create, delete and modify entries to allow and deny access.  For many…
Have you ever had to make fundamental changes to a table in Oracle, but haven't been able to get any downtime?  I'm talking things like: * Dropping columns * Shrinking allocated space * Removing chained blocks and restoring the PCTFREE * Re-or…
Via a live example, show how to restore a database from backup after a simulated disk failure using RMAN.
This video explains what a user managed backup is and shows how to take one, providing a couple of simple example scripts.

726 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question