5
Configuring High-Availability Features

This chapter describe how to configure Oracle Parallel Server high-availability features.

Specific topics discussed are:

• Transparent Application Failover

• Primary and Secondary Instances

Transparent Application Failover

Transparent application failover (TAF) instructs Net8 to fail over an established connection that has failed to a different instance. This enables the user to continue to work using the new connection as if the original connection had never failed.

TAF involves manual configuration of a net service name that includes the FAILOVER_MODE parameter included in the CONNECT_DATA portion of the connect descriptor.

This sections covers the following topics:

• FAILOVER_MODE Parameters

• TAF Implementation

• Verification

FAILOVER_MODE Parameters

The FAILOVER_MODE parameter must be included in the CONNECT_DATA portion of a connect descriptor. FAILOVER_MODE may contain the following parameters:

PARAMETER	Description
BACKUP	Specifies a different net service name for backup connections. A backup should be specified when using PRECONNECT to pre-establish connections.
TYPE (Required)	Specifies the type of failover. Three types of Net8 failover functionality are available by default to Oracle Call Interface (OCI) applications: SESSION: Fails over the session; that is, if a user's connection is lost, a new session is automatically created for the user on the backup. This type of failover does not attempt to recover selects. SELECT: Enables users with open cursors to continue fetching on them after failure. However, this mode involves overhead on the client side in normal select operations. NONE: This is the default, in which no failover functionality is used. This can also be explicitly specified to prevent failover from happening.
METHOD	Determines how fast failover occurs from the primary node to the backup node: BASIC: Establishes connections at failover time. This option requires almost no work on the backup server until failover time. PRECONNECT: Pre-establishes connections. This provides faster failover but requires that the backup instance be able to support all connections from every supported instance.
RETRIES	Specifies the number of times to attempt to connect. If DELAY is specified, RETRIES defaults to five retry attempts.
DELAY	Specifies the amount of time in seconds to wait between connect attempts. If RETRIES is specified, DELAY defaults to one second

TAF Implementation

Depending on the FAILOVER_MODE parameters, TAF can be implemented in a number of ways. Oracle recommends the following methods:

• Implementing TAF with Connect-Time Failover and Client Load Balancing

• Retrying a Connection

• Pre-Establishing a Connection

Implementing TAF with Connect-Time Failover and Client Load Balancing

TAF can be implemented with connect-time failover and client load balancing for multiple addresses. In the following example, Net8 connects randomly to one of the listener addresses on idops1 or idops2. If the instance fails after the connection, Net8 fails over to the other node's instance, reserving any SELECT statements in progress.

op.us.acme.com= 
 (description=  
  (load_balance=on) 
  (failover=on) 
  (address=  
       (protocol=tcp)  
       (host=idops1)  
       (port=1521)) 
 (address=  
       (protocol=tcp)  
       (host=idops2)  
       (port=1521)) 
  (connect_data= 
     (service_name=op.us.acme.com) 
     (failover_mode=
       (type=select) 
       (method=basic))))

Retrying a Connection

TAF also provides the ability to automatically retry connecting if the first connection attempt fails with the RETRIES and DELAY parameters. In the following example, Net8 tries to connect to the listener on idops1. If the connection attempt fails, Net8 waits 15 seconds before trying to connect again. Net8 attempts to connect up to 20 times

op.us.acme.com=  
 (description=  
  (address=  
       (protocol=tcp)  
       (host=idops1)  
       (port=1521)) 
  (connect_data= 
     (service_name=op.us.acme.com) 
     (failover_mode=
       (type=select) 
       (method=basic)
       (retries=20)
       (delay=15))))

Pre-Establishing a Connection

A backup connection can be pre-established. The initial and backup connections must be explicitly specified. In the following example, Net8 connects to the listener on idops1. If idops1 fails after the connection, Net8 fails over to idops2, reserving any SELECT statements in progress.

