CHAPTER 14. DCE and Non-DCE Interoperability

Clients Outside DCE Can Still Connect to Oracle Servers in DCE
Sample Parameter Files
Using TNSNAMES.ORA for Name Lookup When CDS is Inaccessible

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 inaccessible.

Clients Outside DCE Can Still Connect 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 SQL*Net 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 "Sample LISTENER.ORA File" . for a sample file. Also see "TNSNAMES.ORA Can be Used for Name Lookup when CDS is Inaccessible" on page 14 - 5.

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.

Sample Parameter Files

At least three Oracle parameter files are needed for successful client/server communications. You create these files using Oracle Network Manager. LISTENER.ORA resides on the listener node; it defines listener characteristics and the addresses at which the listener listens. TNSNAMES.ORA and SQLNET.ORA reside on client and server nodes. TNSNAMES.ORA provides a list of the service names and addresses of all services on the network. SQLNET.ORA defines client characteristics.

Sample LISTENER.ORA File

In this example, each element is laid out on a separate line, so that it is easy to see the file's structure. This is the recommended format. Network Manager does this for you automatically. 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.

The following 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/prod/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/oracle7))

#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/network/trace
TRACE FILE_LISTENER=listener.trc
LOG_DIRECTORY_LISTENER=/usr/prod/oracle7/network/log
LOG_FILE_LISTENER=listener.log

Sample TNSNAMES.ORA File

The following TNSNAMES.ORA entry 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

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

**In SQL*Net Release 2.2 and Earlier**

To use TNSNAMES.ORA for name lookup and resolution, remove (or comment out) the "native names" 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)

**In SQL*Net Release 2.3 and Later**

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 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.

Prev Next

Library

Product

Contents

Index