Re: RE: wait events and v$session_event
- From: "Don Granaman" <granaman@xxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 14 May 2004 11:04:15 -0700
[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@xxxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
