D
Native Naming Adapters

This appendix provides details about the configuration required by Native Naming Adapters. If you are using an external naming service in your network and want the Oracle clients and servers in the network to use the same service, follow the instructions for the service you use. The following Native Naming Adapters are discussed:

Section D.1, "NIS"

Section D.2, "NDS"

Note::

For information about the CDS naming adapter, which is part of the DCE Integration component of Oracle Advanced Networking Option, refer to the Oracle Advanced Networking Option Administrator's Guide.

D.1 NIS

Organizations and corporations already using Network Information Service (NIS) as part of their systems infrastructure have the option to store Oracle service names and addresses in NIS, using the NIS Native Naming Adapter.

D.1.1 System Requirements

The NIS Naming Adapter requires SQL*Net 2.2 or greater.

D.1.2 How the NIS Naming Adapter Interacts with SQL*Net and Oracle

When a user gives a command such as

	sqlplus scott/tiger@payroll

(where "payroll" is an Oracle service name) the NIS Naming Adapter on the node running the client program (or server acting as a client program) contacts an NIS server located somewhere in the network, and passes the service name to the NIS server. The NIS server resolves the service name into a SQL*Net address and returns this address to the client program (or server acting as a client program). The client program then uses this address to connect to the Oracle database.

Note:

The service name should be the same as the global database name defined in the server's INIT.ORA file.

D.1.3 Oracle Database Service Names are Stored in a Separate NIS Map

A machine that acts as an NIS server runs a program called ypserv, which handles name requests. ypserv stores different types of data in special files called "maps". For example, passwords are stored in a map called passwd.byname. Oracle database service names are stored in a map called tnsnames.

Note:

The tnsnames map is called a.smd in releases previous to SQL*Net 2.2.2.

When a user issues a command like the one in the previous section, the NIS Naming Adapter uses an RPC call to contact the ypserv program and passes the Oracle service name "payroll" and the name of the map-tnsnames. The ypserv program looks in the tnsnames map for the name "payroll" and its corresponding value, which is the address for the service name. The address is returned to the client, and the client program (or server acting as a client program) uses this address to contact the database server.

D.1.4 Configuring NIS Servers to Support the NIS Adapter

Before configuring servers to support the NIS Naming Adapter, make sure that NIS is configured and running on the NIS servers that need to resolve Oracle database service names. Consult your NIS documentation for specifics.

D.1.4.1 Add the tnsnames Map to the Existing Set of NIS Maps

To add the tnsnames map to the existing set of NIS maps:

Use the Oracle Net8 Assistant to create a TNSNAMES.ORA file.

Note:

Keep a copy of the TNSNAMES.ORA file, preferably in your $TNS_ADMIN or $ORACLE_HOME/network/admin directory. You may need to use this file again later to load Oracle service names into the NIS map.

Convert the contents of the TNSNAMES.ORA file to tnsnames using the tns2nis program.

Note:

The tns2nis program is supplied with the NIS adapter on the Oracle Installer tape or disk.

For example, run tns2nis on the command line with one argument:
```
		tns2nis tnsnames.ora
```
tns2nis reads the NATIVE.ORA file from the current directory. (If TNSNAMES.ORA is not located in the current directory, you can use a full pathname to specify its location-for example, /etc/native.ora or $ORACLE_HOME/network/admin/tnsnames.ora).

tnsnames is then written into the current working directory.
Copy tnsnames to the NIS server, if it is not already there.
Install the tnsnames map using makedbm, which is an NIS program. Refer to your NIS documentation for more information.

Note:

This step should be performed by the person in charge of NIS administration.

makedbm converts tnsnames to two files that the NIS server can read. The location of these files is platform-specific. Refer to your platform-specific documentation for details.

For example, as "root", a command of the form:
```
	# makedbm tnsnames /var/yp/`domainname`/tnsnames 
```
generates and installs the tnsnames map in the appropriate directory on the SunOS.

D.1.4.2 Verifying that the tnsnames Map Has Been Properly Installed

You can test the NIS server to see if the map has been installed properly by typing a command with the format:

ypmatch global_database_name tnsnames

For example, you might enter:

ypmatch payroll.world tnsnames

This returns the length of the address (in characters) followed by the address; for example:

	99 (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)

  (HOST = garlic)(PORT = 1999)))

  (CONNECT_DATA=(SID=DIRPROD)))

D.2 NDS

The NDS Naming Adapter allows you to use native NDS naming conventions to connect to an Oracle database on a Novell NDS-enabled network. After the NDS Naming Adapter has been installed on clients and servers, users can type

username/password@service_name

The NDS Naming Adapter provides network users with the following benefits:

Allows clients to use simple NDS names (partial or full) when connecting to a database.
Simplifies the maintenance of the TNS addresses; one change will affect all clients using the NDS Naming Adapter.
Reduces network traffic by eliminating the need for the listener to advertise.

D.2.1 How the NDS Adapter Interacts with SQL*Net and Oracle

This section provides a brief discussion of how the NDS Naming Adapter interacts with SQL*Net and an Oracle Server.

D.2.1.1 What the Client Does

The NDS Naming Adapter resides on the client workstation and translates the NDS object name into a TNS address. The client code gets attributes from the NDS tree for the NDS object whose name matches the Oracle service name. This name can be a full name or a partial name. If it is a partial name, it will be qualified with respect to the current name context. Refer to "Optional Configuration File Parameter for the Client" in this chapter for information on fully-qualified and partially-qualified NDS names.

