Clusterware, SCAN, VIPs, Services, Instance Affinity, and Client Failover Concepts

Learning outcomes

ServiceHub has two healthy RAC instances, but every application connection string contains racnode1.example.com. When node 1 fails, the database survives yet new clients wait on a dead address. RAC availability becomes usable only when Oracle Clusterware owns the network/database resources and clients connect to a service through cluster-aware addresses such as the Single Client Access Name (SCAN).

1. Clusterware owns resource state, dependencies and placement

Oracle Clusterware monitors and controls resources such as cluster VIPs, SCAN listeners, node listeners, databases, instances, Automatic Storage Management (ASM) and database services. Persistent cluster configuration lives in the Oracle Cluster Registry (OCR); node-local state uses the Oracle Local Registry (OLR). SRVCTL is the supported service/database management interface over these Clusterware resources.

2. SCAN is the stable cluster entry name

The Single Client Access Name (SCAN) is a cluster-level name resolved to one or more SCAN virtual IP addresses (commonly three). SCAN listeners can run on different cluster nodes. Clients do not need to know every node hostname and can survive node additions/removals without changing their connection descriptor.

A SCAN listener does not normally host the final database session. It receives the connect request and redirects it to a local listener on a node offering the requested service, using load-registration information from the database instances.

srvctl config scansrvctl status scan -verbosesrvctl config scan_listenersrvctl status scan_listener

3. Node VIPs make network failure faster to detect

A node Virtual IP address (VIP) is managed by Clusterware and can move/fail over when a node/network interface fails. Local listeners use node VIP addresses so failed-node connection attempts can fail quickly rather than waiting for long TCP timeouts against a dead physical host.

srvctl status vipsrvctl status listener

VIP failover helps new/reconnecting clients; it does not preserve application transaction state that was in a failed database process.

4. Services are the workload identity

A database service groups sessions that share workload/availability objectives. For an administrator-managed RAC database, a service can list preferred instances where it normally runs and available instances that can host it after failure or planned relocation. Clusterware maintains the configured service cardinality and policy.

srvctl add service   -db servicehub_rac   -service servicehub_oltp   -preferred "shrac1"   -available "shrac2"   -policy AUTOMATIC   -notification TRUEsrvctl config service -db servicehub_rac -service servicehub_oltpsrvctl status service -db servicehub_rac -service servicehub_oltp -verbose

If the service fails over to an available instance, it does not automatically fail back unless configured to do so. Automatic failback can create a second disruption after the preferred instance returns; choose it intentionally.

5. Trace the connection path

1. Client resolves servicehub-scan.example.com to SCAN VIPs.
2. Client reaches a SCAN listener.
3. SCAN listener uses registered service/load data and redirects to a local listener.
4. Local listener accepts the session on an instance currently offering servicehub_oltp.
5. The application request runs inside that instance; Cache Fusion accesses globally cached blocks as needed.

(DESCRIPTION =  (CONNECT_TIMEOUT=15)  (TRANSPORT_CONNECT_TIMEOUT=3)  (RETRY_COUNT=10)  (RETRY_DELAY=2)  (ADDRESS=(PROTOCOL=TCP)           (HOST=servicehub-scan.example.com)           (PORT=1521))  (CONNECT_DATA=(SERVICE_NAME=servicehub_oltp)))

Oracle recommends a full connect descriptor when timeouts/retries matter; Easy Connect with SCAN does not expose the same timeout/retry controls.

6. Connection failover is not transaction continuity

Fast Connection Failover (FCF) and Fast Application Notification (FAN)-aware pools quickly react to service/node events so dead connections are removed and new work goes elsewhere. Application Continuity (AC) adds request replay for eligible recoverable outages and requires correct service/driver/pool configuration. RAC licensing includes AC for appropriately licensed RAC EE/EE-ES use, but client support and replay correctness still require engineering.

7. Planned service relocation drains workload

srvctl relocate service   -db servicehub_rac   -service servicehub_oltp   -oldinst shrac1   -newinst shrac2   -drain_timeout 60   -stopoption TRANSACTIONALsrvctl status service   -db servicehub_rac   -service servicehub_oltp   -verbose

The 60-second value is only an example. Drain time is workload-specific. Planned draining lets existing requests/transactions complete according to the service stop policy while new work is directed elsewhere.

8. Free lab: service identity without RAC

Oracle services also exist in a single instance, so Free can teach the application abstraction safely. Run as a PDB administrator in FREEPDB1.

BEGIN  DBMS_SERVICE.CREATE_SERVICE(    service_name => 'servicehub_ch18_oltp',    network_name => 'servicehub_ch18_oltp'  );  DBMS_SERVICE.START_SERVICE('servicehub_ch18_oltp');END;/SELECT name,network_name,pdb,enabledFROM v$servicesWHERE name='servicehub_ch18_oltp';

sql servicehub_owner@//localhost:1521/servicehub_ch18_oltpSELECT  SYS_CONTEXT('USERENV','SERVICE_NAME') AS service_name,  SYS_CONTEXT('USERENV','CON_NAME') AS con_name,  SYS_CONTEXT('USERENV','INSTANCE_NAME') AS instance_nameFROM dual;

BEGIN  DBMS_SERVICE.STOP_SERVICE('servicehub_ch18_oltp');  DBMS_SERVICE.DELETE_SERVICE('servicehub_ch18_oltp');END;/

This validates service-based application identity. It does not emulate SCAN, VIP movement, FAN, Clusterware or multi-instance failover.

9. Deliberately wrong: point production only at node1's physical hostname

If all connection descriptors name one physical node, RAC can keep the database alive while clients still fail to find another instance. The repair is a cluster service through SCAN with tested client timeout/retry/FAN behavior, not simply adding the second hostname after the outage.

10. Production judgment

Use services—not SIDs or hard-coded instances—as the application contract. Let Clusterware own service/network resource state, use SCAN for stable discovery, and test both new-connection failover and in-flight-request behavior with the actual driver/pool. Keep service placement aligned with data/workload affinity when Cache Fusion pressure matters.

SCAN/VIP/SRVCTL require Grid Infrastructure; RAC licensing remains separate. Lesson 3 now shows why service placement is also a performance tool: moving every hot block between instances can erase the benefit of adding nodes.

Authoritative references

• Connecting to RAC Using SCANs — SCAN client connection guidance
• Oracle RAC Listener — SCAN listener, local listener and VIP flow
• Workload Management with Dynamic Database Services — preferred/available services and failback
• Server Control Utility Reference — SRVCTL service/SCAN operations
• Ensuring Application Continuity — draining/FAN/Application Continuity concepts