| Oracle® Database Installation and Administration Guide 10g Release 2 (10.2) for Fujitsu Siemens BS2000/OSD Part Number E10319-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Database Installation and Administration Guide 10g Release 2 (10.2) for Fujitsu Siemens BS2000/OSD Part Number E10319-01 |
|
|
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, that access it 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.
The following are the new features in Oracle Net Services:
Oracle Advanced Security
With this release the encryption and data integrity functionality of Oracle Advanced Security are supported. Creating and managing an Oracle Wallet is now supported by the tools owm and orapki.
Direct Handoff
Oracle Database 10g on BS2000 now supports the handoff/direct handoff technique, that is the listener will route the connection request of a client directly to a server. The benefit of the handoff/direct handoff technique is that the client must know only one access point. For example, in a TCP/IP connection only the listener port must be reachable by the client. Unfortunately, this benefit makes the BEQ protocol incompatible with prior versions.
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.
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)
)
where
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)
)
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 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#)
)
where
PROTOCOL specifies the supported protocol. For TCP/IP, the value is TCP.
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 sales-server host:
(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:
Oracle Database 10g 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 10g applications cannot directly spawn a process of a prior version 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
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 theDBA user ID, 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 on the shared server architecture, please 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. You provide information in the connect descriptor to indicate whether a connecting application is to 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 need to set USE_DEDICATED_SERVER=ON in the SQLNET.ORA file or to specify a net_service_name with the parameter SERVER in the used naming method. Note that the SQLNET.ORA parameter USE_DEDICATED_SERVER=ON overwrites the parameter SERVER.
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 need to 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, you can use the information in the following shared server dynamic tables to help you arrive at your decision:
V$DISPATCHER
V$QUEUE
V$SHARED_SERVERS
V$SHARED_SERVER_MONITOR
For more information on 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 have to specify the appropriate parameters in the SQLNET.ORA file.
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 REJECTED.
Each of the preceding parameters can have one of the following values:
| Value | Meaning |
|---|---|
ACCEPTED |
The service will be active if the other side of the connection specifies REQUESTED or REQUIRED and there is a compatible algorithm available on the other side. It will be inactive otherwise. |
REJECTED |
The service must not be active, and the connection will fail if the other side specifies REQUIRED. |
REQUESTED |
The service will be active if the other side specifies ACCEPTED, REQUESTED, or REQUIRED and there is a compatible algorithm available on the other side. It will be inactive otherwise. |
REQUIRED |
The service must be active, and the connection fails if the other side specifies REJECTED or if there is no compatible algorithm on the other side. |
Use the following parameters to control which algorithms will be 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.
| Type | Values |
|---|---|
| Crypto checksum types | SHA1, MD5 |
| Encryption types | AES256, RC4_256, AES192, 3DES168, AES128, RC4_128, 3DES112, RC4_56, DES, RC4_40, DES40 |
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.
SQLNET.CRYPTO_SEED="qwertyuiopasdfghjkl;zxcvbnm,.s1"
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.
Example:
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"
Before a database can receive connections from clients, clients must be configured with 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.
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 make sure that "TNSNAMES" is listed in the client's configuration file parameter for naming adaptors names.directory_path.
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 make sure 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 have to 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, you have to specify the following parameters in the listener's environment file sid.P.ORAENV:
| Parameter | Meaning |
|---|---|
BGJPAR |
parameters for ENTER jobs |
sid_BGJPAR |
parameters for ENTER jobs identified by sid |
sid_USER |
the user ID under which the job should run |
user_ACCOUNT |
Account of the target user ID |
user_PASSWORD |
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 DEMO and 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 sid_BGJPAR and sid_USER. If no value for sid_BGJPAR are found, the listener uses the value given by the parameter BGJPAR. If a user ID is given by sid_USER the listener tries to get the processing admission from the parameters user_ACCOUNT and 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_BGJPAR and 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 BGJPAR.
If a server for the instance DEM1 must be started the listener looks for the parameters DEM1_BGJPAR and DEM1_USER. In this case the parameter DEM1_BGJPAR can be translated, whereas, the translation 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 ORACDEM1.
Now a server for instance DEM2 must be started. The listener looks for the parameters DEM2_BGJPAR and 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 translated successfully and returns the value ORACDEM2. Now the listener tries to get the processing admission by translating the parameters ORACDEM2_ACCOUNT and ORACDEM2_PASSWORD. The listener starts the server job under the user ID ORACDEM2 with the ENTER-PROCEDURE parameters "J-C=JCBORA, START=IMME,CPU-LIMIT=NO,LOGGING=*NO".
Start the listener using the Listener Control Utility LSNRCTL:
CALL-PROCEDURE sid.P.ORAENV
START-PROGRAM $ORAC1020.LSNRCTL
When the 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 LDAP.ORA or 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 TNSPING utility:
CALL-PROCEDURE sid.P.ORAENV
START-PROGRAM $ORAC1020.TNSPING
When the 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 a message similar to the following is returned:
TNS Ping Utility for BS2000: Version 10.2.0.2.20 - Production on 04-JUL-2007 14:49:53 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 (340 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/$ORAC1020.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>
Make sure that the subsystem POSIX is up and running.
Make sure 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 REPAIR-DISK-FILES.
If you are not able to repair the listener log file, delete the file.
A client reports ORA-12545
Check the naming service if the hostname returned by the listener is well known in the TCP/IP network.
If you do not want to use the BCAM hostname of the computer in the TCP/IP network, define a sockets-host-name as described in the BCAM documentation and register this name in the name service.
Make sure that the BCAM Leight Weight Resolver LWRESD is properly configured and running.
A client reports ORA-12535
If you use the IPC protocol, 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, please check the BCAM LETTER-TIMER using the BCSHOW command. If the LETTER-TIME is less than the SQLNET.EXPIRE_TIME, 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 will log a broken pipe in the SQLNET.LOG file:
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 LETER-TIMER to infinite
|
 Copyright © 2007, Oracle. All rights reserved. Legal Notices |
|