Re: DBWR_IO_SLAVES and Asynchronous I/O

"Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message news:tgvr0830ik4404_at_beta-news.demon.nl...
>
> "Dino Hsu" <dino1_at_ms1.hinet.net> wrote in message
> news:d4jvgtch2rslse2tmd01752id3tk5eelc9_at_4ax.com...
> > Dear all,
> >
> > In a book, it says: (See note for source)
> > "...As of 8.1, ORACLE uses the DBWR_IO_SLAVES setting to determine how
> > many LGWR and ARCH I/O slaves to start; setting DBWR_IO_SLAVES to a
> > value greater than 0 sets the corresponding LGWR_IO_SLAVES and
> > ARCH_IO_SLAVES settings each to 4. If the option is not available on
> > your system, then you may be able to use asynchronous I/O to reduce
> > internal DBWR contention. With asynchronous I/O, only one DBWR process
> > is started since the I/O processing is performed asynchronously."
> >
> > My questions:
> > 1.What is the definition of asynchronous I/O? Is it defined by
> > DBWR_PROCESSES=1? Is it related to particular OS configurations?

see below. no. yes.

> > 2.Why do LGWR_IO_SLAVES and ARCH_IO_SLAVES become 4 instead of 3 or 5
> > when DBWR_IO_SLAVES is non-zero?

'cause oracle thinks 4 is a good number.

> > 3."If the option is not available..." What does it mean by this?

availability of asynchronous i/o is o/s platform specific.

> >
> > Thanks in advance, Dino
> >
> > Note: source information:
> > p.102, Kevin Leney, Oracle 8i DBA Handbook
> > Ch4. Physical Database Layouts->
> > Concurrent I/O Among Background Processes
> >
>
> Asynchronous I/O is any I/O where the requestor doesn't wait for
 completion
> of the I/O request.
> Whether or not it is available is O/S dependent.
> Sometimes it will work on RAW devices only.
> On several systems (AIX) you need to configure it.
> If you are using asynchronous I/O you shouldn't need multiple database
> writers and/or IO slaves (that is, as far as I read the Oracle docs on
 this)
> If you can't use async I/O (e.g. when you don't want to use/can't use raw
> devices) in that case you need to configure I/O slaves.
>
> I assume the number 4 is just some 'sensible' default.
>
> Hth,
>
> Sybrand Bakker, Oracle DBA
>

support for asynchronous i/o is platform specific, and most of my experience here relates to HP-UX.

basically, asynchronous i/o is a way to potentially improve performance of the database.

the other alternative is "synchronous" i/o, which means that oracle processes will "block" for each i/o request. that is, when the oracle process issues an i/o request, it will wait for the i/o request to complete, before issuing the next i/o request, and so on, which, depending on the nature of the i/o performed, can introduce a significant performance bottleneck.

one way to reduce the "synchronous i/o" bottleneck is to run multiple oracle processes, each process issuing and waiting for its own i/o requests to complete independently of one another. this, in effect, allows oracle to issue i/o requests concurrently.

with asynchronous i/o, on the other hand, a single oracle process can issue an i/o request without waiting for any previous i/o requests to complete. so oracle can issue multiple, concurrent i/o requests.

in order for oracle to use asynchromous i/o on hp-ux, the async i/o driver must be included in the kernel, the aio driver file must be owned by oracle, and async_io must be enabled for the instance (init.ora parm). when enabled and available, oracle will use the async i/o only for files on raw partitions. that is, i/o to datafiles on filesystems will still be "synchronous".

so, on hp-ux, async i/o is really of benefit only if you are using raw partitions. otherwise, you can simulate the performance boost of async i/o with multiple processes.

note that multiple processes means more overhead (more context switches), and with filesystems (on hp-ux) only one process can obtain a write lock to a file at a time, which means that multiple processes writing to the same file at the same time are going to block each other.

if you cannot move to raw partitions and enable async i/o, for whatever reason, and i/o performance is an issue, you can pursue other options, like "database edition for oracle" from veritas and/or faster disk storage subsystems.

HTH Received on Sun May 27 2001 - 22:58:44 CDT