RE: RE: wait events and v$session_event

  • From: "Jamadagni, Rajendra" <Rajendra.Jamadagni@xxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 11 May 2004 12:49:12 -0400

It doesn't matter how many sessions you have running ... Anytime kernel
wants to read datafile you'll see db file read waits. It has nothing to
do with # of session.

The wait indicates ... "I am kernel and I am waiting till someone reads
x (p3) number of blocks from file (p1) starting with block id (p2) and
makes it available in the buffer cache".

Raj
------------------------------------------------------------------------
--------=20
Rajendra dot Jamadagni at nospamespn dot com=20
All Views expressed in this email are strictly personal.=20
select standard_disclaimer from company_requirements;=20
QOTD: Any clod can have facts, having an opinion is an art !

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of ryan.gaffuri@xxxxxxx
Sent: Tuesday, May 11, 2004 12:23 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: RE: wait events and v$session_event

Cary,

Could you be a little more specific, I don't quite understand this? I am
using one node right now for everything in my ETL process. However, we
have load_balancing turned on.=20

Also, why would I get file read waits if I just have one session
running?=20

 One note worth
mentioning here is that even the famous "I'll do TP on one RAC node and
query-only on the other" strategy is prone to lots of "global cache *"
activity.

Why? Because of the undo blocks that are used by both nodes.

----------------------------------------------------------------
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: