9
Configuring Clients and High Availability Features for Real Application Clusters

This chapter describes how to configure clients and the high availability features of Oracle Real Application Clusters. The topics in this chapter are:

• Configuring Clients for Real Application Clusters
• Transparent Application Failover in Real Application Clusters
• Primary/Secondary Instance Feature in Real Application Clusters
• Real Application Clusters Guard II

Configuring Clients for Real Application Clusters

This section describes client configuration issues not covered by the database creation process. You should configure the client with a net service name for the database. This entry should have an address list of all the listeners in the database. Additionally, set the connect-time failover and client load balancing options.

If the first listener fails, connect time failover instructs the client to failover to the next listener in the address list. Client load balancing instructs the client to randomly select a listener address which distributes the load to avoid overburdening a single listener.

There are two cases in which a client attempts to connect to another address:

• If the listener is down
• If the listener is up, but it has not received registration for the given SERVICE_NAME, so the instance is down

  Note: The PMON process waits 60 seconds to reconnect to a failed listener. You can use the ALTER SYSTEM REGISTER SQL statement to force a reconnection attempt to occur immediately. The registration will only succeed if the listener is running.

The second case implies that the client only attempts to connect to the next listener if the first listener fails. The client also attempts to connect to the next listener if the first listener is running and if that listener does not have a record of the SERVICE_NAME given in CONNECT DATA.

Together, connect-time failover and client load balancing instruct the client to randomly choose an address. If the chosen address fails, then the connection request fails over to the next address. If an instance fails, then the client can connect using another instance.

Implementation of Client Configurations

To control how a client executes connection attempts, configure multiple listening addresses and set FAILOVER to ON and LOAD_BALANCE to ON for the address list. For example:

db.us.acme.com= 
 (description= 
  (load_balance=on)
  (failover=on)
  (address=(protocol=tcp)(host=db1-server)(port=1521))
  (address=(protocol=tcp)(host=db2-server)(port=1521)) 
  (connect_data=
     (service_name=db.us.acme.com)))

Testing the Oracle Net Configuration

Use the following procedures to ensure that your Oracle networking files are configured correctly:

1. On any node or client machine, connect to an instance using the following command:

   CONNECT SYSTEM/password@net_service_name
   
   

   Oracle displays a "Connected" message.

   If Oracle displays a connection error, then troubleshoot your installation. Typically, an error is the result of a problem with the IP address, host name, service name, or instance name.

2. On one node, increase the employee Miller's salary by $1000 and commit the change:

   UPDATE EMPLOYEE
   set sal = sal + 1000
   where ename = 'miller';
   commit;
   
   

3. On the other nodes, select the EMPLOYEE table again:

   SELECT * FROM EMPLOYEE;
   
   

   Miller's salary should now be $2,300, indicating that all the instances can access the records in the database.

Transparent Application Failover in Real Application Clusters

This section discusses the Real Application Clusters-specific aspects of transparent application failover (TAF). This section covers the following topics:

• FAILOVER_MODE Parameters
• TAF Implementation in Real Application Clusters
• Transparent Application Failover Verification

To enable TAF, manually configure a net service name in the CONNECT_DATA portion of the connect descriptor. In the net service name you can include the FAILOVER_MODE and INSTANCE_ROLE parameters.

TAF instructs Oracle Net to move a failed connection to a different instance. This enables users to continue working by using the new connection as if the original connection had never failed.

FAILOVER_MODE Parameters

To configure TAF, you must also set several FAILOVER_MODE parameters in the CONNECT_DATA portion of a connect descriptor to specify failover mode. For example, you can specify the type of failover, the speed at which Oracle should process it, as well as the retry behavior.

TAF Implementation in Real Application Clusters

Depending on the FAILOVER_MODE parameters, you can implement TAF using any of the following methods:

• Implementing TAF with Connect-Time Failover and Client Load Balancing
• Retrying Connections
• Pre-Establishing Connections

Implementing TAF with Connect-Time Failover and Client Load Balancing

You can implement TAF with connect-time failover and client load balancing for multiple addresses. In the following example, Oracle Net connects randomly to a listener address on node db1-server or db2-server. If the instance later fails, then Oracle Net fails over to the other node's instance, preserving any SELECT statements in progress.

db.us.acme.com= 
 (description=  
  (load_balance=on) 
            /* only connect time load balancing and connection load balancing */
  (failover=on)            /* only connect time failover */
  (address=  
       (protocol=tcp)  
       (host=db1-server)  
       (port=1521)) 
 (address=  
       (protocol=tcp)  
       (host=db2-server)  
       (port=1521)) 
  (connect_data= 
     (service_name=db.us.acme.com) 
   (failover_mode=
     (type=select) 
     (method=basic))))

Retrying Connections

TAF also provides the ability to automatically retry connecting with the RETRIES and DELAY parameters if the first connection attempt fails. In the following example, Oracle Net attempts to connect to the listener on db1-server. If the initial connection fails, Oracle moves the connection to addresses in the description lists.

db.us.acme.com=  
 (description= 
  (address=  
       (protocol=tcp)  
       (host=db1-server)  
       (port=1521)) 
  (address=  
       (protocol=tcp)  
       (host=db2-server)  
       (port=1521)) 
   (connect_data= 
     (service_name=db.us.acme.com) 
   (failover_mode=
     (type=select) 
     (method=basic)
     (retries=20)
     (delay=15))))

Pre-Establishing Connections

You can pre-establish a backup connection but you must explicitly specify the initial and backup connections. In the following example, Oracle Net connects to the listener on db1-server. If db1-server fails after the connection, then Oracle Net fails over to db2-server, preserving any SELECT statements in progress. If the pre-connect to the failed instance does not succeed at connect time, then fail back to this instance is no longer possible.

db.us.acme.com= 
 (description=  
  (address=  
       (protocol=tcp)  
       (host=db1-server)  
       (port=1521)) 
  (connect_data= 
     (service_name=db.us.acme.com) 
     (instance_name=db1-server) 
     (failover_mode=
       (backup=db2.us.acme.com) 
       (type=select) 
     (method=preconnect))))
db2.us.acme.com= 
 (description=  
  (address=  
       (protocol=tcp)  
       (host=db2-server)  
       (port=1521)) 
  (connect_data= 
     (service_name=db.us.acme.com) 
     (instance_name=db2-server)
     (failover_mode=
     (backup=db1.us.acme.com)
     (type=select)
     (method=preconnect))
     ))

Transparent Application Failover Verification

Use the V$SESSION view to obtain information about the connected clients and their TAF status. For example, query the FAILOVER_TYPE, FAILOVER_METHOD, and FAILED_OVER columns to verify that you have correctly configured TAF as in the following SQL statement:

SELECT MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER, COUNT(*)
FROM V$SESSION
GROUP BY MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER;

The output before failover resembles the following:

MACHINE              FAILOVER_TYPE FAILOVER_M FAI   COUNT(*)
-------------------- ------------- ---------- --- ----------
db1-server           NONE          NONE       NO          11
db2-server           SELECT        PRECONNECT NO           1

The output after failover is:

MACHINE              FAILOVER_TYPE FAILOVER_M FAI   COUNT(*)
-------------------- ------------- ---------- --- ----------
db2-server           NONE          NONE       NO          10
db2-server           SELECT        PRECONNECT YES          1

Primary/Secondary Instance Feature in Real Application Clusters

The Primary/Secondary Instance feature specifies that the primary instance accepts primary connections and the secondary instance only accepts secondary connections. You can only implement this feature for two-instance Real Application Clusters environments as described in this section under the following headings:

• Configuring the Primary/Secondary Instance Feature
• Client Configuration in Primary/Secondary Instance Configurations
• Listener Configuration in Primary/Secondary Instance Configurations
• Connecting to Secondary Instances in Primary/Secondary Instance Configurations
• Warming the Library Cache on the Secondary Instance

Configuring the Primary/Secondary Instance Feature

Enable the primary and secondary instance feature by configuring the ACTIVE_INSTANCE_COUNT parameter to 1 on both instances. The first instance to start is the primary instance. The primary instance registers its status and database service information with its local listener through dynamic service registration.

If you configure shared server with the LISTENER attribute, then the primary instance can also register with the secondary instance's listener. The LISTENER parameter can specify a listener name alias for the listener to which the dispatcher(s) register information. The alias resolves to a list of listener addresses through a naming method, such as a tnsnames.ora file. This enables the primary instance to accept connections from its local listener, as well as from the secondary instance's listener.

Clients connected to the failed primary instance move to the secondary instance if you have configured TAF. Clients connecting to the database after the primary instance fails are automatically routed to the secondary instance.

Client Configuration in Primary/Secondary Instance Configurations

Oracle Corporation recommends configuring clients with a connect descriptor if the clients use address lists that contain the listener addresses for the primary and secondary instances. When you configure clients, set the LOAD_BALANCE parameter to OFF because all client connections can only go to the primary instance. FAILOVER is set to ON by default for an address list, so you do not need to explicitly specify the FAILOVER parameter. An example of the client configuration follows:

db.us.acme.com= 
 (description= 
  (load_balance=off) /* connection load balancing */ 
  (address=(protocol=tcp)(host=db1-server)(port=1521))
  (address=(protocol=tcp)(host=db2-sevrer)(port=1521)) 
  (connect_data=
     (service_name=db.us.oracle.com)))

Oracle does not recommend setting LOAD_BALANCE to ON. If you do, half of the connections attempt to connect to the listener on the secondary instance that fails to provide connections. The client then attempts to connect using the listener's node on the primary instance, which succeeds.

Listener Configuration in Primary/Secondary Instance Configurations

Remove the static service information sid_LIST_listener_name entry from the listener.ora file. This enables the listener to only use information obtained from dynamic service registration. For example, the sid_list_listener entry has been removed from the listener.ora file in the right column of Table 9-1:

Table 9-1  Listener.ora Example without sid_list_listener Entry

listener= 
 (description=  
  (address=
   (protocol=tcp)
   (host=db1-server)
   (port=1521)))
sid_list_listener= 
 (sid_desc=
 (oracle_
home=/private/system/db)
 (sid_name=db1))

listener= 
 (description=  
  (address=
   (protocol=tcp)
   (host=db1-server)
   (port=1521)))

Connecting to Secondary Instances in Primary/Secondary Instance Configurations

Connecting to the secondary instance may be preferable even when the primary instance is active, for example, to perform a batch operation. The optional INSTANCE_ROLE parameter in the CONNECT_DATA section of a connect descriptor enables you to do this. In addition to explicitly specifying connections to primary or secondary instances, you can also use this parameter to configure Transparent Application Failover (TAF) pre-connections to secondary instances.

Warming the Library Cache on the Secondary Instance

Retaining information about frequently executed SQL and PL/SQL statements in the library cache improves performance. In Real Application Clusters primary and secondary instance configurations, the library cache associated with the primary instance contains up-to-date information. During failover, the benefit of that information is lost unless the library cache on the secondary instance was previously populated.

Use the DBMS_LIBCACHE package to transfer information in the library cache of the primary instance to the library cache of the secondary instance. This process is called warming the library cache. It improves performance immediately after failover because the new primary library cache does not need to be populated with parsed SQL statements and compiled PL/SQL units.

Real Application Clusters Guard II

The installation and setup of active/active cluster configurations is greatly simplified with Real Application Clusters Guard II. However, Real Application Clusters Guard II is not merely a two-node configuration. Rather, the size of a Real Application Clusters Guard II environment is only limited by the limitations of your hardware and operating system.

In Real Application Clusters Guard II, all instances are active and able to support services, which are sets of related business functions. Instances can support a particular service while they are also available to support other services. The client selects a database service as part of the connection request where the middle-tier specifies the SERVICE_NAME parameter in the tnsnames.ora file's connect data description for each service in the connection pool.

The notion of a database service provides a single-system image for managing competing applications that run within a single instance and across multiple instances. The manageability features of the Real Application Clusters Guard II environment allow you to more easily control the instances on which applications run as well as their failover properties and failover targets.