Re: RAC in NAS

  • From: Nuno Souto <dbvision@xxxxxxxxxxxx>
  • Date: Sun, 30 Jul 2006 22:21:26 +1000

Well, that's really the problem with strace, isn't it? Which
kernel, which flavour of Oracle and what specifically happens
with each variation and patch.  Because different combinations
are so different in results, strace is not really an easy way
of decoding if aio is in there, although of course it
can be accurate.

Large numbers of folks out there are still using 2.4 kernels
with all their (dis)advantages, as well as
9ir-God-only-knows-whatever.  Let's not even go into the absence
or presence of all required patches, both Oracle and Linux, in
all magical proportions and combinations.  Again, these
vary wildly depending if one uses Suse, RH or one of
the others.

Don't forget you also have to strace dbwr and lgwr *at the time*
they are opening the files if you want to see what's really going
on.  This means stracing every child of the instance startup
sqlplus - or adding files to an already running instance and watch
them being opened.  Ie: strace is not a stochastic tool, it's a live
monitor. If what you want to monitor is not happening at the time
strace is peeking, you don't see it. Simple as that.

With slabinfo and oracle stats one very much sees what's been going on, as opposed to watching live. If one uses the "watch" technique I described you get a good aproximation of "live". But that's about it. However, it should work with at least RH 2.4 and 2.6 - and I guess 2.2 as well although I was spared that one. And it should show what's going on regardless of whatever patches one slapped on Oracle or if it is one of the many flavours of 9i or 10g.

That's why at the moment I think it's the most accessible and expedite
way of finding out if in reality aio is there or not for Oracle.
With the caveat I described: there might be other software already
using aio, so look for deltas of the second column rather than expecting
to find "only 0 or otherwise".

For example: you can mount ext3 file systems to do aio by default,
even in kernel 2.4.  And if you watch slabinfo with such a file
system mounted you'll see the kio counters ticking over even with simple
programs such as "cat".

-- Cheers Nuno Souto in sunny Sydney, Australia dbvision@xxxxxxxxxxxx

Frits Hoogland wrote,on my timestamp of 30/07/2006 2:40 AM:
exactly my point!

I've seen oracle doing async IO with the 2.4 kernel doing other system calls (the kludgy stuff you mentioned), and oracle doing async IO with the 2.6 kernel (io_submit system call).

Ever looked at orion in conjunction with linux? It doesn't seem to do async IO.


On 7/29/06, *Kevin Closson* <kevinc@xxxxxxxxxxxxx <mailto:kevinc@xxxxxxxxxxxxx>> wrote:

            >>      on the other hand, if the system call is the same, what
    kind of magic is involved which makes oracle do asynchronous IO? The
    system call must tell the operating system what kind of IO it wants to
    do, either by doing a call which implies the kind of synchronousity, or
    by setting a flag which alters the synchronousity.

...but the calls are not the same. If you strace 10g DBWR, after linking in libaio and setting filesystemio_options=direcIO, you will see io_submit(2) calls which are new to 2.6 kernel. There really was no "real" async IO prior to the 2.6 kerenl. There was some kludgy stuff piggy-packed on the socket interface of all things, but it was crazy.

    Then , of course, if $ORACLE_HOME/lib/libodm* is a real ODM library you
    async IO regardless of what libaio is and regardless of what init.ora
    parameters you set...when ODM is linked in, all the "async*" init.ora
    are no-ops and filesystemio_options doesn't do anything either. You just
    async IO

Other related posts: