Skip Headers

Oracle8i Server Installation and Database Administration Guide
Release 3 (8.1.7) for Fujitsu Siemens Computers BS2000/OSD

Part Number A95466-01
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

9
Net8

This chapter describes Net8 and its implementation in the BS2000/OSD environment. It supplements the Oracle Net8 Administrator's Guide with BS2000/OSD-specific information about the following topics:

Net8 Products

Products supported on BS2000/OSD

Net8 Client

yes

Net8 Server

yes

Oracle Protocol Adapters

  • IPC Protocol Adapter

yes

  • TCP/IP Protocol Adapter

yes

  • OSI4 Protocol Adapter

yes

  • MTT Protocol Adapter

yes

  • Bequeath Protocol Adapter

yes

Oracle Names Server

yes

Naming Methods and Oracle Naming Adapters

  • Host Naming
    - HOSTNAME
    - DNS


no
no

  • Local Naming
    - TNSNAMES


yes

  • Centralized Naming using Oracle Names
    - ONAMES/ONRS


yes

  • External Naming
    - NDS
    - NIS
    - DCE/CDS


no
no
no

Oracle Connection Manager

yes

Oracle Advanced Networking Option

no

Oracle Security Server

no

Net8 Utilities
- TNSPING a
- TRCROUTE


yes
yes

Configuration Tools
- Oracle Net8 Easy Config
- Oracle Net8 Assistant


no
no

Troubleshooting Tools
- Oracle Net8 Trace Assistant
- Intelligent Agent


yes
no

Introducing Net8

Net8 supports network communication between a client application and a remote or local database running on a variety of operating systems.

Net8 allows the database servers and the client applications (or servers acting as clients) that access it to run on separate machines, and provides a means for moving data between the nodes on a network.

For example, a UNIX or Windows user can run Developer/2000 applications that access and manipulate data in a remote Oracle Server database running on a BS2000 machine.

Net8 is also used for Inter Process Communication if clients and servers are running on the same machine in the Oracle two-task operating environment.

Oracle Protocol Adapters

Overview

The Oracle Protocol Adapters allow the Transparent Network Substrate (TNS) and its applications to communicate over existing network communication protocols. (A communications protocol is a set of software-implemented standards, or rules, that govern the transmission of data across a network.) The Protocol Adapters map the functions of the underlying protocol into the equivalent functions within TNS. This mapping of communication functions allows calls to or from TNS to be protocol non-specific. An Oracle Protocol Adapter exists for each available application program interface (API) for all industry-standard network protocols.

Figure 9-1 shows how TNS and the Oracle Protocol Adapters interface with existing network protocols. For any TNS client running an industry-standard protocol, the Oracle Protocol Adapter interfaces between the unique API of the underlying protocol and the consistent interface of Oracle's TNS.

Text description of fig9-2.gif follows.

Text description of the illustration fig9-2.gif

Figure 9-1 TNS, Adapters and Protocols

In addition to the differences between vendor-supplied protocols, there are differences between implementations of multiple vendor offerings of the same protocol on many platforms. Since the API of these protocol implementations is different, a separate Oracle Protocol Adapter is required. Figure 9-2 shows the Oracle Protocol Adapter implementations for different versions of three TCP/IP protocols.

Text description of fig9-3.gif follows.

Text description of the illustration fig9-3.gif

Figure 9-2 Adapter Implementations

IPC Adpater

This section introduces Oracle Corporation's Interprocess Communication (IPC) protocol adapter for interprocess calls. It is used to map the functionality of IPC to Oracle's Transparent Network Substrate (TNS).

Overview of IPC

On BS2000 machines, the IPC adapter is used for local interprocess communication. The Net8 IPC adapter uses the ISO functionality of the BS2000 sockets which provides the exceptional advantages of using more than one protocol in a single task efficiently. This technique enables you to configure a listener to listen on a IPC, TCP/IP and OSI4 endpoint without any need of running a polling sequence over these protocols.

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 continous byte stream.

Using the IPC Adapter

The IPC adapter allows TNS and TNS applications to integrate with the Inter Process Communication method on a local host. The syntax for the IPC adapter connection is:

(ADDRESS=
	   (PROTOCOL=IPC)
	   (KEY=alphanumeric)
)

where:

PROTOCOL
specifies the specific adapter to be used. For IPC, the value is "IPC".

KEY
specifies the listen endpoint. A string of at most 32 characters: [a...z], [A...Z], [0...9], '.', '-', '_', '$'

Here is an example of an IPC ADDRESS that specifies a server on a local host:

