5 Configuring Oracle Net Services

5.1.1 Centralized Configuration

In a centralized configuration, Oracle Database and Oracle Database Client are located on the same system. This system is not necessarily on a network, and you can access the application through terminals. If you use a centralized configuration, then you can use a simple Oracle Net Services adapter called the Bequeath adapter, which requires no Oracle Net Services configuration. However, if you want to use Oracle Shared Servers, then you must configure Oracle Net Services even in centralized configurations.

5.1.2 Client/Server Configuration

In a client/server configuration, Oracle Database resides on a multitasking server system, and the client side of the applications resides on another computer, such as a workstation or personal computer. The client and server are connected by a physical network and communicate through a network protocol such as TCP/IP. In a client/server environment, the Oracle application built with an application development tool makes database requests to the server over the network.

5.1.3 Distributed Database Configuration

In a distributed database configuration, users query separate databases as a single database. The major advantage of a distributed database is that users and applications are not required to know where the data resides. You can query database tables by name, regardless of how the network protocols work together to access the required remote database containing the table. Therefore, Oracle Net Services users can communicate and share database information stored in different locations, on different computers, with different operating systems. Distributed databases enable local administration of data and can reduce network traffic if the data that is accessed most often at a location can be stored locally.

Oracle Net Services allows the client and the server to communicate over a variety of media and protocols. A client/server configuration allows DBAs to distribute CPU-intensive user interfaces to low-cost workstations. It also allows application users to be greeted with the graphical user interface (GUI) with which they are most familiar.

5.4.1 IPC-Mailbox Protocol

The Mailbox protocol adapter, or IPC adapter, is automatically configured for use when you install Oracle Net Services. It can be used for client/server connections when both client and server are on the same OpenVMS node. If the client and server are on different systems, then the connection must take place using TCP/IP.

When configuring the TNS listener to listen for mailbox connections, you need to specify a KEY value in the LISTENER.ORA file for the IPC protocol. The listener then creates a mailbox. This mailbox listens for connections and creates a system-wide logical name (the same as the KEY value) that translates to this mailbox device. It is through this logical name that clients find the mailbox of the listener.

The Oracle Shared Server must be configured to use only TCP/IP protocol. The IPC protocol cannot be used here.

Syntax

The following fields must be defined:

(PROTOCOL=IPC)
(KEY=IPC logical name)

where:

PROTOCOL is the keyword that identifies the specific protocol adapter used. For this protocol, the value is IPC. The value can be entered in either uppercase or lowercase, and

KEY is the logical name used to connect to the listener through the Mailbox adapter.

Example

This example shows the two fields for the OpenVMS Mailbox adapter.

(PROTOCOL=IPC)
(KEY=ORA_IPC)

5.4.2 TCP/IP Protocol

The TCP/IP protocol adapter provides support for client/server connections using TCP/IP as a protocol. You can turn Oracle Net Services support for TCP/IP on or off by using the options available on the NetConfig configuration screen.

Oracle Net Services on OpenVMS is developed and certified by using the Hewlett-Packard TCP/IP Services for OpenVMS, which is also known as UCX. If you want to use the TCP/IP protocol adapter for Oracle Net Services, then you should have version 5.5 - ECO 1, or later, TCP/IP Services for OpenVMS installed. TCP/IP protocol stacks from other vendors may work with Oracle, but customers use these products at their own risk. Any TCP/IP problems that cannot be reproduced by using TCP/IP Services for OpenVMS should be referred to the TCP/IP vendor.

Syntax

The following fields must be defined:

