Oracle® Database Administrator's Reference
10g Release 1 (10.1) for hp OpenVMS Alpha
Part No. B13738-01
This chapter provides conceptual and configuration information about Oracle Net Services in the OpenVMS environment.
See Also:Oracle Database Net Services Administrator's Guide (B10775-01) for detailed information about Oracle Net Services architecture
It contains the following topics:
Oracle Net Services is a communications software product that enables you to create a data management environment to share information stored in Oracle Database installations. Oracle Net Services uses the communications protocols supported by various operating systems to provide a distributed processing and distributed database environment for Oracle. Oracle Net Services also refers to a set of products or adapters that support industry-standard protocols such as TCP/IP.
An Oracle Database management system can be configured in one of the following ways:
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.
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.
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.
Oracle Net Services connects dissimilar networks together and enables client/server transactions to be conducted transparently. A user does not have to know that a network exists, because Oracle Net Services hides the complexity of system-level interactions by presenting a layer of interconnectivity to the user through its client/server architecture. This layer is called Transparent Network Substrate (TNS).
The transaction proceeds as follows:
The client sends a request for data.
Oracle Net Services packages the request and sends it to the TNS.
TNS routes the packaged request to the server.
Oracle Net Services on the server side unpackages the request and sends it to Oracle Database 10g.
Oracle Database 10g processes the request and sends the requested data to Oracle Net Services.
Oracle Net Services packages the data and sends it to TNS.
TNS routes the data to the client.
Oracle Net Services on the client side unpackages the data and sends it to the application.
Note:This section supplements the information given in Oracle Net Services Administrator's Guide (B10775-01).
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 systemwide 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 following fields must be defined:
(PROTOCOL=IPC) (KEY=IPC logical name)
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.
This example shows the two fields for the OpenVMS Mailbox adapter.
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.
See Also:Oracle Database Installation Guide (B13681-01)
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.4 or later ECO (Patch Kit) 1 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.
The following fields must be defined:
(PROTOCOL=TCP) (HOST=hostname) (PORT=port#)
The following field is optional:
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.
Parameter to increase 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 ALPHA1 host.
(PROTOCOL=TCP) (HOST=ALPHA1) (PORT=1526)
Each database that you want to connect with the Bequeath protocol adapter must have a command file named
ORA_ROOT:[NETWORK.ADMIN]. For databases created with the Oracle7 RDBMS release 7.3.2 or later, this command file is generated when you create the database. You must create this command procedure manually for preexisting databases.
ORA_NETWORK:CREATE_ORASRV_BEQ.COM command as follows:
$ @ORA_NETWORK:CREATE_ORASRV_BEQ ora_db sid dbname
In this command:
ora_db is the database administration directory
sid is the SID of the database
dbname is the NAME of the database
$ @ORA_NETWORK:CREATE_ORASRV_BEQ DKA400:[home.ORADATA.db_name] PROD PRODDB
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
.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:
xxxxxxxxxx is the Oracle image 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:
The Bequeath listener starts automatically when the
INSORACLE command procedure is run, usually at installation time or during system startup. Unless you decide to run the
REMORACLE command, the Bequeath listener should be up and running all the time.
If the Bequeath listener is down and you want to start it, then run the following command:
You can run a status command to determine if the Bequeath listener is up and running. Run the command:
BEQLSNR STATUS [n]
If you do not provide the optional numeric parameter, then Bequeath listener 0 is queried. To determine the status of any other Bequeath listeners, provide the listener number when you run the command.
To stop the Bequeath listener, run the following command:
BEQLSNR STOP [n]
If you do not provide the optional numeric parameter, then all Bequeath listeners for the installation are stopped. To stop a particular Bequeath listener, provide its number at the command line.
This section details the steps that you can take to resolve problems with a Bequeath listener.
The Bequeath listener writes some trace information. Because the output of the detached processes is set to the null device (
NL:), usually, you will not see it.
Stop the Bequeath listener.
NL: to a file name.
Restart the Bequeath listener.
Changing the Quota for a Server Process That is Created by the Bequeath Listener
To change the process quotas, modify the
BEQLSNR.COM file and remove the comment characters for the quota parameter that you want to change. You must stop and then restart the Bequeath listener after modifying this file.
Ensure that after starting the Oracle Database 10g Bequeath listener, the OpenVMS logical ORA_BEQ has the correct install id as part of its value.
Example (with the Bequeath listener running):
$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:"
If you experience this problem, then run the
BEQLSNR STATUS command to determine if the Bequeath listener is up and running. If the Bequeath listener does not respond, then run the
BEQLSNR STOP command to stop the Bequeath listener and run the
BEQLSNR START command to restart it.
Use one of the following solutions:
ORA_BEQ_TIMEOUT logical to something greater than 120 seconds. Before running the client program, you must define this logical in the
ORA_BEQ_NUM_OF_LISTENERS logical to a value between 1 and 10 to increase the capacity, when a number of clients are connecting at the same time to the Bequeath listener.
With this method, you can increase the number of connections that the Bequeath listeners can handle concurrently. Each time that a client requests a connection, it randomly picks one of the Bequeath listeners that are running to serve it with the connection request. Note that you do not need to stop and restart the Bequeath listener after defining this logical name. This logical name determines the number of Bequeath listeners. However, you must start explicitly each Bequeath listener by running the following command:
$ beqlsnr start n
In this command,
n is an integer that starts from 1 for the first listener and goes up to the value of the
The Bequeath listener must have the OpenVMS privileges listed in Table 5-1 to be able to perform the associated functions listed in the table.
Note:Before attempting to start the Bequeath listener or the TNS listener, the process that starts the Bequeath listener must have the privileges listed in Table 5-1 or be able to have them set. Refer to Section 5.5.2, "TNS Listener Privileges" for more information about setting TNS listener privileges.
Table 5-1 Privileges and Functions of Bequeath TNS Listeners
|CMKRNL||Pass this privilege to server processes that the listener creates.|
|DETACH||Create detached processes.|
|LOG_IO||Perform certain I/O functions.|
|PRMMBX||Create a permanent mailbox on which to listen. (The mailbox is permanent so that the logical name associated with it goes into the SYSTEM logical name table.)|
|SYSLCK||Lock systemwide resources.|
|SYSNAM||Create SYSTEM logical names and shared logical name tables.|
|SHARE||May assign channels to nonshared devices.|
|TMPMBX||Create temporary mailboxes.|
|WORLD||Enable the listener to get information about and to control processes that it may not have created, such as dispatchers and shared server processes.|
The function of the TNS listener is to receive connection requests from local or remote clients and to provide the client with a server process to which the client can connect. The listener can service multiple instances. For each instance, the listener keeps a list of services that provide access to that instance. If multithreaded servers are being used, then the listener may direct a client connection to a dispatcher. Otherwise, for dedicated servers, the listener directs the client connection to an existing Oracle Shared Server or creates a new server process to service the connection.
In Oracle Database 10g, there is a major change in the way the listener is configured for Oracle Shared Servers. The Oracle Shared Server parameters are not the same as in Oracle8i. When you configure for Oracle Shared Server, a request for a dedicated server is no longer handled using the parameters from the
LISTENER.ORA file. This now happens as part of the dispatcher registration. The
PMON process registers dispatchers with the listener for Oracle Shared Server connections.
Generic information about the TNS listener and its configuration can be found in the generic Oracle Net Services documentation. This section provides information only about the TNS listener that is specific to OpenVMS.
This section contains information about the following topics:
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
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
Note:Start the TNS listener by using the Oracle Account.
Caution:If you enter the
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.
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.
Note:Before attempting to start the TNS listener, the process that starts the listener must have the privileges in Table 5-1 or be able to have them set. As noted in the preceding section, the
In this format,
quotaname can be one of the following:
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
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 remove the appropriate logical name definition from the comment in the
TNSLSNR.COM file and specify the quota value.
Quotas can also be specified for the Server processes in the
LISTENER.ORA file on an
SID basis. This is done in the
SID_DESC section for a TNS listener. For example:
SID_LIST_LISTENER = (SID_DESC = (SID_NAME = name) (PROGRAM = disk:[directory]ORASRV_NETV2_SID.COM) (OSDS= (PRIORITY=number) (QUOTA= (ASTLM=number) (BYTLM=number) (PGFLQUOTA=number) ) ) )
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.
Note:The process priority of the server can also be specified, but this is not recommended.
In 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
In an Oracle Shared Server configuration, the TNS listener need not contain the
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
.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.
Note:A separate license is required to use ASO.
This section covers the following topics:
Set the following parameters in the local
INIT.ORA file of the database server:
remote_os_authent = false os_authent_prefix = ""
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
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
This section covers the usage notes for authentication adapters.
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:
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.
Ensure that the clock skew between the client system and the system running the KDC is less than one minute.
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
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.
This section describes the files that you can use to configure Oracle Net Services products.
See Also:Oracle Net Services Administrator's Guide (B10775-01)
The default directory for Oracle Net Services configuration files is
Oracle Net Services searches for configuration files in the following order:
sqlnet.ora file, the current working directory from where an application is run
The directory specified by the
TNS_ADMIN logical, if it is set
For each system-level configuration file, users may have a corresponding local private configuration file (stored in the user's home directory). The settings in the local file override the settings in the system-level file. Table 5-2 lists the system-level configuration files and the corresponding local configuration files:
Oracle Net Services release 10.1.0.3.0 on OpenVMS supports the following protocols:
Before installing the TCP/IP protocol support, you must install and configure the required operating system software. The BEQ and IPC protocol supports do not have any specific operating system requirements.
See Also:Oracle Database Installation Guide (B13681-01) for more information about Oracle Net Services protocol support.
The IPC, TCP/IP and Oracle Net Services protocol supports have a protocol-specific ADDRESS specification that is used for Oracle Net Services configuration files and for the DISPATCHERS initialization parameter in the
Table 5-3 shows the ADDRESS specifications for each supported protocol.
The Bequeath (BEQ) protocol support is both a communications mechanism and a process-spawning mechanism. To use the BEQ protocol support, the client and the server must be on the same system. A network service name can be specified directly by the user at the command line or on the Login screen. It can also be specified indirectly by using a logical, such as
If a network service name is not specified, then the BEQ protocol support is used. In this case, the BEQ protocol support always uses a dedicated server and the shared server model is never used. This dedicated server is started automatically by the BEQ protocol, which waits for the server process to start and attach to an existing System Global Area (SGA). If the startup of the server process is successful, then the BEQ protocol support provides interprocess communication through OpenVMS mailboxes.
An important feature of the BEQ protocol support is that it does not require a listener for its operation. The protocol support is linked to the client tools and directly starts its own server process without outside interaction. However, you can use the BEQ protocol support only when the client program and Oracle Database 10g are installed on the same system. The BEQ protocol support is always installed and always linked to all client tools and to the Oracle Database 10g server.
The IPC protocol support is similar to the BEQ protocol support in that it can be used only when the client program and the Oracle Database 10g server are installed on the same system. The IPC protocol support differs from the BEQ protocol support in that it can be used with Oracle Shared Server configurations. The IPC protocol support requires a listener for its operation. The IPC protocol support is always installed and always linked to all client tools and to Oracle Database 10g.
The IPC protocol support 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 following parameters in any order:
Table 5-4 describes the syntax for IPC protocol connection parameters.
Table 5-4 Syntax for IPC Protocol Connection Parameters
|PROTOCOL||IPC protocol support to be used
The value is IPC. It is not case-sensitive.
|KEY||Service name of database or system identifier (
Example 5-1 shows a sample IPC ADDRESS.
On OpenVMS, the default
tnslnr port is 1521.
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:
(PROTOCOL=TCP) (HOST=hostname) (PORT=port)
Table 5-5 describes the syntax for the TCP/IP protocol connection parameters.
Table 5-5 Syntax for TCP/IP Protocol Connection Parameters
|PROTOCOL||The protocol support to be used
The value is TCP. It is not case-sensitive.
|HOST||The host name or the host IP address|
|PORT||The TCP/IP port|
Example 5-2 shows a sample TCP/IP ADDRESS.