Database Reference
In-Depth Information
(ADDRESS=(host=ca2)(port=1522))
(ADDRESS=(host=ca3)(port=1522)))
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(host=ny1)(port=1522))
(ADDRESS=(host=ny2)(port=1522))
(ADDRESS=(host=ny3)(port=1522)))
(CONNECT_DATA=
(SERVICE_NAME=PO)
(REGION=ca))
)
In addition to the failover specification among address_list sections, each address_list section also specifies
multiple addresses with LOAD_BALANCE set to ON. Essentially, a new connection from the California region will try
the first address_list as load_balance is set to OFF by default for description list. Then, an address from the chosen
address_list will be used to send packets to GDS listeners as load_balance is set to ON for that address_list.
Note that traditionally, a VIP listener or a SCAN listener is specified in the ADDRESS section. But, in the case
of GDS connect string, these are not traditional listeners, but
GDS listeners
. This feature was introduced in version 12c.
GDS listeners can be visualized as global SCAN listeners. Oracle recommends three GDS listeners per region, very
similar to the three SCAN listeners in a RAC cluster. Also, services are managed by srvctl command and global
services are managed by the gsdctl command interface.
GDS listeners connect to the database and register as subscribers of the servicemetric queue. Any topology
changes and Load Balancing Advisories (LBAs) are propagated to GDS listeners, and the GDS listeners use the LBAs
to forward connections to a database that can provide better quality of service.
GDS are useful with the Active Data Guard setup also. With the Active Data Guard feature, it is possible to use
a data guard instance for read-only activity. In many cases, the need arises for a global failover; that is, if the Active Data
Guard database is not available, then failover will be to the primary database and vice versa. The GDS feature will be
handy in implementing this requirement. Refer to the GDS Concept and Administration Guide for more details.
Failover in RAC
A RAC database offers many failover techniques. Failover methods can be classified into two categories: connection
time and runtime failover methods.
Transparent Application Failover
(TAF) is a reactive runtime failover method,
wherein database connection will automatically fail over to a surviving instance if the current instance fails.
Fast Connection Failover
(FCF) is a proactive runtime failover technique. Changes in node availability, service
failures, etc., are propagated to the application, and the application will proactively recycle connections even before
the application encounters connection-related errors.
TAF
TAF fails over the connection to a surviving instance after encountering an instance failure. TAF can operate in either
SESSION or SELECT failover mode.
•
In a SESSION failover mode, if a connection is severed then the connection will fail over
to a surviving instance. Essentially, the connection is reattempted automatically. Only the
connection is restarted, and the application must detect failures and restart failed workload.
•
In a SELECT failover mode, the client-side driver remembers the cursor fetch details, and if
the current connection is severed, then the connection will fail over to surviving node. The
SELECT statement is re-executed, rows are fetched from the cursor and scrolled to the point of
failure in the cursor fetch operation, and rows are returned from the point of failure.