op.acme.com= 
 (description=  
  (address=  
       (protocol=tcp)  
       (host=idops1)  
       (port=1521)) 
  (connect_data= 
     (service_name=op.us.acme.com) 
     (instance_name=op1) 
     (failover_mode=
       (backup=op2.acme.com) 
       (type=select) 
       (method=preconnect))))
op2.acme.com= 
 (description=  
  (address=  
       (protocol=tcp)  
       (host=idops2)  
       (port=1521)) 
  (connect_data= 
     (service_name=op.us.acme.com) 
     (instance_name=op2)))

Verification

You can query FAILOVER_TYPE, FAILOVER_METHOD, and FAILED_OVER columns in the V$SESSION view to verify that TAF is correctly configured.

See Also: Oracle8i Reference for more information about the V$SESSION view

Primary and Secondary Instances

Primary and secondary instances specify that one instance accept connections and the other instance only accept connections if the primary instance fails. This feature can only be implemented for a two-instance Oracle Parallel Server.

This section contains the following sections:

• Overview

• Initialization File Configuration

• Client Configuration

• Listener Configuration

• Connecting to Secondary Instances

Overview

An instance is the primary instance when ACTIVE_INSTANCE_COUNT=1 is set in the initsid.ora initialization file and it has been started first. The primary instance registers its status and database service information with its local listener through dynamic service registration.

If multi-threaded server (MTS) is configured with the LISTENER attribute, the primary instance can also register with the secondary instance's listener. The LISTENER parameter can specify a listener name alias for the listener which the dispatcher(s) register information. This is resolved to a list of listener address through a service registration, such as a tnsnames.ora file. This enables the primary instance to accept connections from its local listener, as well as the secondary instance's listener.

A secondary instance also has the ACTIVE_INSTANCE_COUNT=1 setting but does not register with its listener. Therefore, the secondary instance cannot accept client connections through its listener.

If the primary instance fails, the secondary instance assumes the primary role and registers with its listeners. When the failed instance can once again start, it starts up as the secondary instance, and does not register its dedicated and shared servers with its listeners.

Clients connected to the failed primary instance are failed over to the secondary instance if TAF is configured. Clients that connect to the Oracle Parallel Server after the primary instance fails are routed automatically to the secondary instance.

See Also: "Transparent Application Failover" to configured TAF See Oracle8i Parallel Server Concepts for further general information about primary and secondary instances

Initialization File Configuration

To enable primary and secondary instance configuration, the instance initialization file, initsid.ora, must be configured with the ACTIVE_INSTANCE_COUNT parameter for each instance. The value must be 1 on both instances.

active_instance_count=1

Client Configuration

Oracle recommends configuring a connect descriptor on clients that use an address list that contains the listener addresses for the primary instance and the secondary instance.The LOAD_BALANCE parameter must be set to OFF, since all client connections can only go to the primary instance. FAILOVER is set to ON by default for a list of addresses, so it does not need to be explicitly specified. An example of the client configuration follows:

op.us.acme.com= 
 (description= 
  (load_balance=off)
  (address=(protocol=tcp)(host=idops1)(port=1521))
  (address=(protocol=tcp)(host=idops2)(port=1521)) 
  (connect_data=
     (service_name=op.us.oracle.com)))

Oracle does not recommend setting LOAD_BALANCE=ON. If you do, half of the connections try the listener on the secondary instance, which fail to provide a connection. The client then tries the listener on the primary instance, which succeeds. Oracle recommends sending all connections to the active instance first.

Listener Configuration

Remove the SID_LIST_listener_name information from the listener.ora file. This way, the listener only uses information obtained from dynamic service registration.

For example, the sid_list_listener entry has been removed from the following listener.ora file:

Old listener.ora File	Modified listener.ora File
listener= (description= (address= (protocol=tcp) (host=idops1) (port=1521))) sid_list_listener= (sid_desc= (oracle_home=/orahome81) (sid_name=op1))	listener= (description= (address= (protocol=tcp) (host=idops1) (port=1521)))

Connecting to Secondary Instances

In some situations administrators may wish to connect to the secondary instance even when the primary instance is alive. For example, the administrator may want perform some batch operation on the database.

Remote Login

