f



Raw vs. Cooked

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.

0
12/16/2004 8:48:39 PM
comp.databases.oracle.server 22978 articles. 1 followers. Post Follow

11 Replies
596 Views

Similar Articles

[PageSpeed] 47

IMO stick with raw partitions over file systems.

Steve Adams, who has published a book on Oracle internal structure and
behavior, has written on this subject.  You can find it on his web
site: http://www.ixora.com.au

HTH -- Mark D Powell --

0
Mark.Powell (1630)
12/16/2004 10:32:17 PM
"Mark D Powell" <Mark.Powell@eds.com> wrote in message 
news:1103236337.881584.144870@f14g2000cwb.googlegroups.com...
> IMO stick with raw partitions over file systems.
>
> Steve Adams, who has published a book on Oracle internal structure and
> behavior, has written on this subject.  You can find it on his web
> site: http://www.ixora.com.au
>
> HTH -- Mark D Powell --
>


why, with todays modern cache's on big systerms, raw has no real benefit - 
whats your experience? 


0
Dave
12/17/2004 1:33:39 AM
Hello All

I read the referenced article with interest as the database I am
responsible for is hosted on an HP-UX 11i server and is raw-device
based (the decision to use raw was before my time). However we are not
using the async IO driver. This is where my question comes in. The
paper concludes that:

"Where ease of management is not an issue and there is no application
constraint, customers should always implement raw based database with
async IO on HP-UX"

However, my reading of the evidence suggests to me that where ease of
management is not an issue and there is no application constraint,
customers should consider raw based database with async IO on HP-UX if
the application is primarily write intensive. I notice that:

=====================================
Filesystem with optimal mount options

DB_FILE_SEQUENTIAL_READ 14ms medium load and 19ms heavy load

Raw-device and no async IO driver

DB_FILE_SEQUENTIAL_READ 9ms medium load and 19ms heavy load

Raw-device and async IO driver

DB_FILE_SEQUENTIAL_READ 12ms medium load and 26ms heavy load
=====================================

Read operations are the bottleneck in our database. I have never
encountered a performance problem where write performance is the
bottleneck. I have, on the other hand, encountered a number of
performance problems where db_file_sequential_read was the primary
response time component. This leads me to conclude that by not enabling
the async IO driver I am on the write track. Am I missing something
important here, or do others agree with my conclusions?
Any advice appreciated

Thanks

Austin

0
12/17/2004 11:09:21 AM
Austin, a db_file_sequential_read, is a randon read.  The statistic
name is based on how Oracle stored the read data block into the buffer
cache not on how the IO is performed.

See http://www.lazydba.com/oracle/0__56581.html for backup to my point.

I have never seen proof that any other form of IO can equal Async IO
when the test is exaimined closely for the details of how it was ran.
HTH -- Mark D Powell --

0
Mark.Powell (1630)
12/17/2004 2:49:20 PM
Even with a large buffer cache RAW partitions outperform traditional
file IO and it is highly likely that the database will still perform
significant amount of physical IO operations so speed of the IO still
counts.

We have used both UNIX files systems and raw partitons to support our
databases.  When we converted any of the databases using file systems
to raw partitions there was always a small overall performance gain.
Generally most sites will probably not see a big change, but if IO is a
bottleneck then even a small gain can be very significant to end-user
happiness.

Depending on version and platform there are many different forms of IO.
Ahmed Alomari in his book, Oracle & UNIX Performance Tuning, Prentice
Hall, discusses several of them by platform.  My copy is from 1997, but
if a newer version exists it may be worthwhile for anyone with physical
IO performance issues to try to obtain this book.
HTH -- Mark D Powell --

0
Mark.Powell (1630)
12/17/2004 3:01:46 PM
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@correct.state.ak.us> wrote in message 
news:1103230119.537094.214900@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.
> 


0
jonathan5683 (1392)
12/17/2004 4:03:48 PM
Thanks for the inputs.

Mark, that link you sent was interesting.

