Академический Документы
Профессиональный Документы
Культура Документы
No transaction But Select, 2nd Select NodeA dies between the 2 selects
RETRIES: Use this parameter to specify number of times to attempt to connect after a
failover. If DELAY is specified but RETRIES is not specified, RETRIES default to five
retry attempts.
DELAY: Use this parameter to Specify the amount of time in seconds to wait between
connect attempts. If RETRIES is specified but DELAY is not specified, DELAY default
to one second
Session Based — Session based load balancing takes into account the number of
sessions connected to each node and then distributes the connections to balance the
number of sessions across the different nodes.
The above two options instruct clusterware on how to handle this service.
[-e {NONE|SESSION|SELECT}]
This defines the type of TAF whether SESSION or SELECT.
[-m {NONE|BASIC}]
This defines the method of TAF.
[-z <failover_retries>]
This defines the the number of times to attempt to connect after a failover.
[-w <failover_delay>]
This defines the amount of time in seconds to wait between connect attempts.
Grid User
$srvctl add service -d windy -s Clienttafservpre -r windy1 -a windy2 -P preconnect
The Fast Connection Failover (FCF) feature is a Fast Application Notification (FAN)
client implemented through the connection pool.
The feature requires the use of an Oracle JDBC driver and an Oracle RAC database
FCF will support from 10.1.X & later versions
FCF provides is very fast notification of the failure and the ability to reconnect
immediately using the same URL. When a RAC node fails the application will receive
an exception. The application has to handle the exception and reconnect.
Reason its depends on ONS reason its doesn't required negative acknowledge.
pds.setConnectionPoolName("FCFSamplePool");
pds.setFastConnectionFailoverEnabled(true);
pds.setONSConfiguration("nodes=racnode1:4200,racnode2:4200\nwalletfile= /oracle11/onswalletfile");
pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource");pds.setURL("jdbc:oracle:thin@(DESCRIPTION= "+
"(LOAD_BALANCE=on)"+
"(ADDRESS=(PROTOCOL=TCP)(HOST=racnode1) (PORT=1521))"+
"(ADDRESS=(PROTOCOL=TCP)(HOST=racnode2) (PORT=1521))"+
"(CONNECT_DATA=(SERVICE_NAME=service_name)))");
...
pds.setFastConnectionFailoverEnabled(true);
FCF supports unplanned outages. Dead connections are rapidly detected and then
the connections are aborted and removed from the pool. Connection removal relies
on abort to rapidly sever socket connections in order to prevent hangs. Borrowed
and in-use connections are interrupted only for unplanned outages.
FCF supports planned outages. Borrowed or in-use connections are not interrupted
and closed until work is done and control of the connection is returned to the pool.
FCF recognizes new nodes that join an Oracle RAC cluster and places new
connections on that node appropriately in order to deliver maximum quality of
service to applications at run-time. This facilitates middle-tier integration of Oracle
RAC node joins and work-request routing from the application tier.
FCF distributes runtime work requests to all active Oracle RAC instances.
FCF provides is very fast notification of the failure and the ability to reconnect immediately
using the same URL. When a RAC node fails the application will receive an exception. The
application has to handle the exception and reconnect.
The JDBC driver does not re-target existing connections. If a node fails the application must
close the existing connection and get a new one. The way the application knows that the
node failed is by getting an exception. There is more than one ORA error that can be thrown
when a node fails,the application must be able to deal with them all.
An application may call isFatalConnectionError() API on the
OracleConnectionCacheManager to determine if the SQLException caught is fatal.
If the return value of this API is true, we need to retry the getConnection on the
DataSource.xxxxx
TAF is a database session-level connection failover FCF is an application-level failover mechanism: the
mechanism: it works via the OCI interface only so database-tier notifies the application-tier by means of
applies to applications using thick JDBC drivers and a FAN (fast application notification) message,
those using the OCI libraries (e.g. written in C, like distributed via the ONS (Oracle Notification Service)
OID). During failover a new session will be started on daemons. Where database connections are pooled,
an alternative node (though it can be pre-connected as offered by Oracle JDBC, the driver then has the
ahead of the failure) and this can optionally re-open opportunity to clean up stale connections if a node
a cursor and advance it to the point it was at prior to fails. One very nice feature is that when a node
failure (providing underlying data hasn't changed). comes back online (i.e. a FAN message is sent out)
the JDBC driver will automatically make new
connections to the node to re-balance the pool.