D.2.1.2 What the Server Does

There are three aspects to the server-side NDS Naming Adapter: schema extension, SAP disabling, and listener address storage.

D.2.1.2.1 Schema Extension

During the Oracle installation process on a NetWare 4 server the NDS schema is extended to include an object class called "ORACLE:DBInstance". For the NDS Naming Adapter to function, this class will need an attribute called "ORACLE:TNSAddress". If the class does not exist, it is created and will include the TNSAddress attribute. If the class exists but the TNSAddress attribute does not, the class will be modified. The NLM that performs this during installation is called ORASCHEM.NLM.

D.2.1.2.2 SAP (Service Address Protocol) Disabling

The Oracle SPX Protocol Adapter for NetWare looks for a value in CONFIG.ORA called "ORACLE_SAP". The value of this parameter is ON or OFF. If this parameter is not specified, the default is ON. This has performance implications for SPX networks. When ORACLE_SAP is ON, the SQL*Net listener advertises its address using SAP (Service Advertising Protocol). When ORACLE_SAP is set to OFF, the SQL*Net listener relies on NDS to deliver information to its clients.

If your network consists entirely of NDS enabled clients (that is, clients using NetWare 4 and above), you will get better network performance if you edit the CONFIG.ORA file to set ORACLE_SAP to OFF.

D.2.1.2.3 How Oracle Service Names and Addresses are Stored in NDS

When the network listener is started, it stores its address in the NDS database by locating the Oracle database instance that resides on its server.

Note:

An NDS object for the Oracle database must have already been created.

At that point, the address(es) is (are) accessible to the client from the NDS database

D.2.2 System Requirements

The NDS Naming Adapter requires SQL*Net 2.2 or later and Oracle 7.2 or later. It can be used with any client running Novell libraries, but requires NetWare 4.1 or later on the server.

D.2.3 Optional Configuration Parameters for Clients and Servers

This section describes optional parameters for the NDS Naming Adapter.

D.2.3.1 Optional Configuration Parameter for the Client

There is one optional parameter for the client. It specifies the default name context in which to look for the name to be resolved. The parameter is:

	NATIVE_NAMES.NDS.NAME_CONTEXT





Note:



You must add this parameter manually to the SQLNET.ORA file. It cannot be created using Oracle Net8 Assistant.

For example, if the name of the database object is "Payroll.Finance.Oracle" and the SQLNET.ORA parameter is

	NATIVE_NAMES.NDS.NAME_CONTEXT=Finance.Oracle

then the name "Payroll" will be qualified to ".Payroll.Finance.Oracle". This is an example of a typeless name.

Note:

The leading dot designates this as a full NDS name. If you want to override the name context parameter in SQLNET.ORA, then you can specify the full NDS name in the connect string by using a leading dot.

Additionally, names can be specified as typed names. To specify a typed name, enter a parameter and value in SQLNET.ORA like the following:

NATIVE_NAMES.NDS.NAME_CONTEXT=OU=Finance.O=Oracle

This line will be parsed to produce the typed name CN=Payroll.OU=Finance.O=Oracle.

This parameter works similarly to the NET.CFG parameter "name context". The name context in SQLNET.ORA will override the entry in NET.CFG. If the SQLNET.ORA parameter is not specified, the NET.CFG parameter will be used. If no name context is specified in either file, it defaults to [root]. See the Novell client documentation for more information on the NET.CFG parameters.

Note:

The default name context specified in SQLNET.ORA cannot contain a leading dot. This will result in an NDS error code of -309 (ERR_EXPECTED_IDENTIFIER):

The parameter being parsed is not typed.

D.2.3.2 Optional Configuration Parameter for the Server Configuration

The network listener running on a NetWare server looks at the following optional parameter in the CONFIG.ORA file, which is located in the ORACLE_HOME/NLM directory:

	ORACLE_SAP=[OFF|ON]

ORACLE_SAP can be set to either ON or OFF. When ORACLE_SAP is ON, the SQL*Net listener advertises its address using SAP (Service Advertising Protocol). When ORACLE_SAP is set to OFF, the SQL*Net listener relies on NDS to deliver information to its clients. If not specified in CONFIG.ORA, ORACLE_SAP defaults to "ON".

D.2.3.2.1 Reduce Network Traffic by Setting ORACLE_SAP to OFF

To reduce network traffic on a network where all clients use NDS, use

	ORACLE_SAP=OFF

D.2.4 Known Limitations

Following are some known limitations when using the NDS Naming Adapter:

The TNS address stored in the NDS database cannot be more than 2048 characters in length.
You cannot use more than one listener per database instance. If you do, the last listener to start will overwrite any other TNS address stored in the database object.
If SID support is enabled on the server, you should not use a NULL SID for any of the database instances. If a NULL SID is used for one of the instances, you cannot connect to it using SQL*Net version 2 or Net8.
If SID support is not enabled, the last SID specified in the listener's SID_LIST will be the one used. In this case, the SID is transparent to the user and database. The user does not see it and the database ignores it.
Note:

SID support is controlled by the following parameter in the CONFIG.ORA file:

NW_ENABLE_SID_SUPPORT=[TRUE|FALSE]

D Native Naming Adapters