Database Reference
In-Depth Information
PO =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(
HOST=ebs.example2.com
)
(PORT=20000)))
(CONNECT_DATA=(SERVICE_NAME=PO)
)
)
Support of SCAN listeners in the second network is an important feature in an enterprise database cluster with
multiple network segments and domains, especially after major business events such as a merger of two companies.
Guidelines for SCAN Listeners
Optimally configured SCAN IP addresses and SCAN listeners are essential production components from 11.2 and
later. The SCAN feature greatly reduces administration overheads, as you can publish the TNS connection string
once and that connection string is not affected by RAC cluster topology changes. As SCAN listeners are lightweight
forwarders, even if you have numerous nodes in a cluster, just three SCAN listeners are able to service an onslaught of
connection requests. In fact, in a busy, connection-intensive production cluster, VIP listeners are bottlenecks, while
SCAN listeners are able to withstand spurious connection requests easily.
Multiple DNS servers with failover and load balancing represent an extra layer of protection to avoid a single
point of failure. This load balancing between DNS servers is usually a responsibility of network administrators. If you
configure GNS servers, Clusterware manages GNS daemons and VIPs. If a server running GNS daemon or VIP fails,
then the Clusterware will automatically fail over the GNS daemon and VIP to a surviving instance.
In a single segment network cluster, the local_listener parameter should refer to the VIP listener running on the
local node, and the remote_listener parameter should refer to the SCAN listeners using EZConnect syntax specifying
the DNS alias of the SCAN IP address and port number. Do not specify remote VIP listeners from another node in the
remote_listener parameter, as that can cause cross-registration and accidental connection forwarding to the other node.
Global Database Services (12c)
Oracle Database version 12c introduces the concept of Global Database Services (GDS). Services discussed so far in
this chapter are those that distribute the workload between instances of a database. In a truly globalized environment,
however, databases are replicated using tools such as GoldenGate, Streams, etc. Global services provide a mechanism
to fail over the connections globally between the databases.
It is easier to explain the concept of GDS with a connection string example. Consider that there are two
databases kept in sync using a bidirectional replication technology. The database servicing the California region is
physically located near that region, and likewise the database servicing the New York region is physically located
there. Thus, clients in the California region will benefit by connecting to the California database during normal
operating conditions, and in the case of failure of the database in California, the connections should fail over to the
New York database, and vice versa. Until version 11.2, this was achieved using a connect time failover connect string.
As of version 12c, the connect string for the California region specifies two address_list sections. These two
address_lists have the FAILOVER attribute set to ON but load_balance set to OFF. This connection string will try the
connection to the first address_list in the connect string; that is, the application will connect to the California database.
If that database does not respond before TCP timeout, then the connection will fail over to the New York database.
(DESCRIPTION=
(FAILOVER=on)
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(host=ca1)(port=1522))