I believe I'm correct in saying that db_file_sequential_read siginifies
a wait for an IO request to complete. Am I correct, then, in saying
that the increase in db_file_sequential_read is introduced because of
the increased IO throughput you get from async IO. In otherwords, it's
a symptom of IO performance improvements and not degredation?
Thanks

Austin

0
12/17/2004 5:57:11 PM
I think I'll change my mind for our first development install, and use
cooked space.  I'll then study Oracle structure and plan to use raw for
production.  The reason for going with cooked now is that as I started
reading the Oracle Installation Guide, it seemed that, unlike Informix (have
been Informix DBA), I couldn't just make the single equivalent in Oracle
(i.e., a single tablespace) of a single big Informix storage unit (a "whole
enchilada" rootdbs dbspace).  It appeared to me from the Installation Guide
that I needed to create a dozen (raw) tablespaces.

So, until I understand Oracle better, I'll start with cooked, and then
"graduate" to raw, later.

Thank you all for your helpful comments.


DG





<david_grove@correct.state.ak.us> wrote in message
news:1103230119.537094.214900@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.
>


0
12/17/2004 10:56:06 PM
Just a little expansion on the "single large storage unit" (see below)  for
a database.

I did have many physical storage units in our Informix system.  While
familiarizing myself with Oracle, I found the Oracle SAME paper.  I  tried
it (a single big RAID10 physical storage allocation) with our Informix
database on one of our new Sun boxes.  Now I have a bunch of things
contributing to the results (new box, new configuration, new RAID, and the
new storage structure), but the results were fantastic.  I have become a fan
of SAME.

Someday, when I have spare time and am looking for pain, I might actually
try to set up the traditional many dbspaces/tablespaces thing, and agonize
over what to place where.  But, in the meantime, SAME is great, and I'll try
it on our new Oracle system, too.

DG




"David E. Grove" <david_grove@correct.state.ak.us> wrote in message
news:10s6p0i7tal4q44@corp.supernews.com...
>
> I think I'll change my mind for our first development install, and use
> cooked space.  I'll then study Oracle structure and plan to use raw for
> production.  The reason for going with cooked now is that as I started
> reading the Oracle Installation Guide, it seemed that, unlike Informix
(have
> been Informix DBA), I couldn't just make the single equivalent in Oracle
> (i.e., a single tablespace) of a single big Informix storage unit (a
"whole
> enchilada" rootdbs dbspace).  It appeared to me from the Installation
Guide
> that I needed to create a dozen (raw) tablespaces.
>
> So, until I understand Oracle better, I'll start with cooked, and then
> "graduate" to raw, later.
>
> Thank you all for your helpful comments.
>
>
> DG
>
>
>
>
>
> <david_grove@correct.state.ak.us> wrote in message
> news:1103230119.537094.214900@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.
> >
>
>


0
12/17/2004 11:48:04 PM
db_file_sequential_read is a count of random (single block) IO
requests.  Most indexed access falls into this category: get a branch
block, get a leaf block, get the table block.  When used in conjuction
with the other IO statistics it helps you determine the distribution of
your Oracle IO by type: full table scan verse indexed, number of IO
expended on sort operations, etc....

When the statistic is used at the session level it can help you
determine if a plan is efficient.  That is you can estimate the number
of IO operations a task should take and then compare the statistics to
the estimate.

HTH -- Mark D Powell --

0
Mark.Powell (1630)
12/19/2004 4:42:20 AM
Hello Mark

Thanks again for your input.

I do realise that db_file_sequential_read signifies a wait for a single
block IO and when this event represents a large proportion of a query's
resource profile the most appropriate action is to reduce the number of
database calls (e.g. logical IOs). Only when the number of LIOs
required has been truly reduced to a minimum should we consider making
changes to the IO subsystem if a performance problem still exists.

Where my confusion comes in is that the optimal configuration in the
paper also exhibits the longest db_file_sequential_read durations. This
despite the SQL that is being executed during the test being identical
the SQL executed when testing the non-optimal configurations. This has
led me to think that the increased throughput afforded by async IO has
led to busier disks and longer db_file_sequential_read durations. Do
you think this assumption is reasonable?

0
12/20/2004 9:37:39 AM
Reply: