A Step by Step Setup of Oracle Names Server

by Rampant author Daniel Liu

Paper previously presented by Daniel Liu at Oracle Open World 2000.

Introduction to Oracle Names Server

SQL*Net enables services and their applications to reside on different computers and communicate as peer applications. Network information is stored in multiple places and in multiple formats. The main function of SQL*Net is to establish network sessions and transfer data between a client machine and a server or between two servers. There are different resolution methods used by SQL*Net to resolve a name and help a client to locate a database. The most common practice is storing net service name in a local naming configuration file called tnsnames.ora. But this method becomes a maintenance nightmare for the network and database administrators in a dynamic and multi-platform environment.

Oracle Names provides a mechanism to resolve service names by storing database connecting information in a central location. This replaces the need of having connecting information installed on each individual client machine. This solution reduces the cost of maintenance by 50-95% depending on the number of databases and the topology of the network.

This paper discusses the required steps to configure Oracle Names Servers in SQL*Net. It offers an introduction to the basic concepts of SQL*Net and step-by-step instructions for configuring listener.ora, sqlnet.ora, tnsnames.ora and names.ora files. This paper also shows how to use LSNRCTL and NAMESCTL utilities to setup Oracle Listener and Names Server in both Unix and Windows environment.

SQL*Net Basics

SQL*Net Client - SQL*Net Client enables client connections to databases across a network. A client-side application sends a request to SQL*Net to be transported across the network to the server.

SQL*Net Server - SQL*Net Server enables the listener, through a protocol, to accept connections from client application on the network.

SQL*Net Protocols - Oracle supports the following protocols:

TCP/IP - tThe de facto standard Ethernet protocol used for client/server communication over a network. This protocol is used in Unix and NT environments.

TCP/IP with SSL - Oracle Advanced Security is required in order to use TCP/IP with Secure Sockets Layer. SSL stores authentication data in an Oracle Wallet. When the client initiates a SQL*Net connection to the server, SSL performs a handshake between the two using the certificate or the private key.

SPX/IPX - the Sequenced Packet Exchange is predominantly used in Novell NetWare environments.

Named Pipes - is a high-level interface providing inter-process communications between clients and server and is specifically designed for PC LAN environments.

LU6.2 - the Logical Unit Type 6.2 protocol is part of the IBM Advanced Program-to-Program Communication architecture.

Bequeath - enables clients that exist on the same machine as the server to retrieve information from the database without using the listener.

The tnsnames.ors File

Tnsnames.ora is the configuration file resides on the client's ORACLE_HOME/network/admin/ directory. This file provides information on the database service name, the network route to the service, including the location of the listener through a protocol address.

Figure 1

Listener

The listener is a separate process that resides on the server. It receives incoming client connection requests and manages the traffic of these requests to the server.

A listener is configured with one or more listening protocol address and service information about the destination service. Service information may or may not be configured in the listener.ora file.

Oracle7 or Oracle8 release 8.0 requires service configuration in the listener.ora file. Oracle release 8.1 has a feature called service registration, which automatically registers information with the listener and does not require configuration in the listener.ora file.

The listener has a default name of LISTENER and is configured to listen on the following default protocol addresses:

• TCP/IP protocol on port 1521
• IPC protocol - for external procedures
  

A listener can listen for one or more databases either on the same system or on different systems. One listener can also listen for different versions of databases.
In practice, it is always a good idea to have at least one listener for each version of database on each system and name the listener to some meaningful name instead of the default.

Anytime the listener.ora is modified, the listener must be stopped and re-started with the LSNRCTL utility.

If you expect the listener to handle large volumes of connection requests, you may specify a queue for the process. This enables the listener to dynamically handle larger numbers of concurrent connection requests (refer to figure 2).

dallaslsnr =
(address_list =
        (address =
                (protocol = ipc)
                (key = db1)
        )
       (address =
                (protocol = tcp)
                (host = dallas.company.com)
                (port = 1521)
                (queuesize=20)
        )
)
sid_list_dallaslsnr=
    (sid_list =
            (sid_desc =
                    (global_dbname = db1.company.com)
                    (sid_name = db1)
                    (oracle_home = c:\oracle\oracle81)
            )
     )
names.preferred_servers =
        (address_list =
                (address =
                        (protocol = tcp)
                        (host = chicago)
                        (port = 1575)
                 )
        )

Figure 2

Making the Connection

When a user connects to a database service from across the network, a connect descriptor containing network information about the destination service is passed to the listener.

One method is to create a lengthy connect string as follow:

connect scott/tiger@(description=(address=(portocol=tcp)(host=dallas.company.com)(port=1521))
(connect_data=(service_name=db1.company.com)))

Or we can use a connect identifier to avoid a lengthy connect string:

connect scott/tiger@db1

A connect descriptor can be mapped to a connect identifier. This information is stored either in a local configuration file (tnsnames.ora) on each client machine or in a central system such as Oracle Names.

During a connection request, the client contacts a naming method to resolve a connect identifier to a connect descriptor. The client forwards the request to the listener address specified in the connect descriptor.

The listener, through a protocol, accepts the client connection. It compares the client information with the information it has received from the database, as well as information it has stored in its own configuration file, listener.ora. If the information matches, a connection is granted.

Oracle Names

Oracle Names is an Oracle-specific name service that maintains a central store of service address. This replaces the need of having connecting information installed on each individual client machine. Any database changes on the server side only require changes to the Oracle Names Server. This significantly reduces work involved in maintaining a distributed Oracle environment.

Figure 3

Step by Step Setup of Oracle Names Server Using Enhanced (dynamic) Discovery Option

There are two main types of Oracle Names configuration:

1. Storing TNS connect information in a repository within an Oracle8 database.

2. Enhanced (Dynamic) Discovery Option allows dynamic registration of services.

EDO does not require a database to store service names. Each Names Server automatically replicates its data to all other well-known Names Servers. Listeners will automatically register themselves with well-known Names Servers and clients can find them without configuration.
For simple illustration, a hypothetical network environment is given (refer to table1 and figure 3).

The following shows how to set up Oracle Names Servers in this given environment:

Table 1

1. EDO is used in our example.

2. There are four servers, each named after a city: Chicago, Dallas, New York and Portland.

3. All four servers are in a single domain network called "company.com"

4. Each of the four servers belongs to a different platform.

5. Server "Chicago" and "Dallas" will host Oracle Names Server oranamesrvr0 and oranamesrvr1 respectively.

6. Each server except server "Chicago" hosts one or more database instances.

7. Servers "NewYork" and "Dallas" host version 8.1.5 databases only.

8. Server "Portland" hosts both version 7.3.4 and 8.1.5 databases.

9. There are two listeners on server "Portland": listener "pd8lsnr" for version 8 databases and listener "pd7lsnr" for version 7 databases.

Note: A listener can listen for incoming client connection requests for one or more instances on the same machine or instances on different machines. The default listener name is LISTENER. A better way to name the listener is servernamelsnr. Another good practice is to have at least one listener per server. If multiple versions of database are running on the same server, we should have at least one listener for each version of database.

10. The default port number for Names Server is 1575.

11. The default port number for listener is 1521. But we can always choose a different port number other than the default. For load balance, we may have two or more listener ports for a listener.

The following six steps show how to set up Oracle Names Servers in the "company.com" network domain:

Step #1: The Preparation

1. Install the SQL*Net products.
If you have a typical Oralce8i Enterprise Edition installed on your server, SQL*Net products are probably already installed. If you only want to run Names Server on a machine, SQL*Net is the only product needed. In our case, we need to install SQL*Net product on server "Chicago".

2. Make the Names Server Well Known.
A Well Known Names Server is one that is 'known' to all clients and servers on the network. In our case, the servers "Chicago" and "Dallas" must be defined as a Well-Known Names Servers. This can be done (refer to figure 4, example of host file) by adding the Well Known Names Server name to the Domain Name Server or in the host files. The Well Known Names Server names are: oranamesrvr0, oranamesrvr1, oranamesrvr2, oranamesrvr3 and oranamesrvr4. All client machines must be able to ping the Well Known Names Server.

Figure 4

3. Prepare the configuration file directory (refer to figure 5).

Figure 5

In general, all the configuration files store in the $ORACLE_HOME/network/admin directory. If you have multiple versions of database, you would certainly have different $ORACLE_HOME environment. This means more than one set of configuration files need to be administrated and maintained. To avoid this, you can set a $TNS_ADMIN directory where you will store the configuration files. The system will look in the $TNS_ADMIN directory for those files before the $ORACLE_HOME/network/admin directory. Here is the command to setup configuration directory:

The following chart documents the locations of configuration files:

Platform	$ORACLE_HOME/network/admin	$TNS_ADMIN
Unix	/oracle/product/8.1.5/network/admin/listener.ora	/var/opt/oracle/listener.ora
	/oracle/product/8.1.5/network/admin/tnsnames.ora	/var/opt/oracle/tnsnames.ora
	/oracle/product/8.1.5/network/admin/sqlnet.ora	/var/opt/oracle/ sqlnet.ora
	/oracle/product/8.1.5/network/admin/ names.ora	/var/opt/names.ora
Windows	C:\oracle\ora81\network\admin\listener.ora	C:\oracle\listener.ora
	C:\oracle\ora81\network\admin\ tnsnames.ora	C:\oracle\ tnsnames.ora
	C:\oracle\ora81\network\admin\ sqlnet.ora	C:\oracle\ sqlnet.ora
	C:\oracle\ora81\network\admin\ names.ora	C:\oracle\names.ora

Table 2

Step #2: Creating the First Names Server

1. Prepare the names.ora configuration file.

