I'm just taking a wild guess here, but to get blocking sessions it's possible the query of v$session would have to go to the other node(s) of the RAC cluster for session information, since the blocking session may be on a different node. 60 seconds is the time RHEL RAC takes to time out if a node cannot be reached, which could explain that exact timeout. Why the query works sometimes and not others, I don't know. Bug? Finn On 11/2/07, M Rafiq <rafiq9857@xxxxxxxxxxx> wrote: > > > I ran this query on a non rac 10.2.0.3 database and it returned the rows > very quickly. It may be some RAC related issue. > > Regards > Rafiq > > > > ------------------------------ > Date: Fri, 2 Nov 2007 08:35:40 +0100 > From: exriscer@xxxxxxxxx > To: snowman327@xxxxxxxxx > Subject: Re: Query against V$SESSION hangs on 10g RAC systems > CC: oracle-l@xxxxxxxxxxxxx > > hi > > querying blocking_session is the problem, if you dont query that columnd > then it should be fine > > I have a customer who requested a backport to fix the bug but the one-off > patch has no effect so might have to wait until 10.2.0.4 > > thanks > > -- > LSC > > > > On 11/1/07, *Dean* <snowman327@xxxxxxxxx> wrote: > > We recently had a locking/blocking problem on two different 10.2.0.3 RAC > systems. I ran a query similar to below to get more information: > > select sid, serial#, program, module, action, username, osuser, > sql_hash_value, machine, event, blocking_session > from v$session > where status='ACTIVE'; > > About 1 out of 5 times this query hangs. When it hangs, it waits for > exactly 60 seconds on "DIAG idle wait" and then returns the result set. If > I remove the blocking_session column, this query runs fine and never hangs. > Has anyone run into this or have any ideas why this would happen? > > > > > ------------------------------ > Climb to the top of the charts! Play Star Shuffle: the word scramble > challenge with star power. Play > Now!<http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct> >