RE: RAC Node Preference for sessions

From: <>
Date: Sat, 2 Feb 2013 18:39:28 -0600
Message-ID: <>

Good questions.

RAC so using VIPs. Client TNSNAMES looks correct.

Registration occurs via LOCAL_LISTENER (listener name) and REMOTE_LISTENER = RAC_LISTENER.

Your #3 is interesting.

I hadn't considered looking at the existing sessions - I was only thinking about load. It's possible that the session counts are more balanced than I thought because we have lots of idle sessions.

We also have a lot of sessions end up in SNIPED status so I'm working on a cron job to clean those up - could be related?


-----Original Message-----
From: Fm [] Sent: Saturday, February 02, 2013 6:25 PM To: Taylor Christopher - Nashville
Cc: <>
Subject: Re: RAC Node Preference for sessions

  1. How are your instances registering with RAC listeners?
  2. How are your clients connecting, VIP's or scan? How is the client tnsnames look like?
  3. is session count similar across all instances irrespective of load?

Thank you.

On Feb 2, 2013, at 1:32 PM, <> wrote:

> Is there a way to influence [thru manual intervention] which node is preferred for sessions?
> The reason I ask this question, in this way, is that we have 3 nodes, and node 2 continuously seems to be favored for new sessions.
> These are identical servers (DELL R900s) with the same OS, the same server characteristics (CPU speeds etc).
> We have the default RAC listener service configured:
> 3 CCMNASP1 2295827025 CCMNASP1 5/12/2010 1:58:52 PM 2134570705 N NO NO LONG
> As an example, we had 2 nodes idling (1 & 3) and I was running a perf test on node2 generating a lot of IO (but little CPU) and we kicked off some web reports and they connected to node2 (from Business Objects server).
> I have verified that the BOBJ server is set to use the CCMNASP1 network name so I know it's not setup to only connect to the instance name on node2.
> Part of the issue is that node2 is having "issues" of its own - so when it gets loaded, the issues get exasperated.
> I'm wondering what I'm overlooking (if anything).
> Chris Taylor
> Oracle DBA
> Parallon IT&S
> --

Received on Sun Feb 03 2013 - 01:39:28 CET

Original text of this message