In RAC you would normally let the “listener layer” handle the failover i guess… using a single SCAN address in the jdbcurl. I.e. IFS Cloud wouldn’t know it’s a RAC.

A bit of warning as you ask this question. RAC is complicated. You can get really strange performance issues if heavy jobs start on different nodes. Make sure you have or can get hold of DBA’s with high skills on RAC before going live with it.

 To the question - we support advanced jdbcurl e.g. a dataguard config would look something like:

jdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=OFF)(FAILOVER=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.72.231)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.72.232)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=sb)))

I think this one might be from a customer that had two RAC-one clusters (with SCAN) where one was configured as dataguard standby:

jdbc:oracle:thin:@(DESCRIPTION_LIST=(LOAD_BALANCE=off)(FAILOVER=on)(DESCRIPTION=(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=oltpworkload)))(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=oltpworkload))))

 

Hi,

We are having two node cluster (RAC) without any dataguard configuration.

Can you please provide the connection string?

Regards,

Surendra

It’s the simplest form - Listener layer with SCAN will solve all balancing and failovers.

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=SCANHOSTNAME)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=IFSPDB)))

From ChatGPT:
My Q:
an oracle question - on a very high level how do oracle SCAN addresses work for RAC environments?

ChatGPT said:

Thought for a couple of seconds

At a high level, SCAN (Single Client Access Name) is Oracle’s way of giving your RAC cluster a single “front‑door” address that automatically load‑balances and survives node changes without you having to touch client connect strings every time the cluster changes. Here’s how it works in broad strokes:

1. Single DNS name, multiple IPs

   • You configure one DNS entry (e.g. myrac-scan.acme.com) that resolves—via round‑robin or GNS—to three (or more) virtual IP addresses.

   • Those IPs are the SCAN VIPs; clients don’t care which one they hit first.

2. SCAN Listeners on every node

   • Oracle Clusterware starts a “SCAN listener” process on each node, each binding to all of the SCAN VIPs.

   • That means wherever a given SCAN VIP is bound, there’s a listener ready to accept a connection.

3. Client connects to SCAN

   • Your JDBC, OCI, SQL*Plus, etc. uses the SCAN name in its TNS string.

   • DNS gives back one of the SCAN IPs; the client opens a connection there.

4. Listener redirects to local node listener

   • The SCAN listener accepts the request, then looks at service registration info to decide which node (and which local listener port) actually hosts the requested service.

   • It hands the client back a redirect (in Oracle parlance, a “CONNECT_REDIRECT” packet) pointing to the real listener address for that service on a specific node.

5. Client reconnects to the chosen node

   • The client transparently reconnects to that node’s local listener (often on port 1521) and establishes the session.

   • All of this happens in a fraction of a second.

6. Automatic load balancing & failover

   • Because DNS round‑robins among the SCAN IPs, new connections naturally spread across the three SCAN listeners, then through the redirect logic are balanced across your actual database instances.

   • If a node fails or you add nodes, you don’t need to change any client network configuration—DNS and Clusterware handle it.

Why SCAN matters

• Simplicity: Clients use a single connect‑string forever.

• Elasticity: Add or drop RAC nodes without client‑side reconfiguration.

• Load‑balance: DNS + Clusterware steer connections evenly.

• High availability: SCAN VIPs float to surviving nodes automatically on failures.

That’s the bird’s‑eye view: a one‑name‑to‑rule‑them‑all approach that masks the complexity of your growing and changing RAC farm.