Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle RAC VIP networking question

Re: Oracle RAC VIP networking question

From: DA Morgan <>
Date: Tue, 07 Aug 2007 08:48:48 -0700
Message-ID: <> wrote:
> Unfortunatley - I'm a networking person trying to assist our UNIX/DBA
> team. But, yes, I agree with your understanding of Network Bonding.
> It bonds 2 or more NIC's together to aggregate bandwidth which should
> have nothing to do with VIP's on multiple subnets.
> The bottom line is, we have a 3 node cluster. Each node has a public,
> private and (what we call) an isolated batch subnet NIC (3 NIC's total
> per node). Our Application vendor indicates that it is "strongly"
> encouraged to have this isolated network (where bulk batch processing
> takes place) and not compete with the public NIC where the clients
> access the application. In total, this is 3 seperate IP subnets per
> node. Our Unix/DBA's need to have multiple VIP's to service
> the applications that need to use the public and isolated batch
> subnet. One VIP to listen on the the client side for the actual
> application. And another VIP that will listen on a totally different
> subnet (the isolated batch network) that of course has it's own NIC.
> So, our concern is from what we have heard so far is that it appears
> the VIP per node that any application can use is only available on the
> "public" facing NIC
> Thanks
> Keith

I think your vendor may have some misconceptions with respect to how RAC works. What I would recommend is creating two services. One for your end users that connects them to two nodes and a second service for the batch process that connects to the third. I can't see where a batch process requires a separate physical network and, if it does, they should be thinking NIC bonding for more through-put as latency should not be an issue.

Daniel A. Morgan
University of Washington (replace x with u to respond)
Puget Sound Oracle Users Group
Received on Tue Aug 07 2007 - 10:48:48 CDT

Original text of this message