(PROTOCOL=TCP)
(HOST=hostname)
(PORT=port#)

The following field is optional:

(QUEUESIZE=n)

In the preceding syntax:

• PROTOCOL is the keyword that identifies the specific protocol adapter used.

  For this protocol, the value is TCP. The value can be entered in either uppercase or lowercase.

• HOST is the host name or IP address.

• PORT# is the TCP/IP port number.

• Queuesize is the parameter that increases the queue size. This parameter is optional. If it is not specified, then the default value is 20. If simultaneous connections are made to the listener, then some connection requests may not be received if the listener socket queue size is too small

Example 

In this example, the TCP/IP connect descriptor specifies a listener on the

(PROTOCOL=TCP)
(HOST=ALPHA1)
(PORT=1526)

5.4.3 BEQ-Bequeath Protocol

Each database that you want to connect with the Bequeath protocol adapter must have a command file named ORASRV_BEQ_sid.COM in ORA_ROOT:[NETWORK.ADMIN]. If you used Oracle Database Configuration Assistant to create the database, or if you upgraded the database, then this file is automatically created. However, if you manually created the database, or if you need to recreate this file for any reason, then you must create this command procedure manually by executing ORA_NETWORK:CREATE_ORASRV_BEQ.COM.

5.4.4 Bequeath Listener

On OpenVMS, the Bequeath listener is used as a default to provide dedicated server connections for a local client. The Bequeath listener, running as a detached process, creates detached server processes to service clients on the same system by using the Bequeath adapter. This allows Oracle Database to run in a suitably privileged process.

For each request from the client, the Bequeath listener creates a detached server process and two mailboxes. It then sends the mailbox names to the client, and the client establishes a connection to the server using these mailboxes.

By default, these mailboxes are created with a buffer quota of 8192 bytes and a maximum message size of 2048 bytes. You can change these parameters by defining logical names in the ORASRV_BEQ_SID.com file with other values. For example:

$ define ORA_BEQ_MBXSIZ n 
$ define ORA_BEQ_MBXBFQ n 

The maximum value for the mailbox buffer quotas is 60000 bytes. You should adjust these values carefully, and you should adjust them for performance reasons only.

The Bequeath listener uses a known mailbox name to listen for client requests. This mailbox name is in the format:

ORA_BEQ_READ_MBX_xxxxxxxxxx_n 

where:

xxxxxxxxxx is the Oracle install ID unique to the system (padded with zeroes).

n is a single-digit number (0-9) that is the Bequeath listener number.

This section contains the following topics:

• Section 5.4.4.1, "Starting Up the Bequeath Listener"

• Section 5.4.4.2, "Determining the Status of the Bequeath Listener"

• Section 5.4.4.3, "Shutting Down the Bequeath Listener"

• Section 5.4.4.4, "Problem Resolution"

• Section 5.4.4.5, "Bequeath Listener Privileges"

$ BEQLSNR START [n]

$ BEQLSNR STATUS [n]

$ BEQLSNR STOP [n]

$type ora_rootdir:install.id
SERVER_519462874
 
$show log *beq*
 
(LNM$PROCESS_TABLE)
(SERVER_519462874)
 
"ORA_BEQ" = "519462874"
 
(LNM$JOB_8221BDC0)
 
(LNM$GROUP_000610)
 
(LNM$SYSTEM_TABLE)
 
"ORA_BEQ_READ_MBX_519462874_0" = "MBA3737:"

$ BEQLSNR START n

5.5.1 LSNRCTL

The LSNRCTL utility is used to start and stop the TNS listener and to query its status or services. The LSNRCTL command runs the command procedure ORA_NETCONFIG:LSNRCTL.COM, which provides a shell to the executable program ORA_ROOT:[BIN]LSNRCTL.EXE.

The main function of the command procedure is to check that the privileges required to start the TNS listener are present. These privileges are covered in the following section. If a LSNRCTL START command is entered and the required privileges are not present, then an error message is displayed and LSNRCTL exits.

Do not start the listener from a process that has a User Identification Code (UIC) in the system group, for example, a group less than or equal to MAXSYSGROUP. If you enter a LSNRCTL START command from such a process, then an error message is displayed and LSNRCTL exits. If you enter a LSNRCTL command with no arguments, then you are warned not to start the listener from within the LSNRCTL utility. If the listener is running in a system group, then any server processes it creates will be in the system group. The server is shut down, because it does not let itself run in privileged groups.

On OpenVMS, the Oracle Shared Server must be configured to use only TCP/IP protocol.

5.5.2 TNS Listener Privileges

The process in which the TNS listener runs must have the OpenVMS privileges listed in Table 5-1 to be able to perform the associated function.

5.5.3 Process Quotas

Process quotas for the TNS listener and for the server processes created by the TNS listener can be controlled by logical names. The format of the logical name is:

ORA_LSNR_quotaname 

In this format, quotaname can be one of the following:

• ASTLM

• BIOLM

• BYTLM

• CPULM

• DIOLM

• ENQLM

• FILLM

• JTQUOTA

• PGFLQUOTA

• PRCLM

• TQELM

• WSQUOTA

• WSDEFAULT

• WSEXTENT

Several of the logical names are defined in the LSNRCTL.COM file and control the quotas of the TNS listener process. They are defined in user mode so that they are not present after exiting LSNRCTL. If the TNS listener supports an especially large number of services, then some of these quotas may need to be increased. For the quotas you determine to be deficient, or at the direction of Oracle Support Services, you can edit the quota values in the LSNRCTL.COM file.

To control the quotas of the processes that the TNS listener creates, specify the logical names in the ORA_NETWORK:TNSLSNR.COM file. This is the command file that runs in the TNS listener process. Statements to define these logical names are in the TNSLSNR.COM file, but these statements are put in comments.

If, for example, a very large SGA requires that server processes have larger quotas, then you can activate the appropriate logical name definition in TNSLSNR.COM file by removing the "!" after the "$" and specifying the quota value.

There are no restrictions on the number of quotas that you can specify in the QUOTA list. However, if any quota is specified in the QUOTA list, then none of the quotas specified by logical name is used, and quotas that are not specified in the list will assume the system default.

5.5.4 ORASRV_NETV2_SID Command File

The ORASRV_NETV2_SID.COM file is automatically created for each SID during creation of a database instance.

If an Oracle Shared Server is not being used, then the behavior is the same as seen in earlier releases. The PROGRAM parameter should point to this script in the LISTENER.ORA file. For example:

(SID_LIST_LISTENER = 
 (SID_DESC = 
    (SID_NAME = PROD) 
    (PROGRAM= MY_DISK:[home.NETWORK.ADMIN]ORASRV_NETV2_PROD.COM)
  ) 
) 

When the TNS listener starts a dedicated server process, it extracts the value of the PROGRAM parameter from the LISTENER.ORA file.

In an Oracle Shared Server configuration, the TNS listener need not contain the SID_LIST_listener section mentioned earlier. The Oracle Shared Server dispatchers register with the TNS listener directly. These dispatchers also specify the command procedure to run for a dedicated procedure.

This command procedure is currently set to the ORA_ ROOT:[NETWORK.ADMIN]ORASRV_NETV2_SID.COM, which is created automatically. The location and format of the name of this file cannot be changed. A SID_LIST section in the LISTENER.ORA file that points to the same or different script is completely ignored.

5.5.5 General Connections

Ensure that the Oracle Net Services task file defines any logical names used by the INIT.ORA parameters USER_DUMP_DEST and BACKGROUND_DUMP_DEST (if defined).

5.5.6 Trace Information for TCPIP connection

If the TCPIP connection error is unsuccessful, then please check for the following file:

ORA_ROOT:[NETWORK.LOG]NETV2_sid_pid.LOG

This file matches the time of the error. Provide this file to Oracle Support.

5.6.1 Manual Steps for Authentication Adapters

Set the following parameters in the local INIT.ORA file of the database server:

remote_os_authent = false
os_authent_prefix = ""

For Kerberos5 Adapter

The KRB.CONF file is required on the client side. This configuration file specifies the default realm of the client and maps all known realms to Key Distribution Centers (KDCs).

The following files are required on the server side:

• KRB.REALMS: This file maps host names and domains into realms.

• V5SRVTAB: This file contains a key that the KDC uses to encrypt a service ticket for the client.

The location of these files must be specified by using corresponding parameters in the SQLNET.ORA file.

In addition, the Oracle Net Services client also creates a credential cache file, whose location must be specified in the SQLNET.ORA file on the client side.

The following is an example of the parameters in the SQLNET.ORA file for an installation that can act as both client and server:

SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=ORACLE
SQLNET.AUTHENTICATION_SERVICES = (BEQ,KERBEROS5)
SQLNET.KERBEROS5_KEYTAB = DISK:[TST901.NETWORK.ETC]V5SRVTAB.
SQLNET.KERBEROS5_CONF = DISK:[TST901.NETWORK.KRB5]KRB.CONF
SQLNET.KERBEROS5_REALMS = DISK:[TST901.NETWORK.KRB5]KRB.REALMS
SQLNET.KERBEROS5_CC_NAME = DISK:[TST901.NETWORK.CCACHE]CCFILE.DAT

5.6.2 Usage Notes for Authentication Adapters

This section covers the usage notes for authentication adapters.

General Information

Include the following line in the SQLNET.ORA file:

SQLNET.AUTHENTICATION_SERVICES=(NONE)

The listener should not participate in the authentication service.

It is recommended that you always include BEQ as one of the authentication services in the SQLNET.ORA file. For example:

SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5)

