Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Raw Vs. File systems, your opinion?

Re: Raw Vs. File systems, your opinion?

From: <>
Date: Tue, 5 Dec 2000 09:59:46 -0600
Message-Id: <>

Hi guys,
thanks for all your responses..
However while you guys were writing, I was digging through the web over=

other sites..
Here is a compilation of other "useful" messages I found..

-Bruce Taneja

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D HAPPY READING =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Our database is about 8G and only about 3 tablespaces are updated/inser= ted
> frequently. The DB is running on a shared RS/6000 which uses RAID5 fo=
> of the filesystems. I heard that RAID5 is not suitable for redo logs =
> write intensive tablespaces.
> Is it possible to have some datafiles resided on cooked and some othe=
> online/archived logs on raw devices ??
> Kevin

Yes you can....

In fact in high activity databases, very good performance gains can be = made
simply by making the log files raw...After all, you virtually never cha= nge
their size, never back them - so there is nil impact in having them raw= .
I'm not a sysop, so here goes nothing:
RS/6000's and AIX have a pretty good LVM, that takes away a lot of "all the trouble" you a re referring to. At least, so I'm told=

(not very long ago).

But it may be worth to see what a "normal, multi-spindle, mirrored logi= cal
volume" does. Mirroring takes forever, BTW, on SSA controllers, but I'm=  in
no way in favor of removing mirrors for the sake of performance.



As you already know, you should put your redo logs and other write
intensive datafiles on non-RAID 5 volumes. But you do not need to go
through the trouble of using raw file systems. Just use a non-RAID file=

system to handle this for you.

I am looking at using Oracle Parallel server - it seams that it
requires RAW file system to be setup. I have not had any experience wit=
this. Does anybody have any experience using raw devices.
What are the advantages ??
What are the disadvantages ?? What about backup ?? Disk failure normall=
protected by RAID 1 or RAID 5

Keep in mind this would be on a NT platform...

In article <8q81nq$36m$>,
"Dave Leather" <> wrote:

> Thanks Mark,
> I didn't intend to use autoextend, it was just a query. But the
> about control files still stands. How large should the control file
> be given that they can grow ( to quite a size, the ref says 20000
> blocks ).
> Dave Leather
> "Mark D Powell" <> wrote in message
> news:8q7qvi$gpe$
> > In article <8q7l6q$vps$>,
> > "Dave Leather" <> wrote:
> > > All,
> > >
> > > When you implement raw devices ( as you must for OPS),how does th=
> > > autoextend feature happen, is is disabled for raw dev's . Also
> > control files
> > > grow, what should be allocated to manage the growth , or is the
> > > different in OPS ?
> > > ( if you have any good references for OPS could you let me have
them )
> > >
> > > Thanks in advance
> > >
> > > Dave Leather
> > >
> > >
> > I would not attempt to use auto-extend with OPS and raw
partitions. We
> > run OPS on raw partitions and have never tried auto-extend. Since
> > partitions are fixed in size at creation it makes no sense to
> > less than the entire partition. I would think that it would work as=

> > long as the rdbms did not try to extend past the partition
> > but I would hope that Oracle is smart enough not to allow auto-
> > on raw partitions. Post if you find out it works.
> > --
> > Mark D. Powell -- The only advice that counts is the advice that
> > you follow so follow your own advice --
> >
Well, if you chosen Oracle Block size is 8K then 20,000 blocks would be= about 160M if my mental math is correct. Plus you should leave room for= future growth needed by the next release. The more I think about it the more it seems that I have read something = on how to size a control file. I though maybe I could use v$controlfile_record_section to get an idea, but it is way short.
Received on Tue Dec 05 2000 - 09:59:46 CST

Original text of this message