Oracle8i Parallel Server Setup and Configuration Guide Release 2 (8.1.6) Part Number A76934-01 |
|
This chapter describe how to configure Oracle Parallel Server high-availability features.
Specific topics discussed are:
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:
The FAILOVER_MODE parameter must be included in the CONNECT_DATA portion of a connect descriptor. FAILOVER_MODE may contain the following parameters:
Depending on the FAILOVER_MODE parameters, TAF can be implemented in a number of ways. Oracle recommends the following methods:
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))))
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))))
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)))
You can query FAILOVER_TYPE, FAILOVER_METHOD, and FAILED_OVER columns in the V$SESSION view to verify that TAF is correctly configured.
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:
An instance is the primary instance when ACTIVE_INSTANCE_COUNT=1 is set in the init
sid
.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:
|
To enable primary and secondary instance configuration, the instance initialization file, init
sid.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
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.
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:
Note: If you want to connect to a secondary instance do not remove the SID_LIST_listener_name entry. Instead, see the next section, "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.
Administrators can connect the secondary instance by logging into the machine and performing the batch operation.
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:
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:
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.
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 init
db_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
.
The listener.ora
file on the other node would also be modified in the following manner:
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)))
Administrators that have clients that use the SID parameter in their connect descriptors can connect to the secondary instance by:
listener.ora
file.
Both instances should be configured with two listeners:
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.
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:
listener_admin
.
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
:
The listener.ora
file on the other node would also be modified in the following manner:
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)))
|
![]() Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|