Oracle® Database Administrator's Reference 10g Release 2 (10.2) for hp OpenVMS Part Number B25416-02 |
|
|
View PDF |
This chapter provides conceptual and configuration information about Oracle Net Services in the OpenVMS environment.
See Also:
Oracle Database Net Services Administrator's Guide for detailed information about Oracle Net Services architectureIt 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.
When you install Oracle Net Services on OpenVMS, the following protocol adapters are automatically installed:
TCP/IP
Bequeath
IPC, and
TCPS
See Also:
The ORA_RDBMS:READMEVMS.DOC
file
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.This section gives information about the following protocol adapters on OpenVMS:
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)
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 GuideOracle 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 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 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
.
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:
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:
$ BEQLSNR START [n]
If you do not provide the optional numeric parameter, then Bequeath
listener 0 is started. To start additional Bequeath
listeners, provide the listener number when you run the command.
You can run a status command to determine if the Bequeath
listener is up and running. Run the following 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.
Collecting Bequeath Client Trace Information:
Look for a file in ORA_ROOT:[network.log]BEQ_sid_pid.LOG
that corresponds to the time of a client connect/disconnect issue.
Make file available to Oracle Support.
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.
To get the trace information from the Bequeath
listener:
Stop the Bequeath
listener.
Edit STARTUP_BEQLSNR.COM
.
Change 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 Bequeath
listener, the OpenVMS logical name 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:"
Problem: ORA-12203: TNS: unable to connect to destination
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.
Note:
Contact Oracle Support if theBequeath
listener does not respond, even after restarting it.Client Problem: ORA-12203: TNS: unable to connect to destination
Use one of the following solutions:
Change the ORA_BEQ_TIMEOUT
logical name to something greater than 120 seconds. Before running the client program, you must define this logical name in the ORA_NETWORK:BEQLSNR.COM
file.
Define the ORA_BEQ_NUM_OF_LISTENERS
logical name 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.This is the number of Bequeath
listener that you need to run.
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 ORA_BEQ_NUM_OF_LISTENERS
logical name.
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 theBequeath
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 describes the Open VMS privileges and functions of Bequeath
TNS listeners.
Table 5-1 Privileges and Functions of Bequeath TNS Listeners
Privilege | Function |
---|---|
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 |
SYSLCK |
Lock system-wide resources. |
SYSNAM |
Create |
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.
Note:
TheSID_LIST_
listener
section is no longer used to establish dedicated server connections. These are now automatically handled by the listener, which directly uses the ORA_ROOT:[NETWORK.ADMIN]ORASRV_NETV2_
sid
.COM
script to launch the dedicated server process. This script is automatically created when a new database or instance is created through Oracle Database Configuration Assistant or scripts provided by Oracle Database Configuration Assistant.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:
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.
Note:
Start theTNS
listener from the Oracle Account.Caution:
If you enter theLSNRCTL
interactive mode by giving the LSNRCTL
command without a subcommand, and you have received a warning about inadequate privileges, then do not attempt to start the listener. Depending on the privileges you have, although the listener process may start, it may not function properly.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 theTNS
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 LSNRCTL
command attempts to set these privileges and warns the user if it was unable to do so.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 remove the appropriate logical name definition from TNSLSNR.COM
file by removing the "!" after the "$" and specifying the quota value.
Quotas can also be specified for the Server processes in the LISTENER.ORA
file on an sid-by-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.
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.
This section provides information that is specific to the current release of Advanced Security Option (ASO) for Security and Single Sign-On.
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 = ""
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
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.
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.
The default directory for Oracle Net Services configuration files is ORA_ROOT:[NETWORK.ADMIN]
or TNS_ADMIN
.
Oracle Net Services searches for configuration files in the following order:
For the SQLNET.ORA
file, the current working directory from where an application is run
The directory specified by the TNS_ADMIN
logical name, 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 10g on OpenVMS supports the following protocols:
Bequeath (BEQ)
IPC
TCP/IP
Before installing the TCP/IP protocol support, you must install and configure the required operating system software. BEQ and IPC protocol support does not have any specific operating system requirements.
See Also:
Oracle Database Installation Guide for more information about Oracle Net Services protocol supportIPC 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 init
sid
.ora
file.
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 name, such as ORA_DFLT_HOSTSTR
.
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 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:
(ADDRESS=
(PROTOCOL=IPC)
(KEY=key)
)
Table 5-4 describes the syntax for IPC protocol connection parameters.
Table 5-4 Syntax for IPC Protocol Connection Parameters
Parameter | Description |
---|---|
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:
(ADDRESS=
(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
Parameter | Description |
---|---|
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.