13
DCE and Non-DCE Interoperability

This chapter describes how clients outside DCE can connect to Oracle servers in DCE and how TNSNAMES.ORA can be used for name lookup when CDS is accessible.

The following topics are covered:

13.1 Connecting Clients Outside DCE to Oracle Servers in DCE

Clients without access to DCE and CDS can still connect to Oracle servers in DCE using TCP/IP or some other protocol if a listener is configured to do this. If a listener has been configured in LISTENER.ORA on the server (see the sample LISTENER.ORA in the next section), non-DCE clients can use normal Oracle and Net8 procedures to connect to an Oracle server in DCE.

Note:

In this case DCE security would not be available to clients. Also, service names would be located and resolved to network addresses in a TNSNAMES.ORA file on the client, not using the CDS name server. See Section 13.2.1, "LISTENER.ORA" for a sample file. Also see Section 13.2.2, "TNSNAMES.ORA".

Following are samples of LISTENER.ORA and TNSNAMES.ORA files as they would need to be configured if a client from outside of DCE wanted to connect to Oracle database servers in a DCE environment.

13.2 Sample Parameter Files

At least two Oracle parameter files are needed for successful client/server communications. Create and modify these files using you favorite text editor. The files are as follows:

13.2.1 LISTENER.ORA

This file resides on the listener node. It defines listener characteristics and the addresses at which the listener listens.

In the following example, each element is laid out on a separate line, so it is easy to see the file's structure. This is the recommended format. If you must edit a LISTENER.ORA file by hand, you do not have to put each element on a separate line. Be careful, though, to include all the appropriate parentheses and to indent if you must continue an element onto the next line.

This example assumes the UNIX operating system and the TCP/IP protocol for one listener, and the DCE protocol for another listener. A single listener may have multiple addresses too. For example, instead of having two separate listeners for different database instances on a server node, you could have one listener for both, listening on both TCP/IP and on DCE. However, performance will be better with separate listeners.

LSNR_TCP=
      (ADDRESS_LIST=
          (ADDRESS=
                 (PROTOCOL=IPC)
                 (KEY=DB1)
          )
          (ADDRESS=
                 (PROTOCOL=tcp)
                 (HOST=rose)
                 (PORT=1521)
          ))

  SID_LIST_LSNR_TCP=
         (SID_DESC=
                (SID_NAME=ORASID)
                (ORACLE_HOME=/usr/jprod/oracle7)
         )
LSNR_DCE=
  (ADDRESS=
     (PROTOCOL=DCE)
     (SERVER_PRINCIPAL=oracle)
     (CELL_NAME=cell1)
     (SERVICE=dce_svc))
   SID_LIST_LSNR_DCE=
     (SID_DESC=
       (SID_NAME=ORASID)
       (ORACLE_HOME=/usr/prod/oracle8))

#For all listeners, the following parameters list sample
#default values.

PASSWORDS_LISTENER=
STARTUP_WAIT_TIME_LISTENER=0
CONNECT_TIMEOUT_LISTENER=10
TRACE_LEVEL_LISTENER=OFF
TRACE_DIRECTORY_LISTENER=/usr/prod/oracle7/neatwork/trace
TRACE File_LISTENER=listener.trc
LOG_DIRECTORY_LISTENER=/usr/prod/oracle7/network/log
LOG_FILE_LISTENER=listener.log

13.2.2 TNSNAMES.ORA

This file resides on both the client and the server nodes. It provides a list of the service names and addresses of all services on the network.

The following TNSNAMES.ORA file maps the service name ORATCP to the connect descriptor that includes a TCP/IP address and the service name ORADCE to a connect descriptor that includes a DCE address.

ORATCP = (DESCRIPTION=
          (ADDRESS=
            (PROTOCOL=TCP)
            (HOST=rose)
            (PORT=1521)
           )
           (CONNECT_DATA=
             (SID=DB1)
           )
          )
ORADCE=(DESCRIPTION=
         (ADDRESS=
           (PROTOCOL=DCE)
           (SERVER_PRINCIPAL=oracle)
           (CELL_NAME=cell1)
           (SERVICE=dce_svc)
          )
          (CONNECT_DATA=
                 (SID=ORASID)
          )
          )

A user who wished to access the DB1 database would use ORATCP to identify the appropriate connect descriptor. For example:

SQLPLUS SCOTT/TIGER@ORATCP

13.3 Using TNSNAMES.ORA for Name Lookup When CDS is Inaccessible

Typically, names are resolved into network addresses by CDS. Though the main purpose (in the context of Native Naming adapters) of TNSNAMES.ORA is to load Oracle service names and network addresses into CDS, it could be used temporarily as a backup name resolution service if CDS is inaccessible.

13.3.1 SQL*Net Release 2.2 and Earlier

To use TNSNAMES.ORA for name lookup and resolution, remove (or comment out) the "native name" parameters from SQLNET.ORA on the client. To comment out the lines, add a # at the beginning of each line. For example:

#native_names.use_native=true
#native_names.directory_path=(dce)

13.3.2 SQL*Net Release 2.3 and Net8

You can use TNSNAMES.ORA for name lookup and resolution when DCE CDS is unavailable if you have tnsnames listed as a value for the names.directory_path parameter in the SQLNET.ORA file on the client. For example:

names.directory_path=(dce, tnsnames)

This parameter enables you to list more than one names resolution method. The methods are tried in order. In this example, dce is attempted first. If it is unsuccessful, tnsnames is tried next.

13DCE and Non-DCE Interoperability