Database Reference
In-Depth Information
(ADDRESS=(PROTOCOL=tcp)( HOST=rac1.example.com ) (PORT=12000))
(ADDRESS=(PROTOCOL=tcp)( HOST=rac2.example.com ) (PORT=12000))
(ADDRESS=(PROTOCOL=tcp)( HOST=rac3.example.com ) (PORT=12000))
)
(CONNECT_DATA=
(SERVICE_NAME=PO)
)
)
The preceding connect string has some drawbacks:
1.
If we add another node to the cluster, say rac4.example.com , then connect strings must
be modified in numerous application configuration files. Worse, topology changes might
trigger changes to the tnsnames.ora file in thousands of user computers. This type of
configuration change requires seamless coordination.
2.
Similarly, if a node is removed from the RAC cluster, then connect strings must be altered
to eliminate unnecessary waits for a TCP timeout while creating new connections. For
example, consider that the rac1.example.com node is shut down for a prolonged period
of time. As connection strings can be configured to try to connect to all VIP listeners by
specifying load_balance=ON in the connection string, connection attempts will eventually
succeed, after a brief TCP timeout period. Nevertheless, there may be a delay induced
by TCP timeout duration. This connection delay is visible in applications that open new
connections aggressively.
3.
Without SCAN listeners, the connect time load balancing decision is performed by VIP
listeners. The use of VIP listeners for workload management is not optimal, as the load
balancing decision is not centralized, and so VIP listeners can redirect connections
inaccurately. VIP listeners do not use all service attributes for load balancing either.
SCAN listeners resolve these connect time issues and improve load balancing accuracy. SCAN listeners act as
a forefront of connection management, applications connect to SCAN listeners, and SCAN listeners act as a conduit
mechanism to forward connections to an instance that can provide better quality of service. A SCAN listener identifies
an instance to forward using the service metrics received from the database processes.
SCAN listeners know about topology changes. Any change in the cluster topology, such as addition of a node,
deletion of a node, etc., is propagated to SCAN listeners immediately. Application connects only to the SCAN
listeners, and so cluster topology changes have no effect on application connect strings.
The following is an example of a connect string utilizing the SCAN listener feature; this connect string specifies
the DNS alias of the SCAN IP address (also known as SCAN name) and the port number of SCAN listeners. In this
example, rac-scan.example.com , is the SCAN name and the listener listens on port 25000.
PO =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)( HOST=rac-scan.example.com ) (PORT=25000))
)
(CONNECT_DATA=(SERVICE_NAME=PO))
)
A new connection request using the preceding connect string is made according to the following high-level steps.
Figure 3-2 shows an example of a new connection to the SCAN listener.
 
Search WWH ::




Custom Search