|Oracle® Database Installation and Administration Guide
11g Release 2 (11.2) for Fujitsu BS2000/OSD
|PDF · Mobi · ePub|
This chapter describes Oracle Net Services and it's implementation in the BS2000/OSD environment. It supplements the Oracle Database Net Services Administrator's Guide with BS2000/OSD-specific information about the following topics:
Oracle Net Services supports network communication between a client application and a remote or local database running on a variety of operating systems.
Oracle Net Services allows the database servers and the client applications, or servers acting as clients, to run on separate systems, and provides a means for moving data between the nodes on a network. For example, a UNIX or Windows user can run applications that access and manipulate data in a remote Oracle database running on a BS2000 system
Oracle Net Services is also used for Inter Process Communication if clients and database are running on the same system.
This section introduces Oracle's Interprocess Communication (IPC) protocol support for inter-process calls. It is used to map the functionality of IPC to Oracle's Net Foundation Layer. The IPC protocol is supported for native BS2000 only. Oracle Utilities and products running in the POSIX shell cannot use the IPC protocol.
On BS2000 systems, the IPC protocol is used for local inter-process communication. The Oracle Protocol Support for IPC uses the ISO functionality of the BS2000 sockets.
The client process initiates its IPC connection with the remote process by specifying a
KEY that describes the listening process. Once the connection is established, the two communicating processes send and receive data through a continuous byte stream.
The IPC protocol allows applications to integrate with the Inter Process Communication method on a local host. The following is the syntax for using IPC protocol:
(ADDRESS= (PROTOCOL=IPC) (KEY=alphanumeric) )
PROTOCOL specifies the supported protocol. For IPC, the value is "IPC".
KEY specifies the listen endpoint. A string of at most 32 characters: [a...z], [A...Z], [0...9], '.', '-', '_', '$'
The following is an example of an IPC ADDRESS that specifies a server on a local host:
(ADDRESS= (PROTOCOL=IPC) (KEY=ORCL) )
Note:The IPC protocol is not supported in the POSIX shell. If the IPC protocol is specified by a utility or user application running in the POSIX shell, then Oracle Net Services avoids using the IPC protocol with the following error message:
TNS-12557: TNS:protocol adapter not loadable
This section introduces Oracle's TCP/IP protocol support, which is used to map the functionality within TCP/IP to Oracle's Net Foundation Layer.
TCP/IP is a family of related protocols that derives its name from two main components: the Transmission Control Protocol (TCP) and the Internet Protocol (IP). The IP component dispatches information around the network, and the TCP component assures reliable transfer of data from one point to another.
Application software sitting on top of the TCP/IP protocol views the network as a reliable two-way data transmission medium. This medium provides inter-process communication in a connection-oriented manner between pairs of processes in host computers attached to inter-connected computer networks.
The application or client process initiates its TCP/IP connection with the remote host process by specifying an address pair:
A host IP address
A TCP port (or entry point) on the host
Once the connection is established, the pair of communicating processes sends and receives data through a continuous byte stream. The TCP/IP protocol is supported in BS2000 and the POSIX shell.
The TCP/IP protocol support implements a standard interface that is used to resolve the equivalent communication functions between the TCP/IP protocol and Oracle's Net Foundation Layer.
After the TCP/IP protocol is installed for the particular system, you can use the TCP/IP–specific parameters with the TNS connect descriptors to identify nodes within a TCP/IP-based community.
The specific TCP/IP connection parameters are part of the
ADDRESS keyword-value pair. The three TCP/IP–specific parameters can be entered in any order within the
ADDRESS construct. The syntax used by Oracle's TCP/IP protocol support is:
(ADDRESS= (PROTOCOL=TCP) (HOST=hostname) (PORT=port#) )
PROTOCOL specifies the supported protocol. For TCP/IP, the value is
HOST specifies the host name or the host's IP address.
PORT specifies the TCP/IP port number.
The following is an example of the TCP/IP ADDRESS specifying a client on the
(ADDRESS= (PROTOCOL=TCP) (HOST=sales-server) (PORT=1521) )
The Bequeath technique enables clients to connect to a database without using the network listener. Oracle's Bequeath protocol internally spawns a server process for each client application. It does the same operation that a remote network listener does for the connection locally.
Note:Starting with Oracle Database 10g the BEQ protocol uses the handoff technique which makes this protocol incompatible with the BEQ protocol of prior versions. As a consequence of this enhancement, Oracle Database 11g applications cannot directly spawn a process of a version prior to Oracle Database 10g and connect to it through the BEQ protocol.
The Bequeath protocol
Does not use a network listener (therefore, no listener configuration is required).
Automatically spawns a dedicated server
Is used for local connections where an Oracle Database client application, such as SQL*Plus, communicates with an Oracle Database instance running on the same computer.
Only works in Dedicated Server mode. It cannot be used in a Shared Server mode.
Note:If clients are running under a user ID different from the
DBAuser ID, then Oracle recommends using a net service name to connect through a listener to the destination database.
The initialization parameters that control the shared server architecture are as follows:
For detailed information about the shared server architecture, refer to the Oracle Database Net Services Administrator's Guide.
The shared server architecture and the dedicated server architecture can work concurrently in an instance. Provide information in the connect descriptor to indicate whether a connecting application should use the shared server or the dedicated server architecture. By default, the listener process uses the shared server architecture and if you want the application to use the dedicated server architecture instead, you must set
USE_DEDICATED_SERVER=ON in the
SQLNET.ORA file or specify a
net_service_name with the parameter
SERVER in the used naming method. The
USE_DEDICATED_SERVER=ON overwrites the parameter
The following example shows how to reference a dedicated server in a shared server configuration by using a specially defined net service name:
FINANCE_DED=(DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=sales-server) (PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (SERVER=dedicated)))
For more information, refer to the Oracle Database Net Services Reference guide.
In choosing whether to use the shared server or the dedicated server architecture, you must consider the CPU overhead versus resource allocation, such as tasks, memory and so on. In a situation where many clients need to work only occasionally with the Oracle Database, it would be best to use the shared server architecture, whereas, in a situation where just a few clients need to work with the Oracle Database regularly, it would be best to use the dedicated server architecture. Your decision may not always be as clear-cut as that in these examples. If this is the case, then you can use the information in the following shared server dynamic tables to help you arrive at your decision:
For more information about these tables, refer to the Oracle Database Administrator's Guide.
With this release the data integrity and the cryptographic services of Oracle Advanced Security are supported. The Secure Sockets Layer (SSL) protocol is also supported. SSL provides authentication, encryption, and data integrity using public key infrastructure (PKI). SSL stores authentication data, such as certificates and private keys, in an Oracle Wallet.
For using either the data integrity, or the cryptographic services, or both, you must specify the appropriate parameters in the
Use the following parameters to specify whether a service (example: crypto-checksumming or encryption) should be active:
SQLNET.CRYPTO_CHECKSUM_CLIENT SQLNET.CRYPTO_CHECKSUM_SERVER SQLNET.ENCRYPTION_CLIENT SQLNET.ENCRYPTION_SERVER
Each of the preceding parameters defaults to
Each of the preceding parameters can have one of the following values:
||The service is active if the other side of the connection specifies
||The service must not be active, and the connection fails if the other side specifies
||The service is active if the other side specifies
||The service must be active, and the connection fails if the other side specifies
Use the following parameters to control which algorithms are made available for each service on each end of a connection:
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER SQLNET.ENCRYPTION_TYPES_CLIENT SQLNET.ENCRYPTION_TYPES_SERVER
The value of each of these parameters can be either a list of algorithm names in parenthesis separated by commas or a single algorithm name.
The default crypto checksum type is MD5, while the encryption defaults to all the algorithms.
|Crypto checksum types||
Use the parameter
SQLNET.CRYPTO_SEED to specify the characters used when generating cryptographic keys. The more random the characters are, the stronger the keys are. The string should be 10-70 random characters. This is required when encryption or checksumming is turned on.
For more information, refer to Oracle Database Net Services Administrator's Guide, Oracle Database Net Services Reference, and Oracle Database Advanced Security Administrator's Guide.
SQLNET.CRYPTO_CHECKSUM_CLIENT=required SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT=(md5) SQLNET.ENCRYPTION_CLIENT=accepted SQLNET.ENCRYPTION_TYPES_CLIENT=(aes192,3des168,rc4_128) SQLNET.CRYPTO_SEED="qwertyuiopasdfghjkl;zxcvbnm,.s1"
Although, you can use the Easy Connect Naming Method to connect to the database, it is recommended to configure clients for the use of service names that are easy to remember aliases for database addresses and match the address preconfigured in each system's
LISTENER.ORA file. The client uses these addresses to connect to the network listener, which routes the connection request to the required service. During a connection, a client passes the service name to which it wants to connect.
LISTENER.ORA file identifies and controls the behavior of the network listener that listens for services on the system. This file includes network listener descriptors and addresses, services the listener is listening for, and various control parameters.
Client configuration is accomplished by creating a list of net service names with addresses of network destinations through the local naming parameter file
TNSNAMES.ORA or an LDAP compliant directory server. Clients and database servers (that are clients of other database servers) use the net service name when making a connection.
The Easy Connect naming method, can be used to connect to a database without the need to configure service names in the
TNSNAMES.ORA configuration file. For using the Easy Connect naming method, ensure that
EZCONNECT is listed in the client's configuration file parameter for naming adaptors
Easy Connect naming is only suitable in small and simple environments. Refer to "Using the Easy Connect Naming Method" in Oracle Database Net Services Administrator's Guide for more information about the Easy Connect naming method.
Local naming refers to the method of resolving a service name to a network address by using information configured on each individual client in a
TNSNAMES.ORA configuration file. For using the local naming ensure that
TNSNAMES is listed in the client's configuration file parameter for naming adaptors
Local naming is most appropriate for simple distributed networks with a small number of services that change infrequently.
Directory Naming refers to the method of resolving a service name to a network address by using a Directory Server. For using a directory server ensure that
LDAP is listed in the client's configuration file parameter for naming adaptors
names.directory_path and that the target address of the directory server is configured in the parameter file
LDAP.ORA, for example:
# LDAP.ORA Network Configuration File: network.admin.ldap.ora DEFAULT_ADMIN_CONTEXT = "" DIRECTORY_SERVERS= (oid_server:389:636) DIRECTORY_SERVER_TYPE = Your Internet Directory
For more information, refer to the Oracle Database Net Services Administrator's Guide.
Follow these steps to configure the Oracle Names Method:
Before starting the listener, you must set up the listener's configuration file
LISTENER.ORA. This file includes the addresses of the listeners and various control parameters used by the listener. For more information refer to the Oracle Database Net Services Administrator's Guide
On BS2000 systems you have the chance to define additional job parameters for the Oracle Database tasks particularly a
PROCESSING-ADMISSION to start a job under a user ID different from the user ID of the running job. This technique provides the benefits of using only one listener for all Oracle instances on the system. The instances need not run under the same user IDs. If you want to run only one listener on the database computer, then you must specify the following parameters in the listener's environment file
||the user ID under which the job should run|
||Account of the target user ID|
||Password of the target user ID|
The following example of an
ORAENV file configured for a central listener process shows how the parameters work. The listener can share this
ORAENV file with an instance, which runs under the same user ID. For a better understanding, we assume that the listener and the instances
DEM1 are running under the user ID
ORACDEM1 while the instance
DEM2 is running under the user ID
ORACDEM2. We define the following parameters:
BGJPAR=J-C=JCBORA,START=IMME,CPU-LIMIT=NO,LOGGING=*NO DEM1_BGJPAR=J-C=JCBDEM1,START=IMME,CPU-LIMIT=NO DEM2_USER=ORACDEM2 ORACDEM2_ACCOUNT=O1234 ORACDEM2_PASSWORD=ORACLE
The listener always runs the same sequence to look up the parameters
_USER. If no value for
_BGJPAR is found, then the listener uses the value given by the parameter
BGJPAR. If a user ID is given by
_USER, then the listener tries to get the processing admission from the parameters
user_PASSWORD. For the given
ORAENV we get the following scenarios for the listener:
The listener should start a server for the instance
DEMO. Because the parameters
DEMO_USER are not defined the listener starts the server for the instance
DEMO under the user ID
ORACDEM1 with the start parameters defined by
If a server for the instance
DEM1 must be started, then the listener looks for the parameters
DEM1_USER. In this case the parameter
DEM1_BGJPAR can be evaluated, whereas, the evaluation of
DEM1_USER failed because this parameter is not defined. Therefore, the listener adds the start parameters "
J-C=JCBDEM1,START=IMME,CPU-LIMIT=NO" to the
ENTER-PROCEDURE command and starts the job under the user ID
Now a server for instance
DEM2 must be started. The listener looks for the parameters
DEM2_USER. The parameter
DEM2_BGJPAR is not defined so that the listener uses the start parameters defined by
BGJPAR. On the other hand the parameter
DEM2_USER can be evaluated successfully and returns the value
ORACDEM2. Now the listener tries to get the processing admission by evaluating the parameters
ORACDEM2_PASSWORD. The listener starts the server job under the user ID
ORACDEM2 with the
ENTER-PROCEDURE parameters "
Start the listener using the Listener Control Utility
/CALL-PROCEDURE sid.P.ORAENV /START-PROGRAM $ORAC1120.LSNRCTL
enter options prompt is displayed, press ENTER to get to the
LSNRCTL prompt. Enter the following command to start the Listener:
LSNRCTL> START listener-name
Configuration of network clients involves adding or editing parameters in the client configuration file
SQLNET.ORA and dependent on the used naming method, the configuration file
TNSNAMES.ORA. For more information about the configuration parameters, refer to Oracle Database Net Services Reference.
After you have verified the network connections, you can verify the connections to the desired Oracle database systems using the
/CALL-PROCEDURE sid.P.ORAENV /START-PROGRAM $ORAC1120.TNSPING
enter options prompt is displayed, enter the net service name for the database service which you have specified in the naming service. If everything works fine, then a message similar to the following is returned:
TNS Ping Utility for BS2000/OSD S series: Version 188.8.131.52.0 - Production on 12-JUN-2012 12:07:40 Used parameter files: network.admin.sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = sales-server)(PORT = 3055))) (CONNECT_DATA = (SERVICE_NAME = sales.us.acme.com))) OK (40 msec)
For more information, refer to the Oracle Database Net Services Administrator's Guide.
The following is a list of error messages and steps to fix the errors:
Listener could not be started.
LSNRCTL returns the following error message:
LSNRCTL> start Starting /BS2/$ORAC1120.tnslsnr: please wait... TNS-12547: TNS:lost contact TNS-12560: TNS:protocol adapter error TNS-00517: Lost contact BS2000 Error: 145: Connection timed out LSNRCTL>
Ensure that the subsystem
POSIX is up and running.
Ensure that the
BCAM Leight Weight Resolver
LWRESD is properly configured and running.
Listener could not open the log file.
Check if the listener log file, for example,
NETWORK.LOG.LISTENER.LOG, is accessible and readable.
Verify the listener log file using the BS2000 SDF command
If you are not able to repair the listener log file, then delete the file.
A client reports ORA-12545
Check the naming service if the host name returned by the listener is well known in the TCP/IP network.
Ensure that the
BCAM Leight Weight Resolver
LWRESD is properly configured and running.
A client reports ORA-12535
If you use the IPC protocol, then check the Connection Timeout parameter of
BCAM (use the
BCSHOW command). This parameter should be set to at least 600 seconds.
A client reports ORA-03113
Check if the
SQLNET.EXPIRE_TIME parameter is set for the server. If the parameter is set, then check the
BCAM LETTER-TIMER using the BCSHOW command. If the
LETTER-TIME is less than the
SQLNET.EXPIRE_TIME, then data which are sent by the server to see if the client is running may not be read during their lifetime, which is limited by the
LETTER-TIME. As a result, the client logs a broken pipe in the
ns main err code: 12547 ns (2) err code: 12560 nt main err code: 517 nt (2) err code: 32 nt OS err code: 0x0040002c
You can solve this problem by setting the
LETTER-TIMER to infinite.