(ADDRESS=
	   (PROTOCOL=IPC)
	   (KEY=ORA8.WORLD)
)

TCP/IP Adapter

This section introduces the TCP/IP protocol and Oracle Corporation's TCP/IP Adapter, which is used to map the functionality within TCP/IP to Oracle's Transparent Network Substrate (TNS).

Overview of TCP/IP

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:

Once the connection is established, the pair of communicating processes sends and receives data through a continuous byte stream.

Using the Oracle TCP/IP Adapter

The Oracle TCP/IP adapter allows TNS and its applications to integrate with the TCP/IP communications protocol. The TCP/IP adapter implements a standard interface that is used to resolve the equivalent communication functions between the TCP/IP protocol and TNS.

Once the TCP/IP protocol is installed for your 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 adapter 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 for the TCP/IP adapter connection is:

(ADDRESS=

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

where:

PROTOCOL
specifies the specific adapter to be used. 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.

Here is an example of the TCP/IP ADDRESS specifying a client on the MADRID host:

(ADDRESS=

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

OSI4 Adapter

This section introduces Oracle Corporation's OSI4 protocol adapter for client/server communications in ISO based networks. The OSI4 protocol adapter is used to map the functionality of the ISO network protocol to Oracle's Transparent Network Substrate (TNS).

Overview of OSI4

The OSI4 protocol adapter makes use of the BS2000 sockets which support the ISO address family. With the ISO address family the sockets follows the rules of the OSI (Open System Interconnection) reference model and supports an interface to the ISO (International Organisation of Standardization) protocol stack.

The OSI4 protocol adapter enables client/server conversation over a network using the ISO transport protocol of the OSI network architecture and Net8. This combination enables an Oracle application to communicate in a connection-oriented manner with remote Oracle databases through the ISO transport protocol (if the Oracle database is running on a host system that supports network communication using the ISO transport).

The application or client process initiates its OSI4 connection with the remote host process by specifying a OSI transport address also known as TSAP (Transport Service Access Point), which consists of the following elements:

In this address pair NSAP specifies a host and TSEL the communication endpoint. In order to standardize the TSAP address resolution, a HOST and SERVICE address entry pair are to be used. The BS2000 system requires the address pair

On other platforms these fields are optional for making a connection and will not get across the network. Therefore they must be mapped to the NSAP/TSEL address pair. The mapping must be specified in a PROTOCOL.ORA file.

Using the Oracle OSI4 Adapter

The OSI4 adapter allows TNS and its applications to integrate with the OSI transport architecture running the ISO communication protocol. The syntax for the OSI4 adapter connection is:

(ADDRESS=
(PROTOCOL=OSI4)
(NSAP=network_layer_address)
(TSEL=t-selector)
)

or

(ADDRESS=
(PROTOCOL=OSI4)
(HOST=bcam_hostname)
(SERVICE=string)
)

where:

PROTOCOL
specifies the specific adapter to be used. For OSI the value is "OSI4"

NSAP
Network layer address - at most 64 characters of Hex digits: [0-9],[A-F],[a-f]

TSEL
a string of Hex digits - at most 8 characters of Hex digits: [0-9],[A-F],[a-f]

HOST
BCAM hostname - at most 8 characters: [a-z],[A-Z], [0-9],#,@,$
The first character must not be a number or the $ sign

Note:

  • Lower case characters will be converted to upper case characters.

  • For more information on the BCAM hostname, please refer
    to the documentation that came with your BCAM software.

SERVICE
Transport service - at most 32 characters

Example of a PROTOCOL.ORA File

#
# File : PROTOCOL.ORA
# Usage: Net8
#
#
# my local NSAP address
#
osi4.nsap=490001002 #
# default partial address lookup
# i.e. here's where we look if we get (protocol=osi4)(partial=yes) and
# nothing else
#
osi4.partial=somename #
# default service map location
#
osi4.service_map=someothername #
# partial address list
#
local_lookup.somename=(address_list=
(address=(nsap=490001002)(tsel=8980))
(address=(nsap=490001002)(tsel=8981))
(address=(nsap=490001002)(tsel=8982))
(address=(nsap=490001002)(tsel=8983))
(address=(nsap=490001002)(tsel=8984))
(address=(nsap=490001002)(tsel=8985))
(address=(nsap=490001002)(tsel=8986))
(address=(nsap=490001002)(tsel=8987))
(address=(nsap=490001002)(tsel=8988))
(address=(nsap=490001002)(tsel=8989))
) #
# HOST/SERVICE mapping to NSAP/TSEL list
# Note that in this list, for each ADDRESS specified, all four atoms
# of HOST, SERVICE, NSAP and TSEL must be present
#
local_lookup.someothername=(address_list=
(address=(host=myhost)(service=ora8_8980)
(nsap=490001002)(tsel=8980))
(address=(host=myhost)(service=ora8_8981)
(nsap=490001002)(tsel=8981))
(address=(host=myhost)(service=ora8_8982)
(nsap=490001002)(tsel=8982))
(address=(host=myhost)(service=ora8_8983)
(nsap=490001002)(tsel=8983))
(address=(host=myhost)(service=ora8_8984)
(nsap=490001002)(tsel=8984))
(address=(host=myhost)(service=ora8_8985)
(nsap=490001002)(tsel=8985))
(address=(host=myhost)(service=ora8_8986)
(nsap=490001002)(tsel=8986))
(address=(host=myhost)(service=ora8_8987)
(nsap=490001002)(tsel=8987))
(address=(host=myhost)(service=ora8_8988)
(nsap=490001002)(tsel=8988))
(address=(host=myhost)(service=ora8_8989)
(nsap=490001002)(tsel=8989))
)

Here is an example how to estimate the number of partial addresses which must be defined in the protocol.ora file:

# addresses = maximal # of prespawned servers +
maximal # of dispatchers +
estimated # of bequeathed servers +
1

MTT Adapter

This section introduces Oracle Corporation's Memory Two Task (MTT) protocol adapter for interprocess calls on a local machine. It is used to map the functionality of MTT to Oracle's Tranparent Network Substrate (TNS).

Overview of MTT

On BS2000 machines, the MTT adapter is used for local interprocess communication. This protocol uses a shared memory pool for connection-oriented communication between pairs of processes on a local host.

The application or client process initiates its MTT 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 continous byte stream.

When you have to make a decision between MTT and IPC consider these aspects:

Using the MTT Adapter

The MTT adapter allows TNS and TNS applications to integrate with the MTT method on a local host. The syntax for the MTT adapter connection is:

(ADDRESS=
	   (PROTOCOL=MTT)
	   (KEY=alphanumeric))

where:

PROTOCOL
specifies the specific adapter to be used. For MTT, the value is "MTT".

KEY
specifies the listen endpoint, a string of at most 32 charcters. For building the KEY use the following character set: [a..z],[A..Z],[0..9],'.','-','_', and '$'.

Here is an example of an MTT ADDRESS that specifies a client on a local host:

(ADDRESS=
	   (PROTOCOL=MTT)
	   (KEY=ORA8.WORLD))

Bequeath Adapter

The Bequeath Adapter enables clients to retrieve information from the database without using the network listener. The Bequeath Adapter internally spawns a server process for each client application. In a sense, it does the same operation that a remote network listener does for your connection, yet locally.

The Bequeath Adapter could be your choice when you try to replace single-task mode of an application by two-task mode and may like to avoid running a network listener.

This may be especially important when single-task mode support is diminished or abandoned in the future. Therefore the use of the Bequeath Adapter has been made much simpler (see below).

Overview of the Bequeath Adapter

The Bequeath Adapter

Using the Bequeath Adapter

There are two methods of usage:

  1. The simple implicit method:
    Set the DEFAULT_CONNECTION parameter in the ORAENV file to no value, i.e. DEFAULT_CONNECTION=
    or outcomment this parameter
    * DEFAULT_CONNECTION=S:

  2. The explicit method by specifying an address (in TNSNAMES.ORA or as a DEFAULT_CONNECTION parameter) like this:

    (ADDRESS =
    (PROTOCOL = BEQ)
    (PROGRAM = ORATNS)
    (ARGV0 = ORATNSsid)
    (ARGS = '(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=BEQ)))')
    )


    Note:

    If the client is running under a different USERID than the Oracle instance you have to define the parameter BGJPAR in the client's ORAENV file:

    BGJPAR=PROCESSING-ADMISSION=*PAR(userid,account,'password'),
    JOB-CLASS=jobclass

    Please make sure that the client is allowed to start processes under the DBA userid.


Multi-threaded Server Architecture

The initialization parameters that control the MTS architecture are as follows:

For detailed information on the multi-threaded server architecture, see the chapter 9, "Configuring Multi-Threaded Server" in the Net8 Administrator's Guide.

The MTS 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 MTS or the dedicated server architecture. By default, the listener process uses the MTS 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. If you omit the USE_DEDICATED_SERVER parameter then the MTS architecture is used. The following is an example of a connect descriptor and a SQLNET.ORA parameter set so that the application will use the dedicated server architecture:

TNSNAMES.ORA:

   MADRID_FINANCE=(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=MADRID)
(PORT=1521))
(CONNECT_DATA=
(INSTANCE_NAME=PROD)))

