10.2.0.4以后vip不会自动relocate back回原节点

solution 1：
srvctl relocate service -d -s -I;
crsctl relocate resource $resource_name;
solution 2：
srvctl start nodeapps -n <node name>;

like as:
crs1:
[resdb1:/oracle]$crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora.resdb.db   application    ONLINE    ONLINE    resdb1      
ora....b1.inst application    ONLINE    ONLINE    resdb1      
ora....b2.inst application    ONLINE    ONLINE    resdb2      
ora....B1.lsnr application    OFFLINE   OFFLINE               
ora.resdb1.gsd application    ONLINE    ONLINE    resdb1      
ora.resdb1.ons application    ONLINE    ONLINE    resdb1      
ora.resdb1.vip application    ONLINE    ONLINE    resdb1      
ora....B2.lsnr application    ONLINE    ONLINE    resdb2      
ora.resdb2.gsd application    ONLINE    ONLINE    resdb2      
ora.resdb2.ons application    ONLINE    ONLINE    resdb2      
ora.resdb2.vip application    ONLINE    ONLINE    resdb2   
[resdb1:/oracle]$srvctl start nodeapps -n resdb1
[resdb1:/oracle]$crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora.resdb.db   application    ONLINE    ONLINE    resdb1      
ora....b1.inst application    ONLINE    ONLINE    resdb1      
ora....b2.inst application    ONLINE    ONLINE    resdb2      
ora....B1.lsnr application    ONLINE    ONLINE    resdb1      
ora.resdb1.gsd application    ONLINE    ONLINE    resdb1      
ora.resdb1.ons application    ONLINE    ONLINE    resdb1      
ora.resdb1.vip application    ONLINE    ONLINE    resdb1      
ora....B2.lsnr application    ONLINE    ONLINE    resdb2      
ora.resdb2.gsd application    ONLINE    ONLINE    resdb2      
ora.resdb2.ons application    ONLINE    ONLINE    resdb2      
ora.resdb2.vip application    ONLINE    ONLINE    resdb2 

crs2:
$  crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora....SM1.asm application    ONLINE    ONLINE    gsioms01    
ora....01.lsnr application    ONLINE    OFFLINE               
ora....s01.gsd application    ONLINE    ONLINE    gsioms01    
ora....s01.ons application    ONLINE    ONLINE    gsioms01    
ora....s01.vip application    ONLINE    ONLINE    gsioms02    
ora....SM2.asm application    ONLINE    ONLINE    gsioms02    
ora....02.lsnr application    ONLINE    ONLINE    gsioms02    
ora....s02.gsd application    ONLINE    ONLINE    gsioms02    
ora....s02.ons application    ONLINE    ONLINE    gsioms02    
ora....s02.vip application    ONLINE    ONLINE    gsioms02    
ora.gssa.db    application    ONLINE    ONLINE    gsioms02    
ora....a1.inst application    ONLINE    ONLINE    gsioms01    
ora....a2.inst application    ONLINE    ONLINE    gsioms02    
$ 
$ 
$ lsnrctl start LISTENER_GSIOMS01
LSNRCTL for HPUX: Version 10.2.0.5.0 - Production on 25-MAY-2016 04:32:4
Copyright (c) 1991, 2010, Oracle.  All rights reserved.
Starting /oracle/product/ora10g/bin/tnslsnr: please wait...
TNSLSNR for HPUX: Version 10.2.0.5.0 - Production
System parameter file is /oracle/product/ora10g/network/admin/listener.ora
Log messages written to /oracle/product/ora10g/network/log/listener_gsioms01.log
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=gsioms01-vip)(PORT=1521)(IP=FIRST)))
TNS-12545: Connect failed because target host or object does not exist
 TNS-12560: TNS:protocol adapter error
  TNS-00515: Connect failed because target host or object does not exist
   HPUX Error: 227: Can't assign requested address
Listener failed to start. See the error message(s) above...
$ 
$ srvctl start nodeapps -n gsioms01
CRS-0233: Resource or relatives are currently involved with another operation.
$  crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora....SM1.asm application    ONLINE    ONLINE    gsioms01    
ora....01.lsnr application    ONLINE    ONLINE    gsioms01    
ora....s01.gsd application    ONLINE    ONLINE    gsioms01    
ora....s01.ons application    ONLINE    ONLINE    gsioms01    
ora....s01.vip application    ONLINE    ONLINE    gsioms01    
ora....SM2.asm application    ONLINE    ONLINE    gsioms02    
ora....02.lsnr application    ONLINE    ONLINE    gsioms02    
ora....s02.gsd application    ONLINE    ONLINE    gsioms02    
ora....s02.ons application    ONLINE    ONLINE    gsioms02    
ora....s02.vip application    ONLINE    ONLINE    gsioms02    
ora.gssa.db    application    ONLINE    ONLINE    gsioms02    
ora....a1.inst application    ONLINE    ONLINE    gsioms01    
ora....a2.inst application    ONLINE    ONLINE    gsioms02    
$ 

reference(from oracle support id):

Applies to:
Oracle Server – Enterprise Edition – Version 10.2.0.4 to 11.1.0.7 [Release 10.2 to 11.1]
Information in this document applies to any platform.
Symptoms

Starting from 10.2.0.4 and 11.1, VIP does not fail-over back to the original node even after the public network problem is resolved.  This behavior is the default behavior in 10.2.0.4 and 11.1 and is different from that of 10.2.0.3
Cause

This is actually the default default behavior in 10.2.0.4 and 11.1

In 10.2.0.3, on every instance check, the instance attempted to relocate the VIP back to the preferred node (original node), but that required stopping the VIP and then attempt to restart the VIP on the original node. If the public network on the original node is still down, then the attempt to relocate VIP to the original node will fail and the VIP will fail-over back to the secondary node.  During this time, the VIP is not available, so starting from 10.2.0.4 and 11.1, the default behavior is that the instance check will not attempt to relocate the VIP back to the original node.
Solution

If the default behavior of 10.2.0.4 and 11.1 is not desired and if there is a need to have the VIP relocate back to the original node automatically when the public network problem is resolved, use the following workaround
Uncomment the line
ORA_RACG_VIP_FAILBACK=1 && export ORA_RACG_VIP_FAILBACK

in the racgwrap script in $ORACLE_HOME/bin

With the above workaround, VIP will relocate back to the original node when CRS performs the instance check, so in order for the VIP to relocate automatically, the node must have at least one instance running.

The instance needs to be restarted or CRS needs to be restarted to have the VIP start relocating back to the original node automatically if the change is being made on the existing cluster.

Relying on automatic relocation of VIP can take up to 10 minutes because the instance check is performed once every 10 minutes.  Manually relocating the VIP is only way to guarantee quick relocation of VIP back to the original node. 
To manually relocate the VIP, start the nodeapps by issuing
srvctl start nodeapps -n <node name>

Starting the nodeapps does not harm the online resources such as ons and gsd.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13750068/viewspace-2106370/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/13750068/viewspace-2106370/