Oracle Net8 Administrator's Guide
Release 8.0

A58230-01

Library

Product

Contents

Index

Prev Next

4
Configuring Network Services

Net8 provides services that establish basic connectivity and enhance the manageability and scalability of your network.This chapter outlines procedures for configuring these services.

This chapter includes the following sections:

4.1 Zero Listener Configuration

Before Oracle8 and Oracle7 servers can receive connections from Net8 clients, you must first start a network listener on the server node.

Start a listener and it will listen on a specific default address (Port 1521, TCP/IP, and interprocess communication addresses with KEY=PNPKEY). In a simple TCP/IP network not using Oracle Names, no further configuration is required.

4.2 Configuring the Network Listener

If however, you are using Oracle Names, or wish the listener to handle requests on other listening addresses, you will need to change and specify these preferences in a listener configuration file (called LISTENER.ORA).

The listener configuration file is composed of the following parts:

4.2.1 Naming the Listener

The listener can be given any name. Enter any alphanumeric string to identify the name of the listener in the first line of the listener configuration file, for example:

MYLISTENER =

If no name is specified in the listener configuration file, the listener will be named LISTENER by default. If you use the default listener name, you will not need to specify the listener name within the startup command.

4.2.2 Configuring Listening Addresses

To instruct the listener to listen for connection requests on a specific address, you will need to configure the address protocol and any protocol specific parameters in an ADDRESS parameter similar to the one that follows in your listener configuration file:

(ADDRESS=(PROTOCOL=protocol name)(protocol specific information))

For more information about protocol specific parameters, refer to the Oracle operating system-specific documentation for your platform.

4.2.2.1 Defining Multiple Listening Addresses

Listeners may also be configured to listen on more than one address. To do this, you will need to specify an ADDRESS LIST in your listener configuration file. For example if a host machine is running both TCP/IP and SPX/IPX, the listener may be configured as follows:

listener=

(address list=

(address=(protocol=tcp)(host=sunshine)(port=1521))
(address=(protocol=spx)(service=orasrvc1))
)

4.2.2.2 Interprocess Communication (IPC) Listening Addresses

Interprocess communication (IPC) addresses identify both incoming connection requests from applications on the same node as the listener, and information sent or registered by a database dispatcher. To define IPC addresses, specify IPC as the protocol as well as any KEY values you are using in your listener configuration file:

(ADDRESS=(PROTOCOL=IPC)(KEY=string))

If identifying connection requests from the same node, the key value is equal to the service name of the database. If identifying a database dispatcher, the key value is equal to the database system identifier (SID). If the service name is the same as the SID, only one IPC address is needed.

4.2.2.3 Configuring the Listener to Handle Larger Volumes of Connection Requests

If you expect the listener to handle large volumes of connection requests, you may specify a queue for the process. This will allow the listener to dynamically handle larger numbers of concurrent connection requests.

To specify a queue size for a listener, enter a value to the QUEUESIZE keyword at the end of any listening address in your listener configuration file.

Example 4-1 depicts a typical listener configuration file with the queue size specified.

Example 4-1 Listener Configuration File with Queue Size Specified

listener=

(address=

(protocol=tcp)(host=acme.com)(port=1521)(queuesize=20)
)


Note::

Currently, you can only configure the queue size for listeners operating on TCP/IP and DECnet. The queue size value is operating system specific. On TCP/IP, the default queue size is set to 17.

 

4.2.3 Configuring the Listener for Database Services

The network listener may handle requests for more than one service. To configure information about database instances that the listener is servicing, you will need to provide the following information in the listener configuration file:

4.2.3.1 Global Database Name

The global database name is the name and domain name of the database as given in the database initialization parameter file. If you want to refer to the database by its global database name on the network, then you must specify that global database name to the listener.

4.2.3.2 Oracle Home Directory

The Oracle Home Directory identifies the Oracle Home location of the database that you are specifying. Its value is operating system specific. Table 4-1 lists examples of some operating system-specific strings:

Table 4-1 Operating System Specific Strings
Operating System   String  

UNIX  

(ORACLE_HOME=/usr/oracle)
 

VMS  

(PROGRAM='disk$:[oracle.rdbms]tnslsnr.com')
 

OS/2  

(PROGRAM=ORACLE8)
 

4.2.3.3 System Identifier (SID)

The system identifier or SID is the Oracle system ID for the database server.

4.2.3.4 Configuring Prestarted or Prespawned Dedicated Server Processes

To create prespawned dedicated server processes, add the following four keywords in each SID_DESC in your listener configuration file:

