how to configure IPs for ServiceGuard with RAC

[amrane]

I've got 2 nodes with MCSG (RAC extension).
They run a 9.2 Oracle RAC database used for Oracle Portal

So I've 1 package per node running 1 RAC instance with it's associated IP and of course those packages do not failover

Our DBA has just shown me a metalink note explaining that the IP address of each RAC instance must failover on the other node and keep answering !!!!

Of course I can do another actual failover package just for the IP address but I wanted to ask you how you've configured it ?
Thanks

[Julio Yamawaki · Accepted solution]

Hi,

If you read Using Serviguard Extension for RAC, page 23, you will see a picture talking about using a package for just starting up the listener in each box and in case of node failure, this package with the listener will start up in the other node and all clients will re-connect in this node, using the other instance.
I´ve never used this kind of configuration, I prefer to use TAF in client, because, when you reconnect in the listener, you will lose your session, right? And in TAF mode, depending on the type of session that your are running, you will not.
But, in both cases, you must have two ip addresses to the listeners...
And you must configure a lan to the Oracle RAC heartbeat (cache fusion), because the traffic between this two nodes will be high.

Regards

[amrane]

Thank you for the information. The note was not in the previous edition of the document.

However I'm surprised to see that TAF is working for you because our DBA has shown me that TAF doesn't really work if 1 IP is down.

So now I wonder if the problem is to associate IP to another listener package that actually failover or if the problem comes from TAF.

I've checked tnsnames.ora & listener.ora (see file in attachment) but I'm not dba

[Julio Yamawaki]

Hi,

Why are you surprised for TAF to work with one ip down?
TAF works even without RAC, you can setup this for "normal" instances.
By the way, your tnsnames seems to be ok.
This is a sql to verify what connections you have and what kind these are:
. connect in sqlplus as system
> column machine format a20
> select machine,failover_type,failover_method,failed_over,count(*) from v$session
> group by machine,failover_type,failover_method,failed_over;

The column count(*) will show you how many times this session was failed over.

Regards,

[amrane]

In fact, the failover time is roughly 75 sec when one IP is down. This corresponds to a TCP time out. Here are the corresponding metalink notes :

http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=284716.1

http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=97926.1 (par 4.1)

I think, that's why HP has added that note you was talking about Julio

[Julio Yamawaki]

Hi,

75 seconds is an unacceptable time...
My configuration is not using that a package with a listener and the failover time is about instantaneous (less than 2 seconds, in fact).
Probably you have some issue in configuration.
That tnsnames.ora that you send is from your servers or from your client?
What about your rac heartbeat (not SG heartbeat), how is this configured?
What kind of servers are you using?
About the lan cards, what type of interfaces are you using?

[amrane]

Hi

This is not the failover time of any package. 75 sec is the time the client (tnsping or sql select) takes before answering as soon as 1 of the 2 IPs is down.

Here's another metalink note that explains very well the issue :

http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=249213.1

Here's a small extract :
"What is happening is that the TCP Protocol is timing out at the OS / Network layer.
It can be shown that it is not only Oracle that is experiencing this failover slowness,
but other tools as well."

[Julio Yamawaki]

Hi,

I read this metalink notes, but, see:
1. This timeout is only when you have a single ip address, no TAF
2. If you have TAF, oracle client won´t wait for this timeout and try to reconnect to the other(s) nodes of the tnsnames.ora configuration
So, TCP/IPC timeout doesn´t explain this long time.
I say again that you have some issue in your client configurati

[amrane]

Hi

Thank's a lot for your help. I'm putting the listeners and their VIP in packages as quoted in HP doc