Re: File Systems vs. Raw Devices

A whole bunch of people wrote:
>: >>
>: >> What are the performance gains (is there really a 50% gain in using
>: >> raw devices over file systems)?
>: >
>: >No, more like 10-15%, at least on BSD SunOS systems.
>
> Can't tell you on SunOS, but on the systems I've worked with
> we've seen much more than 50%.. (300% on HP-UX 8.0, about the
> same on SCO/Unisys SVR3). After about a year, we just started
> putting all Oracle databases on raw partitions by default.

There was a time not to long ago I would have made some blanket statement like "Raw doesn't buy you much in terms of performance". I have learned much since then and will instead say:

"Raw doesn't buy you much in terms of performance, Usually" :-}

Seriously, while it going raw is certianly a good move in an environment with high I/O activity, experienced staff, and a need for increased response time, I have never been in any environment where i would consider going raw by default.

By last count we have 25 active instances here. some of which were set up on large workstations servicing specific projects with only 5 users. it is safe to say that other than the automatic scan of the alert_log and the nightly backup a DBA hasn't been in any of these guys in months.

This group/instance doesn't need 3 second response time or a 10%-300% increase in I/O response time. They need a workhorse that will store a lot of data for them and can be retrieved via sql. They need a system that wont get wacked the first time the Jr. Unix Geek addes a filesystem.

Certianly there are many cases where raw partitions is a good thing but there are just as many where it is a bad thing. The best we can do is look at each uniq requirment and see what the best fit is.

As to the statements that going raw improves performance by X percent

With a crappy Filesystem you can get great performance improvements, with a good filesystem you can get mediocure perf improvements with a fantastic filesystem you can get nominal performance improvements and with a good filesystem, a good virtual memory system and the right transaction mix you can get negative performance improvements.

In short, the world is a difficult place that defies generalizaion.

> In my opinion, if a filesystem is going to have some OS type
> buffer cache, why have the OS and Oracle both caching? I can't
> take the caching away from Oracle, but I can take it away from
> Unix.

There are a number of systems out today that do a good job of cacheing I/O requests by using main memory as a generalized buffer cache (SunOS and AIX?). In this case you could argue that runing cooked gets you a big cache area with out having to dedicate a whole bunch of memory only to the SGA. When you go raw you can certianly increase the db_block_buffers to compensate but only at the expense of everything else on the system.

-- 
Regards, 

Lee E. Parsons                  		
Systems Oracle DBA	 			lparsons_at_world.std.com