Release 1 (9.0.1)
Part Number A90154-01
 Home |
 Book List |
 Contents |
 Index |  Master Index |  Feedback |
| Oracle9i Net Services Administrator's Guide Release 1 (9.0.1) Part Number A90154-01 |
|
This chapter describes how to configure advanced features of Oracle Net Services, including advanced connect data parameters, load balancing, failover, and connections to non-database services.
This chapter contains these topics:
This section contains the following advanced connect descriptor topics:
A database service may be accessed by more than one network route, or protocol address. In the following example, sales.us.acme.com can connect to sales.us.acme.com using listeners on either sales1-server or sales2-server.
sales.us.acme.com= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)))
To add a network protocol address to an existing net service name or database service:
The right pane displays the current destination service and address list.
A new Address tab appears:
When a database service is accessible by multiple listener protocol addresses, specify the order in which the addresses are to be used. The addresses can be chosen randomly or tried sequentially.
When multiple protocol addresses have been configured for a net service name or database service, you can configure the parameters described in Table 15-1.
Table 15-1 Address List Parameters
| Parameter | Description |
|---|---|
|
|
When set to See Also: "Configuring Clients for Oracle Connection Manager" on page 13-6 |
|
|
At connect time, instructs Oracle Net to fail over to a different listener if the first listener fails when set to
Connect-time failover is turned
Important: Oracle Corporation recommends not setting the |
|
|
When set to
Client load balancing is turned |
Implementation of these parameter depends on the naming method used. Table 15-2 describes the tools to configure connect-time failover or client load balancing. Source routing involves other configuration that goes beyond the scope of this section.
|
See Also:
"Configuring Clients for Oracle Connection Manager" for more information about configuring clients for source routing |
| Naming Method | Tool to Configure Address List Options |
|---|---|
|
Local Naming |
Net service names stored in a See Also: The procedure that follows |
|
Directory Naming |
Net service names and database services stored in a directory can be configured for connect-time failover and client load balancing using Oracle Net Manager. See Also: The procedure that follows |
|
Oracle Names |
Net service names stored in an Oracle Names server can be configured for connect-time failover and client load balancing using the following tools: See Also: "Task 7: Register Data with the Oracle Names Server" |
To configure connect-time failover or client load balancing:
The right pane displays the current destination service and address list.
The Address List Options dialog box appears:
Table 15-3 describes the Address List Options dialog box options.
Table 15-3 Address List Options Dialog Box
The following example shows a tnsnames.ora file configured for client load balancing:
sales.us.acme.com= (DESCRIPTION= (ADDRESS_LIST= (LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)))
The following example shows a tnsnames.ora file configured for connect-time failover:
sales.us.acme.com= (DESCRIPTION= (ADDRESS_LIST= (LOAD_BALANCE=off) (FAILOVER=ON) (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=sales.us.acme.com)))
The CONNECT_DATA section of a connect descriptor defines the destination database service. In the following example, SERVICE_NAME defines a service called sales.us.acme.com:
sales.us.acme.com= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)))
Besides the service name, connect data information can be optionally configured with the parameters described in Table 15-4.
Table 15-4 Advanced Connect Data Settings
| Oracle Net Manager Field/Option | tnsnames.ora File Parameter | Description |
|---|---|---|
|
Instance Name |
|
Use to identify the database instance to access.
The instance name can be obtained from the Note: This parameter is not enabled if "Use Oracle8i Release 8.0 Compatible Identification" is checked. See Also: "About Connect Descriptors" |
|
Session Data Unit Size |
|
To optimize the transfer rate of data packets being sent across the network, you can specify the session data unit (SDU) size to change the performance characteristics having to do with the packets sent across the network. See Also: "Configuring Session Data Unit" |
|
Use for Heterogeneous Services |
|
If you want an Oracle server to access a non-Oracle system through Heterogeneous Services, turn this option on. See Also: "Configuring Oracle Net for Oracle Heterogeneous Services" |
|
Oracle Rdb Settings |
|
|
|
Oracle RDB Database |
|
Specify the file name of the Oracle RDB database. See Also: "Configuring Oracle Net for an Oracle Rdb Database" |
|
Type of Service |
|
Specify the type of service to use for the Oracle RDB database. See Also: "Configuring Oracle Net for an Oracle Rdb Database" |
|
Global Database Name |
|
Use to identify an Oracle Rdb database. See Also: "Configuring Oracle Net for an Oracle Rdb Database" |
Implementation of these parameter depends on the naming method used. Table 15-5 describes the tools to configure connect-time failover or client load balancing. Source routing involves other configuration that goes beyond the scope of this section.
|
See Also:
"Configuring Clients for Oracle Connection Manager" for more information about configuring clients for source routing |
| Naming Method | Tool to Configure Multiple Address Options |
|---|---|
|
Local Naming |
Net service names stored in a See Also: The procedure that follows |
|
Directory Naming |
Net service names and database services stored in a directory can be configured with advanced connect data information using Oracle Net Manager. See Also: The procedure that follows |
|
Oracle Names |
Net service names and database services stored in an Oracle Names server can be configured with advanced connect data information using the following tools: See Also: "Task 7: Register Data with the Oracle Names Server" |
To configure advanced CONNECT_DATA parameters for either a net service name or a database service:
The right pane displays the current destination service and address list.
The Advanced Service Options dialog box appears:
Connection load balancing improves connection performance by balancing the number of active connections among multiple dispatchers. In an Oracle9i Real Application Clusters environment, connection load balancing also has the capability to balance the number of active connections among multiple instances.
Because the PMON process can register with remote listeners, a listener can always be aware of all instances and dispatchers, regardless of their location. Depending on the load information, a listener decides which instance and, if shared server is configured, which dispatcher to send the incoming client request to.
In a shared server configuration, a listener selects a dispatcher in the following order: 1) least loaded node, 2) least loaded instance, and 3) least loaded dispatcher for that instance. In a dedicated server configuration, a listener selects an instance in the following order: 1) least loaded node, and 2) least loaded instance.
If a database service has multiple instances on multiple nodes, the listener chooses the least loaded instance on the least loaded node. If shared server is configured, then the least loaded dispatcher of the selected instance is chosen.
To enable connection load balancing, the initialization parameter file must contain the following parameters:
SERVICE_NAMES for the database service name
INSTANCE_NAME for instance name
DISPATCHERS to enable shared server configuration and specify the dispatchers used by the instance
An Oracle9i Real Application Clusters environment requires that the dispatchers on each instance be cross registered with the other listeners on the other nodes. This is achieved by the use of the LISTENER attribute of the DISPATCHERS parameter.
|
See Also:
|
Figure 15-1 shows an Oracle9i Real Application Clusters shared server database with two instances, sales1 and sales2, of the same service, sales.us.acme.com. The instances sales1 and sales2 reside on computers sales1-server and sales2-server, respectively. sales1 has one dispatcher and sales2 has two dispatchers. Listeners named listener run on nodes 1 and 2, respectively. The listener attribute in the DISPATCHERS parameter has been configured to allow for service registration of information to both listeners.
The listeners_sales value in (LISTENER=listeners_sales) can be then resolved through a local tnsnames.ora file on the both servers as follows:
listeners_sales= (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521))(ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521)))
Based on the environment, the following actions occur. The numbered actions correspond to the arrows shown in Figure 15-2:
sales1 and sales2 register with both listeners. The listeners are updated on the load of the instances and dispatchers dynamically. The following load information is registered:
| sales1-server | sales2-server | |
|---|---|---|
|
1 Minute Node Load Average |
600 |
400 |
| sales1 | sales2 | |
|---|---|---|
|
Number of Connections to Instance |
200 |
300 |
| dispatcher1 | dispatcher2 | dispatcher 3 | |
|---|---|---|---|
|
Number of Connections to Dispatchers |
200 |
100 |
200 |
The load average on sales2-server (400) is less than the load average on sales1-server (600). This can happen if more processing is required on sales1-server. The number of connections to sales1 (200) is the same as that of its only dispatcher, dispatcher1. The number of connections on sales2 (300) is the sum of the connections on its two dispatchers, dispatcher2 (100) and dispatcher 3 (200). Therefore, sales2 has more connections than sales1. In this example, sales2-server is the least loaded node, sales2 is the least loaded instance, and dispatcher2 is the least loaded dispatcher.
A connect descriptor is configured to try each protocol address randomly until one succeeds:
sales.us.acme.com= (DESCRIPTION= (LOAD_BALANCE=on) (FAILOVER=on) (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=sales.us.acme.com)))
The listener on sales1-server was randomly chosen to receive the client connect request.
The listener on sales1-server compares the load of the instances sales1 and sales2. The comparison takes into account the load on nodes sales1-server and sales2-server, respectively. Since sales2-server is less loaded than sales1-server, the listener chooses sales2-server over sales1-server.
dispatcher2 and dispatcher3. Because dispatcher2 is less loaded than dispatcher3, the listener redirects the client connect request to dispatcher2.
dispatcher2.
Figure 15-3 shows an Oracle9i Real Application Clusters dedicated server database with two instances, sales1 and sales2, of the same service, sales.us.acme.com. The instances sales1 and sales2 reside on computers sales1-server and sales2-server, respectively. Listeners named listener run on nodes 1 and 2, respectively. The REMOTE_LISTENER parameter has been configured to allow for service registration of information to both listeners.
The listener_sales2 value in (REMOTE_LISTENER=listener_sales2) can be then resolved through a local tnsnames.ora file on the sales1-server as follows:
listener_sales2=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521)))
The listener_sales1 value in (REMOTE_LISTENER=listener_sales1) can be then resolved through a local tnsnames.ora file on the sales2-server as follows:
listener_sales1=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)))
Based on the environment, the following actions occur. The numbered actions correspond to the arrows shown in Figure 15-4:
sales1 and sales2 register with both listeners. The listeners are updated on the load of the instances dynamically. The following load information is registered:
| sales1-server | sales2-server | |
|---|---|---|
|
1 Minute Node Load Average |
450 |
200 |
| sales1 | sales2 | |
|---|---|---|
|
Number of Connections to Instance |
200 |
150 |
In this example, sales2-server is the least loaded node and sales2 is the least loaded instance.
A connect descriptor is configured to try each protocol address randomly until one succeeds:
sales.us.acme.com= (DESCRIPTION= (LOAD_BALANCE=on) (FAILOVER=on) (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=sales.us.acme.com)))
The listener on sales1-server was randomly chosen to receive the client connect request.
The listener on sales1-server compares the load of the instances sales1 and sales2. The comparison takes into account the load on nodes sales1-server and sales2-server, respectively. Since sales2-server is less loaded than sales1-server, the listener chooses sales2-server over sales1-server.
sales1-server redirects the client connect request to dispatcher2.
sale2-server. The listener starts a dedicated server process, and the dedicated server process inherits the connection request from the listener.
TAF instructs Oracle Net to fail over a failed connection to a different listener. 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 section of the connect descriptor.
This sections covers the following topics:
TAF automatically restores some or all of the following elements associated with active database connections. Other elements, however, may need to be embedded in the application code to enable TAF to recover the connection.
TAF automatically reestablishes the connection using the same connect string or an alternate connect string that you specify when configuring failover.
TAF automatically logs a user in with the same user ID as was used prior to failure. If multiple users were using the connection, then TAF automatically logs them in as they attempt to process database commands. Unfortunately, TAF cannot automatically restore other session properties. These properties can, however, be restored by invoking a callback function.
If a command was completely executed upon connection failure, and it changed the state of the database, TAF does not resend the command. If TAF reconnects in response to a command that may have changed the database, TAF issues an error message to the application.
TAF allows applications that began fetching rows from a cursor before failover to continue fetching rows after failover. This is called "select" failover. It is accomplished by re-executing a SELECT statement using the same snapshot, discarding those rows already fetched and retrieving those rows that were not fetched initially. TAF verifies that the discarded rows are those that were returned initially, or it returns an error message
Any active transactions are rolled back at the time of failure because TAF cannot preserve active transactions after failover. The application instead receives an error message until a ROLLBACK is submitted.
Serverside program variables, such as PL/SQL package states, are lost during failures; TAF cannot recover them. They can be initialized by making a call from the failover callback.
TAF works with the following database configurations to effectively mask a database failure:
The FAILOVER_MODE parameter must be included in the CONNECT_DATA section of a connect descriptor. FAILOVER_MODE can contain the sub-parameters described in Table 15-6.
Depending on the FAILOVER_MODE parameters, you can implement TAF in a number of ways. Oracle recommends the following methods:
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 protocol addresses on sales1-server or sales2-server. If the instance fails after the connection, the TAF application fails over to the other node's listener, reserving any SELECT statements in progress.
sales.us.acme.com= (DESCRIPTION= (LOAD_BALANCE=on) (FAILOVER=on) (ADDRESS= (PROTOCOL=tcp) (HOST=sales1-server) (PORT=1521)) (ADDRESS= (PROTOCOL=tcp) (HOST=sales2-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.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, Oracle Net tries to reconnect to the listener on sales1-server. If the failover connection fails, Oracle Net waits 15 seconds before trying to reconnect again. Oracle Net attempts to reconnect up to 20 times.
sales.us.acme.com= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales1-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.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, clients that use net service name sales1.us.acme.com to connect to the listener on sales1-server are also preconnected to sales2-server. If sales1-server fails after the connection, Oracle Net fails over to sales2-server, preserving any SELECT statements in progress. Likewise, Oracle Net preconnects to sales1-server for those clients that use sales2.us.acme.com to connect to the listener on sales2-server.
sales1.us.acme.com= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales1-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_NAME=sales1) (FAILOVER_MODE= (BACKUP=sales2.us.acme.com) (TYPE=select) (METHOD=preconnect)))) sales2.us.acme.com= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales2-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_NAME=sales2) (FAILOVER_MODE= (BACKUP=sales1.us.acme.com) (TYPE=select) (METHOD=preconnect))))
You can query FAILOVER_TYPE, FAILOVER_METHOD, and FAILED_OVER columns in the V$SESSION view to verify that TAF is correctly configured.
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(*) -------------------- ------------- ---------- --- ---------- sales1 NONE NONE NO 11 sales2 SELECT PRECONNECT NO 1
The output after failover is:
MACHINE FAILOVER_TYPE FAILOVER_M FAI COUNT(*) -------------------- ------------- ---------- --- ---------- sales2 NONE NONE NO 10 sales2 SELECT PRECONNECT YES 1
|
See Also:
|
The INSTANCE_ROLE parameter is an optional parameter for the CONNECT_DATA section of a connect descriptor. It enables you to specify a connection to the primary or secondary instance of Oracle9i Real Application Clusters and Oracle9i Real Application Clusters Guard configurations.
This parameter is useful when:
INSTANCE_ROLE supports the following values:
primary -- Specifies a connection to the primary instance
secondary -- Specifies a connection to the secondary instance
any -- Specifies a connection to whichever instance has the lowest load, regardless of primary or secondary instance role
In the following example, net service name sales_primary enables connections to the primary instance, and net service name sales_secondary enables connections to the secondary instance.
sales_primary= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales1-server) (PORT=1521)) (ADDRESS= (PROTOCOL=tcp) (HOST=sales2-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=primary))) sales_secondary= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales1-server) (PORT=1521)) (ADDRESS= (PROTOCOL=tcp) (HOST=sales2-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=secondary)))
There are times when Oracle Enterprise Manager and other system management products need to connect to a specific instance regardless of its role to perform administrative tasks. For these types of connections, configure (INSTANCE_NAME=instance_name) and (INSTANCE_ROLE=any) to connect to the instance regardless of its role.
In the following example, net service name sales1 enables connections to the instance on sales1-server and sales2 enables connections to the instance on sales2-server. (SERVER=dedicated) is specified to force a dedicated server connection.
sales1= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales1-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=any) (INSTANCE_NAME=sales2) (SERVER=dedicated))) sales2= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales2-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=any) (INSTANCE_NAME=sales2) (SERVER=dedicated)))
If Transparent Application Failover (TAF) is configured, a backup connection can be pre-established to the secondary instance. The initial and backup connections must be explicitly specified. In the following example, Oracle Net connects to the listener on sales1-server and preconnects to sales2-server, the secondary instance. If sales1-server fails after the connection, the TAF application fails over to sales2-server, the secondary instance, preserving any SELECT statements in progress.
sales1.acme.com= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales1-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=primary) (FAILOVER_MODE= (BACKUP=sales2.acme.com) (TYPE=select) (METHOD=preconnect)))) sales2.acme.com= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=sales2-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_ROLE=secondary)))
Before sending data across the network, Oracle Net buffers and encapsulates data into the SDU. Oracle Net sends the data stored in this buffer when the buffer is full, flushed, or when RDBMS tries to read data. When large amounts of data are being transmitted or when the message size is consistent, adjusting the size of the SDU buffers can improve performance, network utilization, or memory consumption.
The SDU size can range from 512 bytes to 32 KB. The default SDU for the client and the database is 2 KB.
Optimal SDU size depends on the maximum segment size (MSS) and message fragmentation. For TTC connections, configuring an SDU size larger than the 2 KB default requires configuring the SDU on both the client and server computers. When the configured values do not match, the lower of the two values will be used.
To minimize packet header overhead and message fragmentation, set the SDU size as a multiple of the MSS. When Oracle Advanced Security encryption is not used, increase the SDU size by one (1). For example, the TCP/IP version 4 MSS on Ethernet is 1460 bytes. Use a multiple of 1460 for the SDU size if encryption is used. If encryption is not used, increase the SDU size to 1461.
The packet header overhead and message fragmentation can be measured using a network sniffer or by analyzing Oracle Net trace files.
To configure the client, set the SDU size with the SDU parameter in a connect descriptor as follows:
net_service_name= (DESCRIPTION= (SDU=2920) (ADDRESS=...) (ADDRESS=...) (CONNECT_DATA= (SERVER_NAME=sales.us.acme.com)))
Database server configuration depends upon whether or not the database is configured to use shared server or dedicated server processes.
If using shared server processes, set the SDU size in the DISPATCHERS parameter as follows:
DISPATCHERS="(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp))(SDU=2920))"
Ensure that the SDU size matches the value configured for the client.
If using dedicated server processes for a database that is dynamically registered with the listener through service registration, then the SDU size cannot be set. Instead, the 2 KB default is used.
If using dedicated server processes for a database that is registered with the listener through static configuration in the listener.ora file, then set the SDU size in the SID_DESC section of the listener.ora file as follows:
SID_LIST_listener_name= (SID_LIST= (SID_DESC= (SDU=2920) (SID_NAME=sales)))
Ensure that the SDU size matches the value configured for the client.
In the release, Oracle Net provides support for the Virtual Interface (VI) protocol. The VI protocol is a standard communication protocol for clustered server environments. VI is an interface between a cluster Local Area Network (cLAN) Host Adapter, a type of network interface card, and the application. By using VI, applications place most of the messaging burden upon the host adapter, freeing the CPU for other tasks. As a result, VI is able to decrease network latency and CPU utilization.
VI is designed specifically for System Area Networks (SANs). A SAN is characterized by short-distance, high-performance communications between multiple server systems, such as application Web servers and database servers clustered into one switch.
This sections describes how to set up Oracle Net support of VI for application Web server and database server communication. It includes the following topics:
Prior to configuring support for the VI protocol, install the required hardware:
VI hardware can be installed before or after an Oracle9i Server or Oracle9i Client installation that includes VI protocol support. If the hardware is installed after an Oracle installation, perform these steps:
A VI protocol address uses the parameters described in Table 15-7.
Table 15-7 VI Protocol Settings in listener.ora
To configure a protocol address for VI:
listener.ora file on the database server:
A new Address tab appears.
The listener.ora file updates with a VI protocol address. The following example shows a VI endpoint that uses discriminator number 1521 on the computer sales-server.
listener= (DESCRIPTION= (ADDRESS=(PROTOCOL=vi)(HOST=sales-server)(DISC=1521)))
listener.ora file.
The following example shows a net service name of sales that contains the same address information configured in the example output in Step 1.
sales= (DESCRIPTION= (ADDRESS=(PROTOCOL=vi)(HOST=sales-server)(DISC=1521))) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)))
|
See Also:
Chapter 9, "Configuring Naming Methods" for more information about creating connect descriptors |
If you find that the performance between the application Web server and database server is not optimal, you can configure the number of buffers to use or use Oracle Connection Manager to reduce the demand on system resources. This section contains these topics:
The number of buffers is set in the sqlnet.ora file on the application Web server and database server with the VI_RECEIVE_BUFFERS and VI_SEND_BUFFERS parameters. The VI_RECEIVE_BUFFERS parameter specifies the number of buffers that have been posted on the receive queue for a VI endpoint, and the VI_SEND_BUFFERS parameter specifies the number of buffers that have been posted on the send queue for a VI endpoint. By default, these buffers are set to 15. The size of each buffer is the SDU size. The SDU has a default size of 2 KB.
In the following example, each connection will allocate 10 buffers for receiving data and five for sending data and lock the corresponding memory:
VI_RECEIVE_BUFFERS=10 VI_SEND_BUFFERS=5
The number of buffers you configure affect the memory needed for the database server and application Web servers. The more buffers configured, the more memory required.
To calculate the memory requirements for the database server, use the following formula:
(number_connections * number_app_servers) * SDU_size * (VI_RECEIVE_BUFFERS + VI_SEND_BUFFERS)
where:
To calculate the memory requirements for an application Web server, use the following formula:
number_connections * SDU_size * (VI_RECEIVE_BUFFERS + VI_SEND_BUFFERS)
Use the VI_RECEIVE_BUFFERS and VI_SEND_BUFFERS parameters from the sqlnet.ora file on the application Web server.
To keep the number of connections up to an optimal level without burdening system resources, use Oracle Connection Manager's session multiplexing feature to enable the database server to use fewer connection endpoints for incoming requests.
Figure 15-5 shows how Oracle Connection Manager is used to offload some of the network I/O of the application Web servers.
|
See Also:
"Enabling Session Multiplexing" for more information about configuring session multiplexing |
The following topics describe how to configure connections to non-Oracle database services:
External procedures are functions or procedures written in a third-generation language (3GL) that can be called from PL/SQL code. You can configure the listener to listen for external procedure calls. When a PL/SQL or SQL application calls an external procedure, the listener starts an external procedure agent, which by default is named extproc. Using the network connection established by the listener, the application passes the following information to the agent:
The agent then loads the shared library and invokes the external procedure.
The agent can reside on the same computer as the database server or on a remote computer with a listener.
By default, Oracle Net Configuration Assistant configures connections to external procedure during database server installation. For environments where the connection information does not exist, use the following steps to modify the listener.ora file and tnsnames.ora files, located in $ORACLE_HOME/network/admin on UNIX operating systems and ORACLE_HOME\network\admin on Windows:
listener.ora file. If the external procedure agent resides on a remote computer, configure a TCP/IP protocol address in the listener.ora file. The following procedure describes creating an IPC address for the default external procedure agent extproc:
A new Address tab appears.
KEY. Oracle Corporation recommends a KEY value of extproc.
"Configuring Listening Protocol Addresses" for more information about configuring listener protocol addresses
See Also:
extproc in the listener.ora file, including the parameters described in Table 15-8.
Table 15-8 External Procedures Settings in listener.ora
To configure the SID_NAME, ORACLE_HOME, and PROGRAM parameters:
A new Service tab appears.
extproc in the Program Name field, a system identifier such as plsextproc in the SID field, and the Oracle home where the extproc executable resides in the Oracle Home field.
If the application requires that an environment variable be set before the agent is started, enter it the Environment field. For example, if the application requires environment variables MYAPPDIR for the binary location and APPID for the ID, you would enter the following in the Environment field:
'MYAPPDIR=/myappdir/bin','APPID=MYAPP'
|
See Also:
Oracle9i Net Services Reference Guide for further about setting environment variables with |
The listener.ora file updates with external procedures, as shown in the following output:
LISTENER= (DESCRIPTION= (ADDRESS= (PROTOCOL=ipc)(KEY=extproc))) SID_LIST_LISTENER= (SID_LIST= (SID_DESC= (SID_NAME=plsextproc) (ORACLE_HOME=/u1/app/oracle/9.0) (PROGRAM=extproc)))
tnsnames.ora file whose connect descriptor matches the information configured in the listener.ora file.
Based on the listener.ora file shown in Step 2, the tnsnames.ora file would be configured with the following entry:
EXTPROC_CONNECTION_DATA= (DESCRIPTION= (ADDRESS=(PROTOCOL=ipc)(KEY=extproc)) (CONNECT_DATA= (SID=plsextproc)))
|
See Also:
"Configuring the Local Naming Method" for more information about creating a net service name |
Heterogeneous Services are an integrated component within the Oracle database server, and provides the generic technology for accessing non-Oracle systems from the Oracle database server. Heterogeneous Services enable you to:
While Heterogeneous Services provides the generic technology in the Oracle database server, a Heterogeneous Service agent is required to access a particular non-Oracle system.
To initiate a connection to the non-Oracle system, the Oracle database server starts an agent process through the listener on the gateway. For the Oracle database server to be able to connect to the agent, perform the following steps:
listener.ora file.
Table 15-9 Heterogeneous Services Settings in listener.ora
To configure the SID, ORACLE_HOME, and PROGRAM parameters:
A new Service tab appears.
The listener.ora file updates information about the Heterogeneous Services, as shown in the following:
SID_LIST_LISTENER= (SID_LIST= (SID_DESC= (SID_NAME=salesdb) (ORACLE_HOME=/home/oracle/megabase/9.0) (PROGRAM=tg4mb80)))
HS=ok clause to make sure the connection uses Heterogeneous Services:
The Advanced Service Options dialog box appears.
The tnsnames.ora file updates with the new net service name configured for Heterogeneous Services, as shown in the following:
megabase6_sales= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=dlsun206)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales6) (HS=ok)))
Oracle Rdb is a database for Digital's 64-bit operating systems. Because Oracle Rdb has its own listener, the client interacts with Rdb in the same manner as it does with an Oracle database.
To initiate a connection to an Oracle Rdb, set up a net service name to connect to the Oracle Rdb database using the parameters described in Table 15-10.
Table 15-10 Oracle RDB Database Settings in a Connect Descriptor
To configure a client for an Oracle Rdb database, use Oracle Net Manager:
The Advanced Service Options dialog box appears.
The tnsnames.ora file updates with the new net service name configured for the Oracle Rdb database, as shown in the following:
alpha5= (DESCRIPTION= (ADDRESS=...) (CONNECT_DATA= (SERVICE_NAME=generic) (RBD_DATABASE=[.mf]mf_personnel.rdb) (GLOBAL_NAME=alpha5)))
In the following example, TYPE_OF_SERVICE is used to load balance between an Oracle Rdb database service an Oracle database service:
alpha5= (DESCRIPTION_LIST= (DESCRIPTION= (ADDRESS=...) (CONNECT_DATA= (SERVICE_NAME=generic) (RBD_DATABASE=[.mf]mf_personnel.rdb) (GLOBAL_NAME=alpha5))) (DESCRIPTION= (ADDRESS=...) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)) (TYPE_OF_SERVICE=oracle9_database))
|
 Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|