> "Ivan Vasquez" <ivan_at_looker.itos.uga.edu> wrote in message news:<c4aafk$897$1_at_cronkite.cc.uga.edu>...
> >...
> > With only one instance up, any query runs quickly, as expected.
> >
> > With both instances up, I connect to instance A, run a long query (say,
> > 30-seconds) and it runs normally. At this point I assume instance A has
> > cached some or all the blocks used for the query.
> >
> > Then I connect to instance B and issue the same query as above. Rows are
> > returned intermittently, up to 4-second delays in between. I assume in this
> > case RAC is trying to ship whichever buffers are found in instance A instead
> > of reading from disk. No DML activity is going on, it's just me and the
> > database.
> >
> > What confuses me is that I don't see much traffic thru the interconnect, and
> > CPU and disk utilization are far from high. Using vmstat I see increased
> > context switches, but they are just as high as those in the instance that
> > runs fine! I have read note 181489.1 but haven't found much help from it and
> > wonder if it's something else inherent to my architechture (i386).
Ivan
First and foremost take a look at the wait events from Oracle and
other stats related to this query. If the blocks are cached then you
generally get good scalability with RAC in query intensive workloads.
rgds Mark
--
got RAC? -> get empower! for Oracle [www.linxcel.co.uk]
Received on Wed Apr 07 2004 - 02:26:40 CDT