Administrators can connect the secondary instance by logging into the machine and performing the batch operation.

Connecting from a Remote Client

Connecting to the secondary instance from a remote client involves some configuration that is dependent on whether or not the operational clients--that is, clients that are not performing administrative activities--are configured with connect descriptors that use SERVICE_NAMES or SIDs, as described in the following sections:

• Clients that Use Connect Descriptor with SERVICE_NAMES

• Clients that Use Connect Descriptor with SID

Clients that Use Connect Descriptor with SERVICE_NAMES

Administrators that have clients that use the SERVICE_NAME parameter in their connect descriptors can connect to the secondary instance with one of the following method:

• Create a connect descriptor for each instance that uses the SID of the instance in the CONNECT_DATA portion of the connect descriptor

  In the following example, the client can connect to idops1 and idops2 using op1.us.oracle.com and op2.us.oracle.com.

  op1.us.acme.com= 
   (description= 
    (address=(protocol=tcp)(host=idops1)(port=1521))
    (connect_data=
       (service_name=op1.us.oracle.com)))
  op2.us.acme.com= 
   (description= 
    (address=(protocol=tcp)(host=idops1)(port=1521))
    (connect_data=
       (service_name=op2.us.oracle.com)))
  
  

  No further configuration is required.

• Set or modify the GLOBAL_DBNAME parameter in the listener.ora file to a name that administrators alone can use and specify the name as the value for the SERVICE_NAME parameter in the CONNECT_DATA portion of the connect descriptor.

The installation and configuration process should have created a default listener.ora files without the GLOBAL_DBNAME parameter. You system may have listener.ora files that contain the GLOBAL_DBNAME parameter. The GLOBAL_DBNAME parameter specifies a value that typically matches the SERVICE_NAMES parameter in the initdb_name.ora file. In the following example, the SID_LIST_listener_name information specifies an instance named op1 and a database named op.us.acme.com.

listener= 
 (description=  
  (address=
   (protocol=tcp)
   (host=idops1)


   (port=1521)))
sid_list_listener= 
 (sid_desc=
   (oracle_home=/orahome81)
   (global_dbname=ops.us.acme.com)
   (sid_name=op1))

The SID_LIST_listener_name static information is not used, because the instance (if primary) has already registered this information with the listener through dynamic service registration, or the instance (if secondary) does not register with its local listener.

Since the service name is already registered with the listener, the value of the GLOBAL_DBNAME parameter, if present, is not used. Therefore, you can set the parameter to another value that is different from the registered service name.

If the GLOBAL_DBNAME is not present, add it and set it to a value that is different from the registered service name; if the GLOBAL_DBNAME is present, replace the GLOBAL_DBNAME value with different name than the service name.

This new static information does not match the information dynamically registered with the listener through the service registration. Therefore, operational clients are directed to the primary instance and administrative clients that specify the modified service name in the connect descriptor can connect to the secondary instance.

For example, the same listener.ora can modified with a global database name of adminop.us.acme.com.

Old listener.ora File	Modified listener.ora File
listener= (description= (address= (protocol=tcp) (host=idops1) (port=1521))) sid_list_listener= (sid_desc= (global_dbname=op.us.acme.com) (oracle_home=/orahome81) (sid_name=op1))	listener= (description= (address= (protocol=tcp) (host=idops1) (port=1521))) sid_list_listener= (sid_desc= (global_dbname=adminop1.us.acme.com) (oracle_home=/orahome81) (sid_name=op1))

The listener.ora file on the other node would also be modified in the following manner:

Old listener.ora File	Modified listener.ora File
listener= (description= (address= (protocol=tcp) (host=idops2) (port=1521))) sid_list_listener= (sid_desc= (global_dbname=op.us.acme.com) (oracle_home=/orahome81) (sid_name=op2))	listener= (description= (address= (protocol=tcp) (host=idops2) (port=1521))) sid_list_listener= (sid_desc= (global_dbname=adminop2.us.acme.com) (oracle_home=/orahome81) (sid_name=op2))

