Re: Raw vs. Cooked

That's an interesting article - the most interesting point of all being that the database was 235GB, spread over 180 discs.

I think one of the problems with the question: "Is raw better than cooked ?" is that the question is rarely phrased in the best way. Try restating it more like:

    I have 500 MB available RAM, should I set this up as

        500 MB db_cache_size and use RAW
        400 MB db_cache_size, 100MB file system buffer and use file system
        480 MB db_cache_size, 20 MB async_io buffer and use async I/O

(adjust according to your feature set and memory availability). The answer then depends on how well your application is written, and who else is hammering the disks.

If you have a really good application, and no-one else is killing the discs, then raw devices should be faster because (a) they avoid the double-buffering and inode locking issues that the paper mentions and (b) you have put all the memory into the Oracle buffer - which is where the smart code is that really understands which bits of data are most popular and should be kept longest.

If you have a badly written application, particularly one that does repeated, tablescans (most specifically one that are too small to be really noticeable, but too large to be handled extremely well by Oracle) then a file system buffer can save you - because the file system buffer may hand on to file system blocks that Oracle keeps discarding from its LRU list.

If you have a reasonable application, but other people are killing the discs, every write that you do could be slowed down to a random degree because of someone else. In which case async I/O may be your best friend for smoothing out performance peaks.

-- 
Regards

Jonathan Lewis

http://www.jlcomp.demon.co.uk/faq/ind_faq.html
The Co-operative Oracle Users' FAQ

http://www.jlcomp.demon.co.uk/seminar.html
Optimising Oracle Seminar - schedule updated Sept 19th





<david_grove_at_correct.state.ak.us> wrote in message 
news:1103230119.537094.214900_at_c13g2000cwb.googlegroups.com...


>I am the dba for our shop's Informix based app.  We use raw devices on

> our Sun Solaris boxes.

>

> We are about ready to start the process of redeveloping our agency's

> main app using Oracle.  I am starting to familiarize myself with

> Oracle.

>

> I'm wondering about the ole cooked vs. raw space issue.

>

> In my Informix experience, I am quite comfortable using raw space.

> However,I have gotten the impression

> from Oracle folks (for example, an Oracle instructor) that the

> customary practice with Oracle is to use cooked space.  In fact, the

> instructor said there wouldn't be any difference, so he suggested using

> "the more

> convenient" cooked space.  To me, it doesn't really seem inconvenient

> to

> use raw, so I would be happy to go that way if there is a performance

> gain (which seems likely to me).  I am assuming that there  exist

> Oracle utilities to

> handle backups or loading/unloading raw storage.

>

> Anyway, while considering this, I found a recent (April 2004) Oracle

> white paper that

> seems to support my personal bias (don't we just love to see our

> prejudices reinforced?).  It is called "A Quantitative Comparison

> Between Raw Devices and File Systems for Implementing Oracle

> Databases".  It can be found here:

>

> http://www.oracle.com/technology/deploy/performance/pdf/TWP_Oracle_HP_files.pdf

>

> It concludes that using raw devices is much superior to cooked.  But,

> perhaps that conclusion is meant to apply specifically to HP platforms,

> since that was the basis of the paper.

>

> Anyway, among the Oracle cogniscenti, is raw really generally avoided

> in favor of cooked?  Does this paper challenge the generally accepted

> Oracle practice?  Is there a generally accepted "factoid" in the Oracle

> world that either raw or cooked is "the way to go"?

>

> We will be using one big S.A.M.E. RAID10 device.  The question is to

> cook or not to cook, and administrative difficulties of raw vs cooked

> are not an issue (assuming suitable Oracle tools exist).

> Thank you for any comments.

>