Example 4-2 depicts a typical SID_DESC in a listener configuration file that includes information about prespawned dedicated server processes:

Example 4-2 Typical SID_DESC in Listener Configuration File

sid_list_listener=(sid_list =
(sid_desc =

(global_dbname = sales.acme.com)
(sid_name = db1)
(oracle_home = /usr/bin/oracle)
(prespawn_max = 99)
(prespawn_list=

(prespawn_desc=
(protocol=tcp)(pool_size=10)(timeout = 2)
)
)
)
)
4.2.3.4.1 PRESPAWN_MAX

The maximum number of prespawned dedicated server processes the listener will create. This number must be at least as many as the sum of the pool size for each protocol. Set this value to a large number so that prespawned dedicated server processes are always available for new connections.

4.2.3.4.2 PROTOCOL

The protocol on which the listener creates prespawned dedicated server processes.

4.2.3.4.3 POOL_SIZE

The number of unused prespawned dedicated server processes for the listener to maintain on the selected protocol. Choose a number that is greater than 0 but no greater than the PRESPAWN_MAXIMUM value. The value should be about what you expect the average number of connections to be at any given time.

4.2.3.4.4 TIME_OUT

Time in minutes that an inactive prespawned dedicated server process waits for the next connection. The value should be greater than 0. (A value of 0 will allow an inactive shadow process to continue indefinitely, thus wasting machine resources.) Set a short time out value. The time out is activated only after a prespawned dedicated server process has carried a connection and been disconnected. In other words, prespawned dedicated server processes that are waiting for their first connection do not time out.

4.2.4 Registering Information with a Names Server

If you are using Oracle Names, you can configure each listener to forward information about the database it is servicing to a Names Server by setting the USE_PLUG_AND_PLAY parameter to ON in your listener configuration file. For more information about the USE_PLUG_AND_PLAY_listener_name parameter, refer to "Listener Parameters (LISTENER.ORA)" section in Appendix B, "Configuration Parameters".

4.2.5 Configuring Other Listener Features

For a complete list of parameters enabling you to configure additional network listener features including logging and tracing, refer to "Listener Parameters (LISTENER.ORA)" in Appendix B, "Configuration Parameters". For a sample LISTENER.ORA file, refer to "Listener Configuration File (LISTENER.ORA)" in Appendix C, "Sample Configuration Files".

4.3 Configuring Protocol Specific Parameters

The following protocols require you to configure additional parameters in a protocol specific configuration file. This file is called PROTOCOL.ORA:

Protocols that require address information in your protocol specific configuration file have LOCAL_LOOKUP=alias as one of their address parameters in your local naming configuration file, or your listener configuration file. The LOCAL_LOOKUP parameter points to a non-global address in a PROTOCOL.ORA file.

The global address information for the server HORNET.WORLD is contained in the local naming and listener configuration files. This information can be used by any client in the network. The PROTOCOL.ORA entry contains additional address parameters needed for a specific node to reach HORNET.WORLD.

4.3.1 Configuring Validnode Checking

Validnode checking restricts a client's connection access to destinations with specific host privileges. The access list is defined in the your protocol-specific configuration file. To enable validnode checking, add the following parameter in your protocol-specific configuration file:

protocol.validnode_checking = yes

Not all protocols and operating systems support validnode checking. For more information, refer to Oracle operating system-specific documentation for your platform.

4.3.2 Configuring Persistent Buffer Flushing

To configure persistent buffer flushing, add the following parameter in your PROTOCOL.ORA file:

tcp.nodelay = yes

4.3.3 Configuring Dead Connection Detection

Net8 sends a probe periodically to verify that a client-server connection is still active. This is done to ensure that connections are not left open indefinitely, due to an abnormal client termination. If the probe finds a dead connection, or a connection that is no longer in use, it returns an error, causing the server process to exit.

To configure dead connection detection, you will need to configure a TNS Time-Out Value in a profile. You can do this by editing your profile using the following parameter:

SQLNET.EXPIRE_TIME

For information on how to configure this parameter using the Oracle Net8 Assistant, refer to Section 5.2.5.1, "TNS Time-Out Value".

For more information on this parameter, refer to the table titled SQLNET.EXPIRE_TIME in Appendix B, "Configuration Parameters".

4.3.3.1 Limitations

Limitations on using the dead connection detection feature are as follows:

Some protocols may already include a native mechanism to perform the same functionality as dead connection detection. For more information, refer to Oracle operating system specific documentation for your platform.




Prev

Next
Oracle
Copyright © 1997 Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index