Oracle Real Application Clusters (RAC) ensures high availability by supporting the
deployment of a database across multiple machines, thereby reducing the downtime due to hardware
failures or outages, planned or unexpected.
The following diagram shows how all transactions should be sent
to one Oracle RAC node at a time. If that database node goes down,
all Sterling B2B Integrator nodes
reconnect to the second available database node. This scenario requires
that load balancing is turned off, and provides better overall system
performance.
Important: Although both load balancing and high availability (failover) are possible,
running Sterling B2B Integrator with load
balancing turned on will result in performance degradation. For best performance, always turn load
balancing off.
The following table lists the features and benefits of Oracle RAC
when used with
Sterling B2B Integrator:
Features |
Benefits |
Load balancing
|
Oracle RAC supports initial connection time load balancing and runtime connection load balancing.
However, running Sterling B2B Integrator with
load balancing turned on is likely to result in performance issues.
On the client side (JDBC URL), you should set the parameter LOAD_BALANCE to
OFF.
On the server side, turn off load balancing on the database service.
|
SCAN (Single Client Access Name)
|
Available beginning in Oracle RAC 11g R2, SCAN allows you to set up RAC failover without
specifying nodes. Using traditional RAC in Sterling B2B Integrator, you configure the JDBC URL
to name an initial node and a failover node. With SCAN, you configure the JDBC URL so that SCAN
selects the initial node and fails over to the other available node.
A
benefit to using SCAN over traditional RAC is that you do not need
to update the URL when a node name changes. There is, however, a potential
performance degradation as SCAN searches for an available node.
|
High availability (Failover)
|
Oracle RAC supports high availability by
eliminating the dependence on a single server, where the chances of
database downtime are more due to hardware failure.
Initial connection time failover
In initial connection time failover, the database node availability is determined while
establishing the connection. The connection is established with the available database node.
However, if a database node goes down while a transaction is in progress, the transaction will fail
and throw an SQLException error, and a new connection will be established with the available
node.
Initial connection time failover can be
configured on the JDBC multi-instance URL on the client side by setting
this parameter:
FAILOVER=ON
Sterling B2B Integrator supports
two-node Oracle RAC setup.
To establish initial time connection
failover in Sterling B2B Integrator,
perform the following tasks:
Configure the following properties in ASI node and in the
customer_overrides.properties.in file in containers. You can set values for
these properties (in milliseconds) that are suitable for your operating environment.
Setting a
value too low would result in genuine SQL queries getting terminated
before they have a chance to be processed and return the dataset.
A value too high means that the application threads are holding connections
which are waiting on a query timeout for that duration and are not
available for other tasks. This could result in lower throughput.
An optimum setting depends on the customer's environment.
jdbcService.oraclePool.prop_oracle.jdbc.ReadTimeout=<milliseconds>
jdbcService.oraclePool_local.prop_oracle.jdbc.ReadTimeout=<milliseconds>
jdbcService.oraclePool_NoTrans.prop_oracle.jdbc.ReadTimeout=<milliseconds>
jdbcService.oracleUIPool.prop_oracle.jdbc.ReadTimeout=<milliseconds>
jdbcService.oracleArchivePool.prop_oracle.jdbc.ReadTimeout=<milliseconds>
- Perform one of the following:
- (UNIX or Linux®)
From the install_dir/install/bin directory, run
setupfiles.sh.
- (Windows) From the
install_dir\install\bin directory, run
setupfiles.cmd.
- Restart the ASI and container JVMs to apply the changes.
|
High availability (Failover), continued
|
Runtime connection failover
When one Oracle RAC
node goes down, the active connections from the node that went down
will failover to the active node. When the node that went down is
up and running again, the connections are not redistributed. You can
redistribute the connection pools by setting lifespan parameter to
a value greater than 0, which ensures that connection pools are terminated
after the lifespan value is met and load balancing occurs when new
connections are established. However, configuring a low value lifespan
may lead to connections being terminated quickly thereby losing the
benefit of connection pool.
To override all the Oracle pools lifespan to a value greater than 0, set the following value in
the customer_overrides.properties.in
file: jdbcService.<oraclepool>.lifespan=180000
|
Visibility Event Queues |
You can increase the number of visibility queues and event input queue
capacity in the customer_overrides.properties.in file to ensure that adapters
are responsive.To increase the default queue size and the thread counts, perform the following tasks:
-
Set the following values in the ASI node and in the
customer_overrides.properties.in file in containers:
dmivisibility.number_visibility_threads=6
dmivisibility.event_input_queue_capacity=3072
- Perform one of the following:
- (UNIX or Linux)
From the install_dir/install/bin directory, run
setupfiles.sh.
- (Windows) From the
install_dir\install\bin directory, run
setupfiles.cmd.
- Restart the ASI and container JVMs to apply the changes.
|
Fast Connection Failover (FCF) |
Sterling B2B Integrator does not support Fast Connection
Failover (FCF).
|
Transparent Application Failover (TAF) |
Sterling B2B Integrator does not support Transparent
Application Failover (TAF).
|