Oracle9i Real Application Clusters Setup and Configuration Release 2 (9.2) Part Number A96600-01 |
|
This chapter describes how to configure the high availability features of Real Application Clusters. The topics in this chapter are:
This section discusses the Real Application Clusters-specific aspects of transparent application failover (TAF). This section covers the following topics:
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 connection that has failed to a different instance. This enables the user to continue working by using the new connection as if the original connection had never failed.
To configure TAF, include FAILOVER_MODE
parameter settings in the CONNECT_DATA
portion of a connect descriptor. There are several sub-parameters you can use to specify FAILOVER_MODE
. For example, you can specify the type of failover and speed at which Oracle should process it, as well as the retry behavior Oracle should use.
See Also:
Oracle9i Net Services Administrator's Guide for detailed information about the sub-parameters you can use for |
Depending on the FAILOVER_MODE
parameters, you can implement TAF using any of the following methods:
You can implement TAF with connect-time failover and client load balancing for multiple addresses. In the following example, Oracle Net connects randomly to one of the listener addresses on node db1
or db2
. If the instance fails after the connection, 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))))
See Also:
Oracle9i Net Services Administrator's Guide for more information about and examples of load balancing |
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, it fails over 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))))
See Also:
Oracle9i Net Services Administrator's Guide for detailed information about |
A backup connection can be pre-established. The initial and backup connections must be explicitly specified. In the following example, Oracle Net connects to the listener on db1-server
. If db1-server
fails after the connection, 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.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.acme.com) (type=select) (method=preconnect)))) db2.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.acme.com) (type=select) (method=preconnect)) ))
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 NONE NONE NO 11 db2 SELECT PRECONNECT NO 1
The output after failover is:
MACHINE FAILOVER_TYPE FAILOVER_M FAI COUNT(*) -------------------- ------------- ---------- --- ---------- db2 NONE NONE NO 10 db2 SELECT PRECONNECT YES 1
See Also:
|
The Primary/Secondary Instances 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. This section describes the primary and secondary instance feature in more detail and contains the following topics:
An instance is the primary instance when ACTIVE_INSTANCE_COUNT=1
is set in the 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 you configure shared server 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 to which the dispatcher(s) register information. This is resolved 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. A secondary instance registers with its local listener as a secondary instance, and the secondary instance has its ACTIVE_INSTANCE_COUNT
set to 1
in the init
sid.ora
file.
If the primary instance fails, the secondary instance assumes the primary role and registers with its listeners. When the failed instance re-starts, it starts up as the secondary instance.
Clients connected to the failed primary instance are failed over to the secondary instance if you have configured TAF. Clients connecting to the Real Application Clusters database after the primary instance fails are automatically routed to the secondary instance.
See Also:
|
To enable primary and secondary instance configuration, configure the initialization parameter file by setting the ACTIVE_INSTANCE_COUNT
parameter to 1
on both instances.
Oracle Corporation recommends configuring a connect descriptor on clients that use an address list containing the listener addresses for the primary instance and the secondary instance. 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 a list of addresses, so it does not need to be explicitly specified. 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=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 tries the listener on the primary instance, which succeeds.
See Also:
|
Remove the static service information sid_LIST_listener_name
entry 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 listener.ora
file as shown in Table 9-1:
In some situations, you may wish to connect to the secondary instance even when the primary instance is active. For example, you may want to perform a batch operation on the database. To do this, use the INSTANCE_ROLE
parameter in the connect data portion of the connect descriptor to configure explicit secondary instance connections.
The optional INSTANCE_ROLE
parameter in the CONNECT_DATA
section of a connect descriptor enables you to specify connections to primary or secondary instances. This parameter is useful for explicitly connecting to primary or secondary instances and for using Transparent Application Failover (TAF) to pre-connect to secondary instances.
See Also:
Oracle9i Net Services Administrator's Guide for more detailed information and examples of |
Maintaining 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.
See Also:
Oracle9i Real Application Clusters Real Application Clusters Guard I - Concepts and Administration for more information about this feature and Oracle9i Supplied PL/SQL Packages and Types Reference for more information about using |
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 are able to support services. Instances are brought in automatically to support a service while they are also available to support other services.
A service in Real Application Clusters Guard II is a group of related business functions. The client selects a database service as part of the connection request where the middle-tier specifies the SERVICE_NAME
in the tnsnames.ora
file's connect data description for each server in the connection pool. The service has associated functions--for statistics aggregation, for performance and resource consumption, and for configuring, measuring, and comparing service thresholds and workload distributions based on service levels and priority.
The notion of 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.
See Also:
Oracle9i Real Application Clusters Guard II Concepts, Installation, and Administration on the Real Application Clusters Guard II software CD |
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. This randomization distributes the load to avoid overburdening a single listener.
There are two cases in which a client attempts to connect to another address:
SERVICE_NAME
, so the instance is down
The second case implies that the client only attempts to connect to the next listener if the first listener fails. The client also tries the next listener if the first listener is up, but does not know about 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, the connection request fails over to the next address. If an instance fails, the client can connect using another instance.
Warning: Do not set |
To control how the client executes these connection attempts, configure multiple listening addresses and use FAILOVER=ON
and LOAD_BALANCE=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)))
See Also:
|
To ensure the files are configured correctly:
CONNECT SYSTEM/
password@
net_service_name
Oracle displays a "Connected
" message.
If there is a connection error, troubleshoot your installation. Typically, this is a result of a problem with the IP address, host name, service name, or instance name.
UPDATE EMP
set sal = sal + 1000 where ename = 'miller';commit;
EMP
table again:
SELECT * FROM EMP;
Miller's salary should now be $2,300, indicating that all the instances can access the records in the database.
|
![]() Copyright © 1998, 2002 Oracle Corporation. All Rights Reserved. |
|