Optimize Distributed Workload - Expert Oracle RAC Performance Diagnostics and Tuning - page 500

For the application to be ONS aware, the application using FAN should specify the system property
-oracle.ons.oraclehome = < location-of-ons-home> and ensure that the ons.jar file is located on the application
CLASSPATH . The ons-home must be the $GRID_HOME where ONS is installed on the client machine.
Transaction Guard
As discussed in the previous sections, in-flight transactions fail, and users tend to get notified by the application
through a return message that a transaction was not completed successfully or they are falsely notified that a
transaction did complete. The persistence layer of the application is not able to provide the right response back to the
user. The user ends up guessing or falsely trying to create the transaction again.
In Oracle Database Version 12c (12.1.0), Oracle has introduced a feature called the transaction guard that makes
several attempts on failed transactions before actually declaring it could not be processed successfully.
Transaction guard provides a new protocol and API for application developers to include in their code to monitor
and react to any planned and unplanned outages and protects the persistence layer from repeated submissions by
the users. This new logical transaction ID ( LTXID ) will help determine the outcome of the last transaction that was left
open in the database after an instance or database failure.
Database services can participate in the logical transaction process by including the -commit_outcome
and -retention parameters. These parameters are included in the database service definition process using the
srvctl command.
Load Balancing
Apart from providing system availability and failover functions, a clustered solution should also be able to balance
the available resources on all instances against the various user sessions and their workload. Meaning, based on
the intensity of the process on hand on the various nodes and the availability of resources, a clustered configuration
should be able to distribute load across all nodes in the cluster.
In a clustered database environment such as RAC, load balancing could be based on several criteria or goals:
for example, the number of physical connections to each instance in the cluster; the throughput of the various
instances in the cluster; the throughput (CPU) of the database servers on the cluster; the user traffic on a database
a listener to accept more connections; and so forth. Although all of these are potential methods in which the nodes
and or instances in a cluster could be load balanced, the most common and desired option is to load balance based
on response time of the instances. Under this method, the load is not balanced based on the number of sessions but
based on the amount of resources available on the respective instances.
RAC provides several types of load balancing that are broadly classified based on the type of user connections to
the database server.
Client Load Balancing
When a user makes a connection to the database using the definitions provided in the tnsnames.ora file on the
client machine, the connection is routed to one of the available nodes. This routing is based on the listeners on the
respective nodes being able to accept the connection request from the user or application:
TAPS =
(DESCRIPTION=
(ADDRESS_LIST=
(FAILOVER=ON)
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=PRODDB-SCAN.SUMMMERSKY.BIZ)(PORT=1521))
)