cancel
Showing results for 
Search instead for 
Did you mean: 

Row Device vs File System

SOLVED
Go to solution
mehul_3
Regular Advisor

Row Device vs File System

Hi
What is the differance between Raw Device and File System.
We use HP-UX11i operating system.
Which is the better option from above one.

Regards,
Mehul
14 REPLIES
Pete Randall
Outstanding Contributor

Re: Row Device vs File System

The difference is whether I/O is buffered by the HP-UX kernel or not. With a file system, it is - with a raw device HP-UX does not do any buffering. This is typically used for a database application and the DB does any required buffering.


Pete

Pete
Pat Lieberg
Valued Contributor

Re: Row Device vs File System

I'm assuming this is in relation to a Database application. Typically, filesystems have buffering overhead from the OS involved, where the raw devices do not.
Piergiacomo Perini
Trusted Contributor

Re: Row Device vs File System

hi,
as other guys said
the difference is overhead
introduced by file system/OS.
On my past experience (with other
Unix platform) Raw Device have
better performance.

regards
Jean-Luc Oudart
Honored Contributor

Re: Row Device vs File System

Async IO are currently only available on raw device.
Lots of people claim raw device gives more performance than file system, but gain differ from application type and transaction load.

see also attachment

Regards
Jean-Luc
fiat lux
Steven E. Protter
Exalted Contributor

Re: Row Device vs File System

A. Clay Stephenson actually did some scientific tests with oracle of raw versus filesystem. The differences in performance has dwindled. HP-UX 11i v1 has very little advantage for raw filesystems on Oracle.

Of course you've not actually told us what you are going to put in these raw filesystems. The downside of raw is, your only access is via database/application utilities. Filesystems are accesible and can be backed up if the database or application is shut down.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Jean-Luc Oudart
Honored Contributor

Re: Row Device vs File System

From the performance point of view, you cannot say for 100% that raw is and always will be the fastest ( as I say in previous post, it depends ...) and you may want to benchmark your application to verify waht is best for you.

see also this comment form Tom Kyte :
http://asktom.oracle.com/pls/ask/f?p=4950:8:11141198565443368411::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:7931107631402

Regards
Jean-Luc
fiat lux
Piergiacomo Perini
Trusted Contributor

Re: Row Device vs File System

Jean-Luc and other,

i seriously forget to specify that
obviously it depend from use of db
:-)

regards
Bill Hassell
Honored Contributor
Solution

Re: Row Device vs File System

Something that is often overlooked in choosing raw versus file access for databases: backup and restore. Filesystems can be backed up with many tools in HP-UX, but raw has no files, no directories, nothing for a backup program to use. The only tool is dd but this is terribly unreliable. It simply reads blocks of data and writes them onto tape (or another disk). There is no timestamp as to when the backup was made, no information about source location (rlvol name), system name, nothing but raw data. What this means is that the backup is useless if incorrect information is written on the label.

So you have a couple of choices: have your databasae developers write a procedure to shutdown the database and export all the data to a set of extra disks, then backup the exported data files. Or, purchase a commercial backup program that understands and handles raw backup images. Be very careful about a cheap solution. Assuming the decision is based on important production servers, the backup program must be able to recover from tape errors, handle multiple tapes for a single backup, take care of documenting each tape, logs all activities and sends alerts when something goes wrong, etc.


Bill Hassell, sysadmin
A. Clay Stephenson
Acclaimed Contributor

Re: Row Device vs File System

There is one other thing to consider --- and this is the only time I seriously consider the use of raw i/o. It is possible for multiple hosts to access a shared raw device with r/w access allowed by all the hosts. That is simply not possible with conventional filesystems because one host will have no idea about another host's buffer cache contents. There are clustered filesystems that even manage that trick but I'm yet to be convinced of their reliability given the extreme complexity of this task. Even with raw devices there must still be a synchronization mechanism to prevent simultaneous access to the same data blocks and indices.

If it ain't broke, I can fix that.
saju_2
Respected Contributor

Re: Row Device vs File System

Hi mehul

I think u already got the answer for difference between RAW and FS.
I found an article in net which was discussing about either to use DB as RAW or FS. Pls check this attachment.

Regards
CS

saju_2
Respected Contributor

Re: Row Device vs File System

Hi all

The same attachment which i posted is already attached by Jean-Luc.. Sorry guys..

Regards
CS
Yogeeraj_1
Honored Contributor

Re: Row Device vs File System

hi mehul,

they have been Raw Device and File system, now there is ASM (Automatic Storage Management). A thing that you must not ignore now with Oracle Databases!

In fact Oracle allows you to use all of them. TPC results have show that ASM is on the "large end".

ASM also brings along the following advantages:
o Management Capabilities
The administration layer has been removed so that DBA gets the hand, the System administrator is least involved. The DBA manages storage for the thing that uses more storage than anything else in your system (the database). There are less moving pieces.

o Availability
It provides for database level mirroring of database data. It is mirrored and then striped (instead of striped and mirrored) meaning if you lose a 9GB drive in the array, you don't need a hot spare sitting around -- we just need 9 gig of storage somewhere in the system on other failure groups in the disk group. You need to get a new 9gig drive soon, but you don't lose protection just because you lost a disk and didn't have an entire blank one sitting around.

You can also for instance ONLINE migrate your NAS to a SAN. You just have to add the SAN storage to the disk group, drop the NAS storage and the database will move all data from "hardware A" to "hardware B".

o Performance.
There is no man in the middle with ASM. It does not have the overheads associated with file systems (the latter just manages sections of disk that are made of pages in things called files).

hope this helps too!

kind regards
yogeeraj
No person was ever honoured for what he received. Honour has been the reward for what he gave (clavin coolidge)
Arunvijai_4
Honored Contributor

Re: Row Device vs File System

What Tom says ?

http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:7931107631402

-Arun
"A ship in the harbor is safe, but that is not what ships are built for"
Frank de Vries
Respected Contributor

Re: Row Device vs File System

I worked with both but I see that raw devices are more and more phased out.

I think this makes sense since technology
to disks has improved a lot I find that raw devices became something of the passed when I/O buffer memory was significant performance factor. And so as a DBA you didn't mind to sarcrifice conveniance for
performance.

Nowadays with high scsi or even fiber throughput to a san disk cluster (Hp, EmC or
Toshiba) and also the later versions of Oracle became more sophisticated in regards to disk i/o so that raw devices are no longer a sexy performance solution.

So it does no longer make sense to surrender
transparency and easier database managemant
for the (once) performance gain by using
raw devices.

One more comment: The best performance gain
is still achieved in writing better i/o
efficient code.

Hope this gives you a better philosophical
basis to your decision making process and choices at hand.







Look before you leap