Re: RE: wait events and v$session

From: Don Granaman <granaman_at_cox.net>
Date: Fri, 14 May 2004 00:03:48 -0400
Message-ID: <01ca01c439dd$de6f7aa0$6401a8c0@dilbert>

[Again a late response - resubmitted since the original was over-quoted. Is there a "three strikes and you're out" law?]

Which is why, in spite of the everything (write cache fusion, marketing propaganda, etc), the reality is that the "optimal" use of RAC is much that same as it was with 7.x OPS - segregating processes between instances based on which objects they access - whether for read or write. The penalty for overlap may be reduced in many cases, but still exists. I agree on the basic idea that you don't really use RAC for performance or *general* availability. In the majority of implementations, they are actually reduced. My favorite model for 7.x OPS was actually to run multiple databases, each with an instance on each node, then run each application entirely on one node/instance - with a "failover chain" to other instances (AKA "OPS for Dummies").

For large and intense OLTPish systems, an "instance-blind" RAC/OPS implementation is less painful than a 16p nail in the skull, but sometimes only slightly...

Don Granaman
OraSaurus

Original Message ----- From: "Cary Millsap" <cary.millsap_at_hotsos.com> To: <oracle-l_at_freelists.org> Sent: Tuesday, May 11, 2004 9:55 AM Subject: RE: RE: wait events and v$session_event

> 1. Here's an example of what I meant: RAC node B begins a query at =
> 12:00n,
> which will end at 12:03p. At 12:01p, RAC node A updates a block that B =
> won't
> read until 12:02p. At 12:02p, B discovers that the current incarnation =
> of
> the block is newer than 12:00n, so it has to reconstruct the 12:00n =
> image of
> the block using undo. This undo (one or more undo blocks) was at least =
> at
> some point in node A's buffer cache. If it still is, then the block has =
> to
> travel the interconnect and endure the expensive cache coherency lock
> management code path. (If it's not still in A's cache, then it's just a =
> PIO
> on node B, but then you have different problems.)
>
> 2. The confusion comes from calling timed events "waits." The duration =
> of an
> Oracle timed event like 'db file sequential read' is the duration of the =
> OS
> read() call that the Oracle kernel called to fetch the block. In the
> queueing theory sense, it's not a "wait" at all; it's a service time. =
> It's a
> "wait" only from the perspective of how long the Oracle kernel has to =
> "wait"
> from the issuance of a gettimeofday call occurring right before the =
> read()
> to the issuance of another gettimeofday call occurring right after the
> read().
>
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Thu May 13 2004 - 23:00:47 CDT

Re: RE: wait events and v$session_event