In this way, connections within the server system through the default Bequeath adapter do not have to go through authentication. This is especially important during database startups and shutdowns.

Kerberos5

1. Ensure that the clock skew between the client system and the system running the KDC is less than one minute.

2. Oracle Database client and server processes use the Coordinated Universal Time (UTC) format (time elapsed since 00:00:00 Jan. 1, 1970 in records). Ensure that the system is set to the correct time zone in terms of deviation from Greenwich Mean Time (GMT). Otherwise, the following error message is written to the Oracle Net Services trace file:

   Clock skew too great

3. Ensure that the value of the SQLNET.AUTHENTICATION_KERBEROS5_SERVICE parameter that you specify in the SQLNET.ORA file matches exactly with the value specified in the KDC. This value is case-sensitive.

5.8.1 ADDRESS Specification

IPC and TCP/IP protocol support have a protocol-specific ADDRESS specification that is used for Oracle Net Services configuration files and for the DISPATCHERS initialization parameter in the initsid.ora file.

Table 5-3 shows the ADDRESS specifications for each supported protocol.

5.11.1 Specifying a TCP/IP ADDRESS

The TCP/IP protocol connection parameters are part of the ADDRESS keyword-value pair. The ADDRESS is commonly part of a larger construct such as a connect descriptor or configuration file. You can enter the parameters in any order:

(ADDRESS=

(PROTOCOL=TCP)
   (HOST=hostname)
   (PORT=port)

)

Table 5-5 describes the syntax for the TCP/IP protocol connection parameters.

Example 5-2 shows a sample TCP/IP ADDRESS.

(ADDRESS=

(PROTOCOL=TCP)
   (HOST=MADRID)
   (PORT=1521)

)

PORT=listener_name