What is Oracle Async I/O?

Question 1:
Regarding the use of the async in oracle, can anybody offer advise as to
whether this methods has advantages over the std file system aproach. We
currently operate a number of oracle databases on HPUX 10.20, using
single discs with unix file systems and a buffer cache. We have employed
mirroring, but have not used striping.

Ans for Question 1:
aync_io is normally recommended for raw partitions and places where OS supports
asynchronous io..
Asynchronous IO has been reported to have cause corruption problems on certain
os platforms with certain versions..
For more details refer to Oracle Metalink

Question 2:
I'm running 7.3.4 on HP 10.20 and I've enabled async I/O in the kernel
and in the init file. someone in Oracle support said to do that many
moons ago even though it says only use async i/o with raw device files.
I use JFS files. Now someone else from Oracle support sends me FAQ
saying I shouldn't use asyn I/O with JFS but there's no reason as to
what can happen if you do. So far been running like this for quite
awhile. Any thoughts?

I've also been running an Oracle 8.0.3 instance using async i/o (it
defaults to that outta the box fer gawd's sake - all ya gotta do is set
it up in Unix) for awhile as well.

Ans1 for Question 2:
JFS is the name for VERITAS File System (VxFS) on HP. Indeed it
does not support async I/O on 10.20. So you should not be using
async I/O right now. In a few month we are releasing
the VERITAS Storage Edition for Oracle on 11.0. This product
includes VxFS 3.3 that allows async I/O on files (with the VERITAS
Quick I/O driver). As a matter of fact, these Quick I/O files behave
and perform just like raw devices. On Solaris we have seen over 100%
performance improvements over traditional cooked files for TPCC
type workloads. We expect the same on HP as well.

-- David Lai
VERITAS Software

Reply to Ans1:
So it doesn't work at all or would I get some sorta error message or
it (as in the next reply) a matter of ensuring data integrity
and that could be a potential problem. So far, I've had no
problem but then... There's no way we're going to 11.0 anytime
soon I doubt. So you recommend turning it off period then? Will
I see some preformance degredation in disk writes or nothing
as it doesn't really work?

Ans2 for Q2:

The problem of async I/O is a data integrity problem. The purpose of a
RDBMS is to ensure that any committed transaction has indeed being
written to disk - this is the purpose of the log writer. Basically, when
you say 'commit', then the log writer writes the log buffer to the redo
log file, and when it is safely written on disk you get a 'committed'
acknowledgement. If you use async I/O it just means that you send a
write command, and anticipate a successful return. The question is then
what will happen if somebody unplugs your computer at this crucial
moment? It depends on how your buffers are managed and how your hardware
behaves (i.e. if it has some battery to cope with a power failure). This
is why async I/O may indeed work well with anything, until ..., but also
why Oracle support people will only recommend it when it's totally safe.
Who do you think you are going to blame if you ever have a data
integrity problem ?
--

Stéphane Faroult
Oriole Corporation

Reply to Ans2:
We have backup power supplys of course. Mostly we don't really care
about data integrity that much. We reload a database every single
night and after the load is done it's read-only. We do this from
flat files etc... If the database goes mams-up we just start again
although it's never happened to this day yet. It will someday
I'm sure.

So not sure if this is still a problem or whether it doesn't make
any diff if I turn it off or on really?

Ans3 to Reply:
If you don't mind about integrity, losing transactions etc. just go for
the fastest ...
--
Regards,

Stéphane Faroult
Oriole Corporation

Hosted by www.Geocities.ws