Your can either use SQL*Net Assistant to create a names.ora file or create it manually. Officially, Oracle only supports the use of SQL*Net Assistant . The names.ora file should contain at least the following settings (refer to (Figure 1):

• Oracle Names Server name
• Oracle Names Server listening protocol address

names.default_domain = company.com
names.server_name = oranamesrvr0.company.com
names.preferred_servers =
        (address_list=        
                (address=        (protocol = tcp)
                                        (host= chicago)
                                        (port = 1575)
                )
        )

Step #3: Registering the Listeners

• Use_plug_and_play - tells the listener to register with the Names Server.
• Names.preferred_servers - tells the listener which Names Server register its service information with.

Use_plug_and_play_nylsnr = on
nylsnr =
(address_list =
        (address =
                (protocol = ipc)
                (key = db2)
        )
        (address =
                (protocol = ipc)
                (key = db3)
        )
        (address =
                (protocol = tcp)
                (host = newyork.company.com)
                (port = 1800)
        )
        (address =
                (protocol = tcp)
                (host = newyork.company.com)
                (port = 1805)
        )
)
sid_list_nylsnr=
    (sid_list =
            (sid_desc =
                    (global_dbname = db2.company.com)
                    (sid_name = db2)
                    (oracle_home = /oracle/product/7.3.4)
            )
            (sid_desc =
                    (global_dbname = db3.company.com)
                    (sid_name = db3)
                    (oracle_home = /oracle/product/8.1.5)
            )
    )
names.preferred_servers =
        (address_list =
                (address =
                        (protocol = tcp)
                        (host = chicago)
                        (port = 1575)
                 )
        )

• NAMESCTL> query db2

  Step #4: Setting Up a Second Names Server

names.default_domain = company.com
names.server_name = oranamesrvr1.company.com
names.preferred_servers =
        (address_list=        
                (address=        (protocol = tcp)
                                        (host= dallas)
                                        (port = 1575)
                )
        )

NAMESCTL> query db4
Total response time:	0 seconds
Response status:		normal, successful completion
Authoritative answer:	yes
Number of answers:	0
TTL:                   	1 day

NAMESCTL> query db4
Total response time: 	0 seconds
Response status: 	NNC-00406: name "db4.company.com" does not exist
Authoritative answer: 	yes
Number of answers: 	0
TTL:                   	1 day

• Go to the first Names Server, dump the service address information to a tnsnames.ora file.
  Note: Always keep a good copy of tnsnames.ora file. Whenever there are changes in service information, make sure you dump a good tnsnames.ora file. This is very important for Names Server recovery. (more information on step #6: Maintaining the Names Server).
  NAMESCTL> dump_tnsnames

• Transfer the file to the second Names Sever.
  % ftp chicago.company.com
  ftp> get tnsnames.ora
  
  
• Reload the service address information from the tnsnames.ora file the second Names Server.
  NAMESCTL> load_tnsnames

  Step #5: Setting Up the Client Machine
  

Once Oracle Names Servers are up and running, you need to set up your client machines.

1. Install SQL*Net client and Oracle8 Names Servers products.

2. Create a list of Oracle Names Servers to contact, using one of the following methods:

• Create a static list of preferred Oracle Names Server in the sqlnet.ora file.
  The onames in the names.directory_path entry tells the client to connect to the Names Server first. Here is the sequence a client makes contact. It will first make contact to Names Server oranamesrvr0. If oranamesrvr0 is down, then it will make contact to oranamesrvr1. If both Names Servers are down, then it will look up in its own tnsnames.ora files for connecting information. For this reason, you may still want to keep your local tnsname.ora file.

names.directory_path = (onames,tnsnames)
names.default_domain = company.com
names.preferred_servers =
	(address_list=
		(address=	
			(protocol=tcp)
			(host=oranamesrvr0.company.com)
			(port=1575)
		)		
		(address=	
			(protocol=tcp)
			(host=oranamesrvr1.company.com)
			(port=1575)
		)
	)

Figure 12 (sqlnet.ora)

• Discover Oracle Names Server by dynamically creating a sdns.ora file. Client machines read this file to find the addresses of oracle Names Servers to contact. You can use either SQL*Net Assistant or the NAMESCTL utility to generate the sdns.ora file.
  

  Here is an example how to use NAMESCTL utility to generate sdns.ora file and what this file contains:
  NAMESCTL> ns_order

Figure 13 (sdns.ora)

3. A client machine may not necessarily be your Windows PC. It could be one database server requesting service from another database server. SQL*Net software may already be installed on your server, but you still need to go through step 2 above. The Oracle Universal Installer does not install the $ORACLE_HOME/network/names directory on Unix platforms. This directory is necessary for successful configuration. If it does not exist, create it manually.

Step #6: Maintaining the Names Server

Now you have everything setup, you are ready to make connection. Off course, we are not living in a perfect world. Names Server may fail over sometimes. So here are some of the maintenance tips:

1. If one of the Names Servers is down, just restart this Names Server. It will pick up connection information from the other Names Server. NAMESCTL> start oranamesrvr0

2. If both of your Names Server are down, restart both of the Names Server, then using one of the following methods: · Reload all the connecting information from your tnsnames.ora file. NAMESCTL> load_tnsnames · Shutdown all your listeners and restart all your listeners. So database connection information can be registered with the Names Server. LSNRCTL> start|stop [listenr_name]

3. If a listener is down, all you need to do is restart it.

4. If you make change in your listener.ora file, you need to shutdown the listener and restart it. This will register the new information with the Names Server.

5. To check the status of the listener and Names Server, use one of the following two methods:

• From SQL*Net utilities: NAMESCTL> status oranamesrvr0 LSNRCTL> status dallaslsnr
• From Unix:

Figure 14

• From NT, check NT Services

6. If you have trouble starting a Names Server, you may do the following:

• Go to $ORACLE_HOME/network/admin/names directory
• Delete all the checkpoint files (ckcfg.ora, ckpcch.ora and ckpreg.ora)
• Restart the Names Server
• Repeat number two above

7. If you want to have a more maintenance free environment, use the following script. The script is for the Unix environment. You can modify accordingly to fit your Windows environment.

• Setup a cron job to run lsnrcheck script every ten minutes.

Figure 15 (cron job)

• This scirpt will restart listener and Names Server if they fail.

Figure 15 (lsnrcheck)

Conclusion

SQL*Net support several categories of naming methods. Oracle Names is an Oracle-specific name service that maintains a central store of service addresses. It provides major benefits over local naming method (tnsnames.ora). The author covers the basic concepts of SQL*Net. By following the steps given in this paper, you should have your Names Server running in no time.

References

Oracle Names Administrator's Guide. Release 2.0;
SQL*Net Administrator's Guide. Release 8.1.6;
Oracle Metalink and support papers numbers:
Note: 45596.1, Configuring a Simple v2.0 Dynamic Discovery Names Server;
Note: 60660.1, Configuration of Oracle Names Dynamic Discovery Option v8.xx;
Note: 73065.1, Step by Step Setup of Oracle Names v8.0.