SQLNET.ORA:

USE_DEDICATED_SERVER=ON

An application specifying:

SCOTT/TIGER@MADRID_FINANCE

as a logon string in which MADRID_FINANCE represents the service name, will connect to the database PROD on host MADRID and cooperate with a dedicated server.

In choosing whether to use the MTS or the dedicated server architecture, you need to consider the CPU overhead versus resource allocation (tasks, memory and so on). In a situation where many clients, that need to work only occasionally with the Oracle Server, then it would be best to use the MTS architecture, whereas, in a situation where just a few clients need to work with the Oracle Server 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 MTS dynamic tables to help you arrive at your decision:

For more information on these tables, see the Oracle8i Administrator's Guide.


Note:

If you want to use the Multi-Threaded Server Architecture please ensure that the INIT.ORA parameter INSTANCE_NAME is set:

INSTANCE_NAME=sid


Configuring the Network

Before a database server can receive connections from clients, clients must be configured with service names (easy to remember aliases for database addresses) that match the address preconfigured in each server machine's LISTENER.ORA file. These addresses are used by the client to connect to the network listener during a connection. During a connection, a client passes the system ID (SID) of the server to which it wants to connect.

The LISTENER.ORA file identifies and controls the behavior of the network listener that listen for the databases on the machine. This file includes network listener descriptors and addresses, the SIDs of the databases the listeners are listening for, and various control parameters.

