Re: Direct IO

Hi Howard ;)

I think I feel another 'discussion' coming on :) Notwithstanding that it is still taught in the PT class, I see no documentation whatever saying that SORT_DIRECT_WRITES is tuneable anymore. In fact, a query of v$obsolete_parameter reveals that they are in fact deprecated parameters.

In terms of the NT Direct IO thing. If it is on by default, does that then mean that all operations on an NTFS device bypass the cache? That seems a little wierd as NT likes to tout itself as a fileserver OS (with a fair amount of physical memory being dedicated to file ops IIRC).

Cheers,

Dave

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:3b379e43_at_news.iprimus.com.au...
>
> "Dave Haas" <davidh_at_no.spam.hotmail.com> wrote in message
> news:UGKZ6.79549$Jg4.8380487_at_news1.telusplanet.net...
> > Hi Howard :)
> >
> > How does one enable this direct i/o thing on NT then? I've not seen any
> > Oracle parameters to do it and i'm not sure how to enable it at the OS
> > level. Is it on by default?
>
> Yup, I think so -but I think that you have to be using NTFS for that to be
> so (not that you'd want to be running Oracle on top of a FAT32 file system
> anyway!).
>
> >
> > In terms of SORT_DIRECT_WRITES i'm reasonably sure that it's no longer a
> > user settable thing. The direct writing of sort blocks to disk is now
> > handled automagically.
> >
>
> Well, the parameter is still discussed in the 8i Performance Tuning
 course,
> so it is still configurable. If sort_area_size is LESS than 640K, it is
> needed to enable sort direct writes. I guess if you were certifiably
> insane, if your sort_area_size was larger than 640K, you could use it to
> disable sort direct writes. But yes -given that a sensible size for
> sort_area_size on the whole is around 1Mb, it is all automated to be on by
> default.
>
> Regards
> HJR
>
>
>
>
> > Cheers,
> >
> > Dave
> >
> >
> > "Howard J. Rogers" <howardjr_at_www.com> wrote in message
> > news:3b372546$1_at_news.iprimus.com.au...
> > > ;-)
> > >
> > > The little I know about it, and in the context in which our earlier
> > > 'discussion' would have raised the issue, this has nothing to do with
> > > by-passing Oracle's buffer cache, but to do with by-passing the file
 system
> > > buffer.
> > >
> > > NT and Raw devices don't use a file system buffer. Unix does
 (generally),
> > > and its buffer is usually 8K big (hence the need for Oracle to match
 that
> > > buffer, and thus need 8K blocks on Unix).
> > >
> > > SORT_DIRECT_WRITES is a different beast entirely. That tells Oracle
 that
> > > when the PGA for a User has filled up doing a sort, and needs to swap
 to
> > > temporary tablespace, could you please not flood my buffer cache with
 the
> > > relevant data, but have the Server Process write it directly to the
 relevant
> > > datafile. Provided your sort_area_size is at least 640K in 8i,
> > > sort_direct_writes is automatically true (as far as I can tell).
> > >
> > > But although the buffer cache is thereby avoided, you'd still actually
 be
> > > passing the write to the file system buffer if your temporary
 tablespace
 was
> > > on a cooked device.
> > >
> > > Regards
> > > HJR
> > >
> > > "Dave Haas" <davidh_at_no.spam.hotmail.com> wrote in message
> > > news:SERY6.338$84.100633_at_news0.telusplanet.net...
> > > > Hi.
> > > >
> > > > I have a question with regard to terminology. In several posts (and
 an
> > > > argument I had with Howard a while ago :) people have used the term
 'Direct
> > > > IO'. To be perfectly honest I'm not exactly sure what that means.
 AFAIK
> > > > the IO options are 1) file-system buffered and 2) Raw IO. I heard
 (or
 more
> > > > to the point, read) a post that said something to the effect of '...
 direct
> > > > I/O means that the buffer cache is not involved in the operation
 ...'.
 Does
> > > > that have something to do with the sort-direct-write operation and
 the
 old
> > > > SORT_WRITE_BUFFERS and SORT_WRITE_BUFFER_SIZE? I'm a little
 confused
 (as
> > > > usual) ...
> > > >
> > > > Dave
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Received on Mon Jun 25 2001 - 17:48:47 CDT