Re: RAC in NAS

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_at_iinet.net.au


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.

> 

> frits

> 

> On 7/29/06, *Kevin Closson* <kevinc_at_polyserve.com 

> <mailto:kevinc_at_polyserve.com>> 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

>     get

>     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

>     params

>     are no-ops and filesystemio_options doesn't do anything either. You just

>     get

>     async IO

--
http://www.freelists.org/webpage/oracle-l