Client configuration is accomplished by creating a list of service names and addresses of network destinations through a TNSNAMES.ORA client configuration file or an Oracle Names Server. A client (or a server that is part of a distributed database) needs this information to tell it where it can make connections.

Using the Local 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 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.

Using the Centralized Naming Method

Centralized Naming refers to the method of resolving a service name to a network address by using Oracle Names. Oracle Names uses Oracle Names Servers to store the names and addresses of all database services on a network. Connection requests are routed through an Oracle Names Server, which resolves the service name to a network address and returns that information to the client. For using the centralized naming make sure that "ONAMES" is listed in the client's configuration file parameter for naming adaptors 'names.directory_path'.

Centralized naming is most appropriate for large, complex networks (over 20 databases) that change frequently.

Configuration on the Server

  1. If you have decided for the central naming method you have to set up the Oracle Names Server's configuration file NAMES.ORA in which you specify the addresses of the Names Server, the domains, administration regions, and various control parameters used by the Names Server. For more information on the Oracle Names Server see the chapter Oracle Names in the Oracle Net8Administrator's Guide.

    Start the Oracle Names Server using the Oracle Names Control Utility NAMESCTL:

    CALL-PROCEDURE sid.P.ORAENV
    START-PROGRAM $ORACL817.NAMESCTL
    
    

    When the "enter options" prompt is displayed, press [ENTER] to get to the NAMESCTL prompt. Enter

    NAMESCTL> START
    
    
    

    to start the Oracle Names Server.

  2. Before starting the Listener, you have to set up the Listener's configuration file LISTENER.ORA. This file includes the addresses of the listeners on a server, the SIDs of the databases for which they listen, the prespawn parameters and various control parameters used by the Listener.

    On the BS2000 system you have the chance to define a seperate job-class for the servers of every instance. You do this by specifying the BGJPAR environment variable in your ORAENV file or by specifying the OSDS parameter within the SID_DESCRIPTION parameter in your LISTENER.ORA file. If OSDS is defined in the LISTENER.ORA, the value of this parameter will overpunch the ORAENV parameter value. If you start the Listener in a userid which is not the DBA userid, you can add the logon values to the BGJPAR or OSDS parameter. For example, the OSDS variable could have the following syntax:

    (OSDS="[PROCESSING-ADMISSION=*PAR(userid,account,'password')],
    JOB-CLASS=jobclass")

    The following is an example of how you use the OSDS parameter in your LISTENER.ORA file when you are describing the system identifiers of the database for whom the listener listens:

    SID_LIST_LISTENER = (SID_LIST =
    (SID_DESC =
    (SID_NAME = ORA8)
    (PRESPAWN_MAX = 10)
    (PRSPAWN_LIST =
    (PRESPAWN_DESC =
    (PROTOCOL = IPC)
    (POOLSIZE = 5)
    (TIMEOUT = 15)
    )
    (PRESPAWN_DESC =
    (PROTOCOL = TCP)
    (POOLSIZE = 5)
    (TIMEOUT = 15)
    )
    )
    (OSDS = "JOB-CLASS=JCBORA8")
    )
    )

    For more information see the chapter Configuring Network Services in the Oracle Net8 Administrator's Guide.

    Start the Listener using the Listener Control Utility LSNRCTL:

    CALL-PROCEDURE sid.P.ORAENV
    START-PROGRAM $ORACL817.LSNRCTL

    When the "enter options" prompt is displayed, press [ENTER] to get to the LSNRCTL prompt. Enter

    LSNRCTL> START <listener_name>
    
    

    to start the Listener.

  3. If you have decided to use a Oracle Connection Manager you have to set up the Oracle Connection Manager's configuration file CMAN.ORA in which you specify the addresses the Connection Manager is listening on, and various control parameters used by the Connection Manager. For more information on the Oracle Connection Manager see the chapter Oracle Connection Manager in the Oracle Net8 Administrator's Guide.

    Start the Oracle Connection Manager using the Oracle Connection Manager Control Utility CMCTL:

    CALL-PROCEDURE sid.P.ORAENV
    START-PROGRAM $ORACL817.CMCTL

    When the "enter options" prompt is displayed, press [ENTER] to get to the CMCTL prompt. Enter

    CMCTL> START
    
    

    to start the Oracle Connection Manager.

Configuration on the Client

Configuration of network clients involves adding or editing parameters in the client configuration file SQLNET.ORA and dependent on the used naming method the local naming configuration file TNSNAMES.ORA. For more information on configuring clients see the chapter Configuring Network Clients and the section Sample Configuration Files in the Oracle Net8 Administrator's Guide.

Testing the Configuration on the Client

After you have varified the network connections you can verify the connections to the desired Oracle databases by using the TNSPING utility:

CALL-PROCEDURE sid.P.ORAENV
START-PROGRAM $ORACL817.TNSPING

When the "enter options" prompt is displayed, enter the alias for the database service which you have specified in your TNSNAMES.ORA or in the Oracle Names Server. If everything works fine a message similar to the following will be returned to the user:

TNS Ping Utility for BS2000:
c) Copyright 1997 Oracle Corporation. All rights reserved.
Attempting to contact (ADDRESS=(PROTOCOL=TCP)(HOST=orahost)(PORT=1521))
OK (1350 msec)