For those clients that are to perform remote administration, create separate connect descriptors for each of the instances. Ensure that the CONNECT_DATA portion uses a SERVICE_NAME that has a value that matches the new value for the listener.ora file's GLOBAL_DBNAME parameter.

In the following example, the client can connect to idops1 and idops2 using adminop1.us.oracle.com and adminop2.us.oracle.com.

adminop1.us.acme.com= 
 (description= 
  (address=(protocol=tcp)(host=idops1)(port=1521))
  (connect_data=
     (service_name=adminop1.us.oracle.com)))
adminop2.us.acme.com= 
 (description= 
  (address=(protocol=tcp)(host=idops1)(port=1521))
  (connect_data=
     (service_name=adminop2.us.oracle.com)))

See Also: Chapter 6, "Configuring Naming Methods,"in the Net8 Administrator's Guide to configure a connect descriptor Chapter 7 "Configuring the Listener," in the Net8 Administrator's Guide to configure static service information

Clients that Use Connect Descriptor with SID

Administrators that have clients that use the SID parameter in their connect descriptors can connect to the secondary instance by:

1. Configuring an additional administrative listener in the listener.ora file.

2. Specifying the appropriate SID in the CONNECT_DATA portion of the connect descriptor.

Both instances should be configured with two listeners:

• One listener, typically with a default name of listener, is used for client connections.

  This listener should not contain a SID_LIST_listener_name entry in the listener.ora file. This listener relies solely on dynamic service registration to obtain information about the database.

• A second administrative listener, with a different name, is used for remote administration.

  Only clients performing remote administration use this listener. This listener does not rely on service registration for database registration information. Instead, it relies on the SID_LIST_listener_name entry in the listener.ora file.

The installation and configuration process should have already created listener.ora files on both nodes with the SID_LIST_listener_name information.

To create the administrative listener:

1. Create another listener with a distinctive name, such as listener_admin.

2. Give it a port number that is not 1521, the default port number.

3. Replace listener_name in SID_LIST_listener_name in the listener.ora file with the name of the administrative listener.

   For example, the following listener.ora file has an entry for an administrative listener called listener_admin that listens on port 1480 for requests to an instance named op1 that services database op.us.acme.com:

   Old listener.ora File	Modified listener.ora File
   listener= (description= (address= (protocol=tcp) (host=idops1) (port=1521))) sid_list_listener= (sid_desc= (oracle_home=/orahome81) (sid_name=op1))	listener= (description= (address= (protocol=tcp) (host=idops1) (port=1521))) listener_admin= (description= (address= (protocol=tcp) (host=idops1) (port=1480))) sid_list_listener_admin= (sid_desc= (global_dbname=op.us.acme.com) (oracle_home=/orahome81) (sid_name=op1))

   The listener.ora file on the other node would also be modified in the following manner:

   Old listener.ora File	Modified listener.ora File
   listener= (description= (address= (protocol=tcp) (host=idops2) (port=1521))) sid_list_listener= (sid_desc= (global_dbname=op.us.acme.com) (oracle_home=/orahome81) (sid_name=op2))	listener= (description= (address= (protocol=tcp) (host=idops2) (port=1521))) listener_admin= (description= (address= (protocol=tcp) (host=idops2) (port=1480))) sid_list_listener_admin= (sid_desc= (global_dbname=op.us.acme.com) (oracle_home=/orahome81) (sid_name=op2))

   See Also: Chapter 7, "Configuring the Listener," in the Net8 Administrator's Guide for listener configuration instructions

4. For those clients that are to perform remote administration, create a separate connect descriptor for each of the administrative listeners.

   For example:

   op1_admin1= 
    (description= 
      (address=(protocol=tcp)(host=idops1)(port=1480))
     (connect_data=
        (sid=op1)))
   op2_admin2= 
    (description= 
      (address=(protocol=tcp)(host=idops2)(port=1480))
     (connect_data=
        (sid=op2)))
   

   See Also: See Chapter 6, "Configuring Naming Methods," in the Net8 Administrator's Guide to configure a connect descriptor.