Resolving Oracle RAC VIP Failover and SCAN IP Load‑Balancing Issues

1. RAC VIP Failover Problem

RAC Failover means any node failure should be transparent to users; connections to a failed node are automatically moved to a healthy node.

1.1 Symptom

RAC cluster, primary node down, VIP failover broken:
java.sql.SQLRecoverableException:
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory
Additional information: 5291
Additional information: -1213915437

1.2 Diagnosis

Oracle RAC Failover can be:
1. Client‑Side Connect‑time Failover
2. TAF
3. Service‑Side TAF
The article uses TAF. TAF migrates sessions from a failed instance to a healthy one transparently, but uncommitted transactions are rolled back.

-- Correct configuration example
RAC =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
    (LOAD_BALANCE = YES)
    (FAILOVER = ON)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = RAC)
      (FAILOVER_MODE =
        (TYPE = SESSION)
        (METHOD = BASIC)
        (RETRIES = 180)
        (DELAY = 5)
      )
    )
  )

DELAY and RETRIES control retry interval and count.

-- JDBC connection string example
jdbc:oracle:thin:@(DESCRIPTION =
  (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.luocs.com)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.luocs.com)(PORT = 1521))
    (LOAD_BALANCE = yes)(FAILOVER = on)
  )
  (CONNECT_DATA = (SERVER = DEDICATED)(SERVICE_NAME = luocs))
)

Note: The issue was caused by a static listener configured during ADG setup, which prevented setting GLOBAL_NAME in listener.ora and disabled Connect‑time Failover and Transparent Application Failover (TAF).

2. RAC SCANIP Load‑Balancing Failure

2.1 Symptom

Connecting via SCANIP results in:
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

-- Configuration used
RACSCAN =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (LOAD_BALANCE = on)
      (FAILOVER = on)
      (ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = testdb)
    )
  )

2.2 Diagnosis

Oracle documentation notes that /etc/hosts can resolve only one SCAN IP address.

Without DNS, client connections using RAC load‑balancing will fail.
SCAN VIP count is unrelated to node count; the VIP is assigned randomly.
When DNS resolves SCAN, it returns a round‑robin list of IPs.
Do NOT configure multiple SCAN IPs in /etc/hosts; use DNS for proper resolution.
This is the correct deployment method.

DNS returns three SCAN IPs; the client picks one, contacts the corresponding SCAN Listener, which then load‑balances the request to a less‑busy local listener on a node, completing the client‑instance connection.

3. Key Points for RAC IP Configuration

3.1 Correct SCANIP Settings

Error when connecting via SCANIP:
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

-- Solution
Check SCAN listener status; service not registered because remote_listener is empty.
SQL> alter system set remote_listener='rac-scan:1521';
SQL> alter system register;

REMOTE_LISTENER works like LOCAL_LISTENER: each instance registers with the SCAN listener, enabling load‑balanced routing to local listeners.

3.2 Correct VIP Settings

-- VIP connection error
receives a connection refused error (ORA-12541) instead of waiting for long TCP connect timeout.
The client quickly moves to the next address.

-- Solution
SQL> show parameter local;
NAME               TYPE    VALUE
------------------- ------- -------------------
local_listener      string  
parallel_force_local boolean FALSE

SQL> alter system set local_listener='rac-vip1:1521' scope=memory sid='RAC1';
SQL> alter system set local_listener='rac-vip2:1521' scope=memory sid='RAC2';
SQL> alter system register;

Setting LOCAL_LISTENER to the VIP ensures each instance registers with the public IP/VIP, allowing successful registration and failover.

4. Summary

High availability is the first line of defense when failures occur; it must be thoroughly tested before production to guarantee reliable database operation.