For more information see the chapter Using TNSPING in the Oracle Net8 Administrator's Guide.

Migrate to Net8

Net8 is the network component of Oracle8i Release 3. Net8 in conjunction with the BS2000 sockets gains the benefits of a common waiting point for the IPC, TCP/IP and OSI4 protocol.

Net8 using the TCP/IP protocol is backward compatible with SQL*Net version 2. This means that Net8 clients can transparently connect to an Oracle7 database. It also means that existing SQL*Net version 2 clients can connect to an Oracle8i Release 3 database.


Note:

The MTT-adapter v8.1.7 is not compatible to the MTT adapter of version 8.0.4 and older.


Compatibility Issues

Net8 v8.1.7 is compatible to SQL*Net version 2 except the MTT adapter which is not compatible to the releases prior than v8.1.5.

TCP/IP

The Net8 v8.1.7 TCP/IP adapter is not backward comptible to Sockets v1.x.

MTT

The MTT adapter is not compatible to releases prior than v8.1.5.

Troubleshooting Net8

  1. Listener takes a lot of CPU time

    • Check your listener configuration file if the listener should use the MTT protocol for listening and at least one of the other protocols.

    • Declare a seperate listener for the MTT protocol.

  2. Listener could not open the log file.

    • Check if the listener log file (e.g. 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.

  3. A client reports ORA-12545

    • Check your naming service if the hostname returned by the listener is well known in your TCP/IP network.

    • If you do not want to use the BCAM hostname of your machine in your TCP/IP network, define a sockets-host-name as described in your BCAM documentation and register this name in your name service.

  4. A client reports ORA-12535

    • If you use the IPC or OSI4 protocol, please check the Connection Timeout parameter of BCAM (use the BCSHOW command). This parameter should be set to at least 600 seconds.

  5. A client reports ORA-03114

    • Please check the log files of the server (NETWORK.LOG.SERVER.LOG) and the client (CLIENT.LOG) for BCAM return codes. If the server reports

      BCAM-RC 0040002C
      
      

      and the client reports

      BCAM-RC 04010024
      
      

      then increase the BCAM-LETTER-TIME parameter.


Go to previous page Go to next page
Oracle
Copyright © 2001 Oracle Corporation.

All Rights Reserved.
Go To Table Of Contents
Contents
Go To Index
Index