Let's see an example of how we can configure FCF for JDBC clients.
aq_ha_notifications
is disabled. As we discussed, in 11gR2, it's possible to create role-specific database services so that service is automatically enabled or disabled whenever there is a role change. The following statements can be run on the primary and standby clusters to create a database service for a production service OLTP:srvctl add service -d ORCL_PRIM -s OLTP -r prim_node1,prim_node2 -l PRIMARY -q FALSE -e NONE -m NONE -w 0 -z 0
srvctl add service -d ORCL_STD -s OLTP -r std_node1,std_node2 -l PRIMARY -q FALSE -e NONE -m NONE -w 0 -z 0
If needed, the following statements will create a read-only service for reporting on the physical standby database:
srvctl add service -d ORCL_PRIM -s REPORTING -r prim_node1,prim_node2 -l PHYSICAL_STANDBY -q FALSE -e NONE -m NONE -w 0 -z 0
srvctl add service -d ORCL_PRIM -s REPORTING -r std_node1,std_node2 -l PHYSICAL_STANDBY -q FALSE -e NONE -m NONE -w 0 -z 0
CONNECT
descriptor."jdbc:oracle:thin:@" + "(DESCRIPTION_LIST=" + "(LOAD_BALANCE=off)" + "(FAILOVER=on)" + "(DESCRIPTION=" + "(ADDRESS_LIST=" + "(LOAD_BALANCE=on)" + "(ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_SCAN)(PORT=1521)))" + "(CONNECT_DATA=(SERVICE_NAME=OLTP)))" + "(DESCRIPTION=" + "(ADDRESS_LIST=" + "(LOAD_BALANCE=on)" + "(ADDRESS=(PROTOCOL=TCP)(HOST=STANDBY_SCAN)(PORT=1521)))" + "(CONNECT_DATA=(SERVICE_NAME=OLTP))))";
TCP_CONNTIMEOUT_STR
property so that the connection attempt fails over to the next host in the ADDRESS_LIST
list after the specified time.Properties prop = new Properties(); prop.put(oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STR, ""+5000); // 5000ms pds.setConnectionProperties(prop);
pds.setFastConnectionFailoverEnabled(true); pds.setONSConfiguration("nodes=prim_node1:6200,prim_node2:6200,std_node1:6200,std_node2:6200");
FAN is a notification mechanism in which Oracle doesn't wait for clients to detect any database status changes (such as service, instance, or if the database goes up or down), and quickly (as its name implies) informs clients about the events. If FAN is not used, clients need to wait for the TCP timeout duration to fail over to another specified connection. This duration can be very long and not suitable for our failover time target.
In addition to up/down events, FAN also notifies clients with load-balancing advisory events. Clients use this information and connect to the instance with the best response time.
It's possible to take advantage of FAN with the following methods: