1. Introduction
One of the biggest challenges in a clustered database environment is providing a single, stable connection point for client applications. Before Oracle Database 11g Release 2, clients had to know the hostname or IP address of every RAC node. Whenever a new node was added or removed, client connection strings often needed to be updated.
To solve this problem, Oracle introduced SCAN (Single Client Access Name).
SCAN provides a single hostname that clients use to connect to the RAC database. Oracle Clusterware and the SCAN Listeners automatically redirect client connections to the most appropriate RAC node, providing load balancing, high availability, and simplified administration.
Definition:
SCAN (Single Client Access Name) is a cluster-wide virtual hostname that provides a single entry point for all client connections to an Oracle RAC database.
2. Why SCAN is Required
Before SCAN (Oracle RAC 10g)
Clients needed to specify every node in the connection string.
Example:
Node-1 : racnode1.bsl.com
Node-2 : racnode2.bsl.com
Node-3 : racnode3.bsl.com
Connection String:
(DESCRIPTION=
(ADDRESS=(HOST=racnode1))
(ADDRESS=(HOST=racnode2))
(ADDRESS=(HOST=racnode3))
)
Problems:
Complex client configuration
Difficult maintenance
Client updates required when adding/removing nodes
Harder to manage large clusters
After SCAN (Oracle 11gR2 and Later)
Clients use a single hostname:
prod-scan.company.com
Oracle automatically routes the connection to an appropriate node.
3. What is SCAN?
SCAN consists of:
One SCAN Name (DNS hostname)
Typically three SCAN IP addresses
Three SCAN Listeners (recommended)
Example:
SCAN Name
prod-scan.bsl.com
↓
192.168.1.210
192.168.1.211
192.168.1.212
Oracle Clusterware manages the SCAN listeners as cluster resources.
4. Oracle RAC SCAN Architecture
Client Applications
(SQL*Plus / JDBC / OEM / ODP.NET)
│
│
DNS Lookup (SCAN Name)
│
prod-scan.company.com
│
┌───────────────────────────────────────┐
│ DNS Resolution │
└───────────────────────────────────────┘
│ │ │
▼ ▼ ▼
SCAN IP-1 SCAN IP-2 SCAN IP-3
│ │ │
▼ ▼ ▼
SCAN Listener1 SCAN Listener2 SCAN Listener3
│
▼
Cluster Resource Manager
│
▼
Determines Best Available Instance
│
┌────────┴────────┐
▼ ▼
Node-1 Node-2
Local Listener Local Listener
│ │
▼ ▼
Instance-1 Instance-2
5. Components of SCAN Architecture
| Component | Purpose |
|---|---|
| SCAN Name | Single hostname used by clients |
| DNS | Resolves SCAN name to multiple SCAN IPs |
| SCAN VIP | Virtual IP for SCAN Listener |
| SCAN Listener | Accepts initial client connection |
| Local Listener | Listener running on each RAC node |
| Database Service | Determines which instance receives the connection |
| Oracle Clusterware | Manages SCAN resources |
6. SCAN Name
Clients never connect directly to a node.
Instead they connect to:
prod-scan.bsl.com
Advantages:
One hostname
Easy administration
No client changes when nodes are added
Simplified configuration
7. SCAN IP Addresses
Oracle recommends three SCAN IPs.
Example:
| SCAN Name | SCAN IP |
|---|---|
| prod-scan.bsl.com | 192.168.1.210 |
| prod-scan.bsl.com | 192.168.1.211 |
| prod-scan.bsl.com | 192.168.1.212 |
The DNS server returns these IPs using round-robin resolution.
8. SCAN Listeners
Each SCAN IP hosts one SCAN Listener.
Example:
SCAN-1
↓
SCAN Listener-1
↓
Node-1
SCAN-2
↓
SCAN Listener-2
↓
Node-2
SCAN-3
↓
SCAN Listener-3
↓
Node-3
A SCAN Listener can run on any RAC node. If a node fails, Oracle Clusterware automatically relocates the SCAN Listener to another healthy node.
9. Local Listener
Every RAC node runs its own Local Listener.
Example:
Node-1
↓
Local Listener
↓
Instance-1
The Local Listener:
Registers local database services
Accepts redirected client connections
Creates server processes
10. Dynamic Service Registration
Oracle instances automatically register themselves with the Local Listener using PMON (or equivalent background registration mechanisms in newer releases).
The Local Listener then shares service information with the SCAN Listener.
Registered information includes:
Instance Name
Database Name
Services
Load Information
Instance Status
11. Complete Client Connection Flow
Step 1
Application connects:
prod-scan.bsl.com
Step 2
DNS returns:
192.168.1.210
192.168.1.211
192.168.1.212
Step 3
Client connects to one SCAN Listener.
Client
↓
SCAN Listener
Step 4
SCAN Listener checks:
Which services are available?
Which instances provide the requested service?
Which instance is least loaded?
Step 5
SCAN Listener redirects the client.
SCAN Listener
↓
Local Listener
↓
Node-2
Step 6
Local Listener creates a dedicated (or shared, if configured) server process.
Listener
↓
Dedicated Server Process
↓
Instance
Step 7
Client communicates directly with the database instance.
The SCAN Listener is no longer involved in SQL processing after the initial connection.
12. SCAN Connection Flow Diagram
Application
│
▼
SCAN Name (prod-scan.bsl.com)
│
▼
DNS (3 SCAN IPs)
│
▼
SCAN Listener
│
▼
Local Listener
│
▼
Database Service
│
▼
Oracle Instance
│
▼
SQL Processing
13. Load Balancing
SCAN supports Connection Load Balancing.
Example:
100 Users
↓
SCAN Listener
↓
40 Users → Node-1
35 Users → Node-2
25 Users → Node-3
Distribution depends on service configuration and instance load.
14. Node Failure Scenario
Suppose:
Node-2 crashes.
Before Failure:
Node-1
Node-2
Node-3
After Failure:
Node-1
Node-3
Oracle Clusterware:
Detects node failure.
Restarts the SCAN Listener (if necessary) on another node.
Relocates affected services according to policy.
New client connections are redirected to healthy instances.
15. Adding a New RAC Node
Without SCAN:
Modify every client connection string.
Add the new node information.
With SCAN:
Add Node
↓
Cluster Registers Services
↓
Clients Continue Using Same SCAN Name
No client-side connection string changes are required.
16. SCAN vs VIP
| SCAN | VIP |
|---|---|
| Single client entry point | Node-specific virtual IP |
| Cluster-wide | One per RAC node |
| Uses SCAN Listeners | Uses Local Listener |
| Simplifies client configuration | Provides fast node failover |
| Load balancing | Node availability |
17. SCAN vs Local Listener
| SCAN Listener | Local Listener |
|---|---|
| Accepts initial client connection | Accepts redirected connection |
| Cluster-wide | Runs on each node |
| Redirects client | Establishes database session |
| Managed by Clusterware | Associated with a specific node |
18. Useful SCAN Commands
Check SCAN Configuration
srvctl config scan
Example:
SCAN name: prod-scan.bsl.com
Check SCAN Listener
srvctl status scan_listener
Check SCAN VIP
srvctl status scan
View Listener Status
lsnrctl status
View Cluster Resources
crsctl stat res -t
19. Real-Time Production Scenario
Scenario: One RAC Node Goes Down
Environment
3-node Oracle RAC
Banking application
SCAN configured with three IPs
Incident
Node-2 unexpectedly crashes due to a hardware failure.
What Happens?
CSSD detects heartbeat loss.
CRSD marks Node-2 resources offline.
SCAN Listener previously running on Node-2 is relocated to another node if required.
Services configured on Node-2 are restarted on surviving instances according to policy.
New client connections continue using
prod-scan.company.com.The SCAN Listener redirects new sessions to Node-1 or Node-3.
Result
Existing sessions on Node-2 are disconnected unless protected by Application Continuity.
New connections continue successfully.
Users typically experience minimal disruption.
20. SCAN Best Practices
Configure three SCAN IP addresses for production clusters.
Register the SCAN name in DNS (or use Grid Naming Service where appropriate).
Ensure SCAN resolves correctly from client systems.
Do not hard-code node hostnames in client applications.
Use database services instead of instance names.
Monitor SCAN Listener status daily.
Verify that dynamic service registration is functioning.
Test failover and connection redirection during maintenance windows.
21. Common SCAN Issues and Troubleshooting
| Problem | Possible Cause | Verification |
|---|---|---|
| Clients cannot connect | DNS resolution failure | nslookup prod-scan.bsl.com |
| SCAN Listener offline | Cluster resource issue | srvctl status scan_listener |
| Services not visible | Dynamic registration issue | lsnrctl status |
| Uneven connection distribution | Service configuration | srvctl config service -d <db_name> |
| Connection delays | Network or listener problems | Check listener logs and Clusterware resources |
22. Summary
The SCAN Listener Architecture is one of the most significant enhancements introduced in Oracle RAC. It provides a single, cluster-wide connection point that hides the complexity of multiple RAC nodes from client applications. Through DNS resolution, SCAN Listeners, Local Listeners, and database services, Oracle automatically directs client connections to the most appropriate database instance while supporting connection load balancing and high availability.
By eliminating node-specific connection strings and allowing seamless cluster expansion without client reconfiguration, SCAN greatly simplifies RAC administration and improves application resilience. In modern Oracle RAC deployments, SCAN, together with VIPs, Oracle Clusterware, and database services, forms the foundation of a robust and highly available client connectivity architecture.
No comments:
Post a Comment