According to our Operations Department, we can have Quick I/O for
only another $15,000 per.
----- Original Message -----
From: Shawn Ferris <Shawn.Ferris_at_twtelecom.com>
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
Sent: Tuesday, November 14, 2000 7:16 AM
Subject: RE: Asynchronous I/O on Solaris
> Veritas - Not sure how it's licensed, but I believe it's an add-on to VxFS
>
> Shawn M Ferris
> Oracle DBA - Time Warner Telecom
>
> > -----Original Message-----
> > From: Lewis, Ed [mailto:Ed_Lewis_at_PremierInc.com]
> > Sent: Tuesday, November 14, 2000 5:50 AM
> > To: Multiple recipients of list ORACLE-L
> > Subject: RE: Asynchronous I/O on Solaris
> >
> >
> > Steve,
> > When you mention Quick I/O, is that
> > a feature of Solaris, or the Veritas
> > product ? Thanks for the info.
> >
> > -----Original Message-----
> > Sent: Tuesday, November 14, 2000 1:00 AM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Hi All,
> >
> > It seems that the issue of asynchronous I/O on Solaris is
> > still alive and
> > kicking. Here is an attempt to pull the threads together.
> >
> > Oracle 7 had an 'async_write' parameter that used to default
> > to TRUE. If set
> > to
> > FALSE, Oracle would use the standard 'write()' system call to
> > do synchronous
> > writes. So DBWR for example would have to wait for each physical I/O
> > operation
> > to complete before it could do anything else. So if DBWR
> > needed to write 1
> > block
> > to each of 10 disks, all those write operations would be done
> > in series. The
> > intent of the default use of asynchronous I/O was to allow
> > multiple writes
> > to
> > distinct disks to be performed in parallel by a single process.
> >
> > Up to Solaris 2.3, there was only a threads based implementation of
> > asynchronous
> > I/O. For every concurrent asynchronous I/O operation, the 'aiowrite()'
> > system
> > call would allocate or spawn a light-weight process to
> > perform an ordinary
> > synchronous write. This achieved I/O parallelism at the expense of
> > additional
> > CPU usage associated with thread creation and extra context switching
> > overheads.
> > Under moderate to heavy write loads it was actually more
> > efficient to set
> > 'async_write' to FALSE and to configure a modest number of DBWR slave
> > processes
> > using the 'db_writers' parameter. The performance gain here
> > was commonly of
> > the
> > order of 2% to 5%.
> >
> > Solaris 2.4 introduced kernelized asynchronous I/O (KAIO) for
> > raw devices.
> > This
> > is an alternative implementation of the 'aiowrite()' system
> > call that avoids
> > the
> > unwanted performance costs of the threads based
> > implementation. Because KAIO
> > only works for raw devices, the 'aiowrite()' system call was
> > changed to use
> > KAIO
> > on raw devices and to use the threads based implementation
> > for file system
> > I/O.
> >
> > With the introduction of Quick I/O with Solaris 2.5.1, it
> > became possible to
> > use
> > KAIO against file system based datafiles. Thus the
> > 'aiowrite()' system call
> > was
> > changed to attempt to use KAIO even on file systems, and then
> > to revert to
> > threads based asynchronous I/O if that fails. This increased
> > the overhead of
> > asynchronous I/O even further, so that more sites needed to disable
> > asynchronous
> > I/O using Oracle parameters than before. From Oracle8 this is
> > done using the
> > 'disk_asynch_io' parameter, normally in conjunction with either the
> > 'db_writer_processes' or 'dbwr_io_slaves' parameters.
> >
> > The situation was confused somewhat by bug 4222164 in Solaris
> > 2.6, that
> > affected
> > patchsets below 105181-19 and greatly exaggerated the
> > performance cost of
> > the
> > threads based implementation of asynchronous I/O. However,
> > the basic problem
> > of
> > the performance overhead of file system based asynchronous I/O remains
> > unchanged
> > despite the resolution of this bug.
> >
> > Oracle have responded at 8.1 by avoiding the use of
> > 'aiowrite()' for UFS
> > based
> > datafiles. That has confined the problem to VxFS based
> > datafiles for which
> > Quick
> > I/O is not enabled -- still a large number of sites. A more
> > general solution
> > is
> > promised with 8.1.7 in which Oracle will attempt to recognise
> > whether KAIO
> > is
> > available for file system based datafiles, and decide
> > dynamically whether to
> > use
> > 'aiowrite()' or not. There may also be a new '_filesystemio_options'
> > parameter
> > to override the default intelligence if necessary.
> >
> > @ Regards,
> > @ Steve Adams
> > @ http://www.ixora.com.au/
> > @ http://www.christianity.net.au/
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Steve Adams
> > INET: steve.adams_at_ixora.com.au
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Lewis, Ed
> > INET: Ed_Lewis_at_PremierInc.com
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
> >
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Shawn Ferris
> INET: Shawn.Ferris_at_twtelecom.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
Received on Tue Nov 14 2000 - 09:15:43 CST
