Setting Up and Running Oracle Names with the Dynamic Discovery Option
This chapter provides several scenarios that show how to set up and use Oracle Names version 2.0 with the Dynamic Discovery Option (DDO).
If you are not certain whether to use the Dynamic Discovery Option, see "Choose Whether to Use the Dynamic Discovery Option"![[*]](jump.gif)
.
Upgrading to SQL*Net release 2.3 and Oracle Names 2.0 without the Dynamic Discovery Option is discussed, "Configuring Oracle Names".
Configuration Scenarios
This chapter describes how to do the following:
- Create a new network using DDO--create a completely new network using Oracle Names 2.0 and the Dynamic Discovery Option.
- Upgrade all components in an existing network--upgrade all the existing Oracle Names and SQL*Net components in your network to SQL*Net 2.3 and Oracle Names 2.0 using the Dynamic Discovery Option.
- Gradually upgrade an existing network--gradually upgrade an older SQL*Net network to use SQL*Net release 2.3 and the Dynamic Discovery Option.
- Upgrade from a Native Naming Adapter--gradually migrate a site which uses another naming service to use Oracle Names 2.0 with the Dynamic Discovery Option.
In addition, this chapter includes a section on non-default parameters. If your network configuration is not covered by of these scenarios, see Appendix B, "Complex Network Issues and DDO," for instructions on other networks.
Note: If you have a network that stays the same for long periods of time, whether large or small, converting the network to dynamic discovery may not be worth the effort. Also, administrators of networks that have MultiProtocol Interchanges, gateways, or Native Naming Adapters might find the Dynamic Discovery Option more troublesome to use than its benefits warrant.
A Review of Network Components
In order for Oracle Names 2.0 to function correctly as a naming service, certain information needs to be accessible to certain components. When you configure and run a network with Oracle Names 2.0 and the Dynamic Discovery Option, there are three main network components that must be able to communicate and find each other:
- Oracle7 Servers--Oracle7 Servers must know how to find a Names Server in order to register themselves automatically. If they are not registered automatically, they need to be defined in the network definition using Network Manager.
- Clients--Clients on the network must know how to find all Names Servers.
Rules for Setting Up and Using the Dynamic Discovery Option
The following list of rules applies to all the given scenarios described in this chapter. Following these rules provides the smoothest transition to Oracle Names 2.0 with the DDO.
- New Oracle Names Servers must also be defined in the network definition as long as there are SQL*Net 2.2 (or earlier) clients on the network that have not been upgraded.
This is due to the fact that the network definition is the source of the NAMES.PREFERRED_SERVERS parameter in the SQLNET.ORA file which clients with earlier versions of SQL*Net use to locate the Names Servers.
- Since all Names Servers must read the network definition, and all Names Servers are defined in the network definition, Names Servers do not need well-known Names Servers to know about each other if a network definition exists
- All Names Servers should continue to use the network definition to get information for 7.2 (or earlier) databases whenever the connect data is modified.
In this case there is no need for Dynamic Discovery.
- New and upgraded Names Servers can use well-known addresses as long as the new well-known Names Servers are defined in the network definition using oranamesrvr0-4.
- Clients, databases, and listeners on an existing network already have a NAMES.PREFERRED_SERVERS defined in their SQLNET.ORA file enabling them to find all local Names Servers, regardless of whether they are using a well-known Names Server.
These are configured addresses that are provided to Oracle Names clients, and SQL*Net clients and listeners. These addreses are also provided to other Names Servers in the network definition.
- When all SQL*Net release 2.2 (or earlier) clients have been upgraded, the Names Server definitions can be dropped from the network definition.
- When all databases and listeners in the region are upgraded to Oracle 7.3, their definition in the network definition can be dropped because services are now automatically registered.
- When the previous two items are true, the network definition and the NAMES.PREFERRED_SERVERS parameter can be dropped entirely. All of the Names Servers and all of the clients are now upgraded and the network definition is unnecessary in the Dynamic Discovery network.
Before You Begin
Before you begin using any of the following upgrade scenarios, the following must be true:
- a single region and a single community
- a protocol which supports well-known addresses
These scenarios describe the TCP/IP protocol. If you need information on other protocols, see your platform-specific documentation.
- site administrator chooses to use the Dynamic Discovery Option.
Scenario 1: Create a New Network Using the Dynamic Discovery Option
The following steps are brief guidelines for you to create and run your network using Oracle Names 2.0 with the Dynamic Discovery Option.
No other configuration files are needed if you accept all default parameters. The only configuration file needed in a default setup is a LISTENER.ORA for every database, which is created automatically during installation.
. Install the Names Server.
See your platform specific documentation for information on how to install the well-known Names Server. The default installation setup for the Names Server uses the Dynamic Discovery Option.
. Assign aliases to the nodes that will be well-known Names Servers.
You must provide an alias for each of the machines that will become a well-known Names Server. The required aliases are oranamesrvr0, oranamesrvr1, and so forth through oranamesrvr4. For TCP/IP networks, the port number used by the well known Names Server is 1575. This port number is included in the SQL*Net 2.3 software so that all SQL*Net release 2.3 clients and services know it without any action by you.
If Network Information Services (NIS) is used on the network, list the addresses of the well-known Names Servers in the host.byname map file. If there are slave NIS servers, do an explicit yppush to all the slaves.
If NIS is not used, add an alias for each of the well-known Names Servers to the /etc/hosts file on every host file in the network. The content of the /etc/hosts file will look something like the following:
ipaddress howe.acme.com oranamesrvr0
ipaddress orr.acme.com oranamesrvr1
ipaddress roenick.acme.com oranamesrvr2
ipaddress gretzky.acme.com oranamesrvr3
ipaddress syoung.acme.com oranamesrvr4
The well-known address port number may vary depending on the protocol in use in your network; refer to your platform-specific documentation for the specific port number used.
. Start the 2.0 Names Servers on nodes for which you created the YP or NIS aliases.
To start the Names Server, execute the following command:
NAMESCTL START
A message will indicate whether or not the Names Server was successfully started.
. Install and define databases and listeners.
Answer Yes when queried during the installation process whether to upgrade using the Dynamic Discovery Option.
See the Oracle operating system-specific documentation for your platform. You may also want to refer to the following documents published by Oracle Corporation:
Attention: When installing SQL*Net you must execute the install_pnp script to be able to generate a LISTENER.ORA file. Execute the script in order to proceed. For more information on the install_pnp script see your platform-specific documentation.
. Check to see if the GLOBAL_DBNAME parameter is in your LISTENER.ORA file. It will look approximately like the following:
GLOBAL_DBNAME=DBNAME.domain
If you do not have the GLOBAL_DBNAME in your LISTENER.ORA file the listener will not be able to register with the Names Server.
. Start listeners using LSNRCTL.
To start a network listener, execute the following command:
LSNRCTL START
When the listener starts, it registers itself and the services it listens for with the well-known Names Server.
See your platform-specific documentation for more information on how to install clients on your network.
. Test if the Names Servers have the databases defined.
From any node on your network that has SQL*Net and NAMESCTL installed, enter the following NAMESCTL command:
NAMESCTL> QUERY db_name
At this point your network should be fully operational with the Dynamic Discovery Option so that you can start the database and use your network connections.
Attention: The Dynamic Discovery Option only works on nodes that use SQL*Net release 2.3. Services will not be automatically registered if SQL*Net release 2.3 is not used, and clients will not be able to find the well-known Names Server.
Scenario 2: Upgrading All Components in an Existing Network
The following steps are a guide for upgrading all network components to SQL*Net 2.3 and Oracle Names 2.0 using the Dynamic Discovery Option.
This scenario is useful for networks that can upgrade all components from an existing SQL*Net version to SQL*Net 2.3 and Oracle Names 2.0 with the Dynamic Discovery Option at one time.
. Shut down all database listeners.
. On all client and server nodes, use a text editor to remove the NAMES.PREFERRED_SERVERS parameter in the SQLNET.ORA file.
. Remove the NAMES.ORA file on all existing Names Server nodes.
Your explicit path to NAMES.ORA is operating system-specific. On most UNIX systems NAMES.ORA exists in the following location:
$ORACLE_HOME/network/admin/names.ora
. Install Oracle Names 2.0 on the Names Server nodes.
We recommend installing Oracle Names on at least two Names Servers to preserve a fault-tolerant network.
. Assign aliases to the nodes that will be well-known Names Servers.
You must provide an alias for each of the machines that will become a well-known Names Server. The required aliases are oranamesrvr0, oranamesrvr1, and so forth through oranamesrvr4. For TCP/IP networks, the port number used by the well known Names Server is 1575. This port number is included in the SQL*Net 2.3 software so that all SQL*Net release 2.3 clients and services know it without any action by you.
If Network Information Services (NIS) is used on the network, list the addresses of the well-known Names Servers in the host.byname map file. If there are slave NIS servers, do an explicit yppush to all the slaves.
If NIS is not used, add an alias for each of the well-known Names Servers to the /etc/hosts file on every host file in the network. The content of the /etc/hosts file will look something like the following:
ipaddress howe.acme.com oranamesrvr0
ipaddress orr.acme.com oranamesrvr1
ipaddress roenick.acme.com oranamesrvr2
ipaddress gretzky.acme.com oranamesrvr3
ipaddress syoung.acme.com oranamesrvr4
Note: The well-known address port number may vary depending on the protocol in use in your network; refer to your platform-specific documentation for the specific port number used.
. Start the 2.0 Names Servers on nodes for which you created YP or NIS aliases.
To start the Names Server, execute the following command:
NAMESCTL> START
A message will indicate whether or not the Names Server was successfully started.
. Upgrade all listeners to SQL*Net 2.3 and databases to Oracle7.3.
Answer Yes when queried during the installation process whether to upgrade using the Dynamic Discovery Option.
At this point the LISTENER.ORA file will be created. This file contains all the Dynamic Discovery data for each service.
Attention: When installing SQL*Net you must execute the install_pnp script to be able to generate a LISTENER.ORA file. Execute this script in order to proceed. See your platform-specific documentation for more information on using or obtaining the install_pnp script.
. Check to see if the GLOBAL_DBNAME parameter is in your LISTENER.ORA file. It will look approximately like the following:
GLOBAL_DBNAME=DBNAME.domain
If you do not have the GLOBAL_DBNAME in your LISTENER.ORA file the listener will not be able to register with the Names Server.
. Start listeners using LSNRCTL.
To start a network listener, execute the following command:
LSNRCTL START
When the listener starts, it registers itself and the services it listens for with the well-known Names Server.
. Upgrade all clients on the network.
Each client application should now be upgraded to run SQL*Net 2.3
At this point all of the components in your network should be fully configured to run Oracle Names 2.0 with the Dynamic Discovery Option.
Test whether applications can successfully connect to an Oracle Names Server from a SQL*Net client. Execute a SQLPlus application, such as sqlplus username/password@service_names, where service_name is the database name that has just been registered. If you cannot connect, most likely you will receive the error ORA-12154. This usually indicates that the client cannot find the Names Server. Refer to the trace files or error message log files to find details.
Scenario 3: Gradually Upgrading an Existing Network
This scenario is most useful to a site that cannot upgrade everything at once, but want to upgrade various components to the Dynamic Discovery Option in an orderly fashion.
This scenario takes you through an upgrade where there are three existing Names Servers in a network. All of the servers are upgrading to SQL*Net 2.3 and Oracle Names 2.0, but at this time only two are becoming well-known Names Servers using the Dynamic Discovery Option. The third Names Server will not use the DDO.
In this case, the network will maintain some SQL*Net 2.2 clients and some SQL*Net 2.3 clients.
. Upgrade all Names Servers to Oracle Names 2.0.
It is important that all Names Servers be upgraded to Oracle Names 2.0 so that they can replicate their registration information.
. Assign aliases to the nodes that will be well-known Names Servers.
You must provide an alias for each of the machines that will become a well-known Names Server. The required aliases are oranamesrvr0, oranamesrvr1, and so forth through oranamesrvr4. For TCP/IP networks, the port number used by the well known Names Server is 1575. This port number is included in the SQL*Net 2.3 software so that all SQL*Net release 2.3 clients and services know it without any action by you.
If Network Information Services (NIS) is used on the network, list the addresses of the well-known Names Servers in the host.byname map file. If there are slave NIS servers, do an explicit yppush to all the slaves.
If NIS is not used, add an alias for each of the well-known Names Servers to the /etc/hosts file on every host file in the network. The content of the /etc/hosts file will look something like the following:
ipaddress howe.acme.com oranamesrvr0
ipaddress orr.acme.com oranamesrvr1
ipaddress roenick.acme.com oranamesrvr2
ipaddress gretzky.acme.com oranamesrvr3
ipaddress syoung.acme.com oranamesrvr4
Note: The well-known address port number may vary depending on the protocol in use in your network; refer to your platform-specific documentation for the specific port number used.
. The newly migrated well-known Names Servers need to be defined in the network definition. Using Network Manager, change the address of two of the newly upgraded Names Servers to be well-known addresses. To do this, create new nodes names oranamesrvr0 and oranamesrvr1. Edit the property sheets of the two of the Names Servers so that they are on these nodes, using port 1575.
For example, the previously existing network definition for the two servers might have looked like the following:
(address=(protocol=tcp) (host=gretzky) (Port=1529))
(address=(protocol=tcp) (host=howe) (Port=1529))
The new well-known address definition that you update using Network Manager must look like the following:
(address=(protocol=tcp) (host=oranamesrvr0) (port=1575))
(address=(protocol=tcp) (host=oranamesrvr1) (port=1575))
. Start the well-known Names Servers on nodes for which you created YP or NIS aliases.
To start the Names Server, execute the following command:
NAMESCTL START
A message will indicate whether or not the Names Server was successfully started.
. Upgrade all desired listeners to SQL*Net 2.3 and databases to Oracle7.3.
Use Network Manager to remove each database that you choose to upgrade from the old network definition. This is necessary because all Oracle7.3 databases will automatically register themselves with a well-known Names Server. The database name automatically goes into the LISTENER.ORA file that is being created when that database is upgraded. When the listener starts, it registers the database name with the well-known Names Server.
During the upgrade process, answer "Yes" when queried whether to upgrade using the Dynamic Discovery Option.
At this point the LISTENER.ORA file will be created. This file contains all the Dynamic Discovery data for each database.
Attention: When installing SQL*Net you must execute the install_pnp script to be able to generate a LISTENER.ORA file. Execute this script in order to proceed. See your platform-specific documentation for more information on using or obtaining the install_pnp script.
. Check to see if the GLOBAL_DBNAME parameter is in your LISTENER.ORA file. It will look approximately like the following:
GLOBAL_DBNAME=DBNAME.domain
If you do not have the GLOBAL_DBNAME in your LISTENER.ORA file the listener will not be able to register with the Names Server.
. Start listeners using LSNRCTL.
To start a network listener, execute the following command:
LSNRCTL START
When the listener starts, it registers itself and the services it listens for with the well-known Names Server.
. Upgrade the desired clients to SQL*Net 2.3.
At this point you have the option of removing the NAMES.PREFERRED_SERVERS parameter in the SQLNET.ORA file for all SQL*Net 2.3 clients. We recommend that you keep this line in the SQLNET.ORA file. In case both well-known Names Servers are not available, those clients can still find the other Names Server even though it is not a well-known Names Server.
This is an issue of reliability versus maintenance and distribution, and should be decided by individual administrators for each individual network.
. Start all databases and listeners that have been upgraded.
Note: SQL*Net 2.2 clients can be configured to use the well-known Names Servers. Simply define the new well-known Names Servers on the NAMES.PREFFERED_SERVERS parameter in the network definition using Network Manager.
Generate new configuration files. Distribute the SQLNET.ORA files that include the new Names Server addresses to all of the clients on the network.
Note: All three Names Servers should be included in the list of NAMES.PREFFERED_SERVERS in the SQLNET.ORA file.
Although it has been upgraded to Oracle Names 2.0, the third Names Server does not need the NAMES.PREFFERED_SERVERS in the SQLNET.ORA file be edited.
At this point all of the components you have chosen to upgrade in your network should be fully configured to run Oracle Names 2.0 with the Dynamic Discovery Option.
Test whether applications can successfully connect to an Oracle Names Server from a SQL*Net client. Execute a SQLPlus application, such as sqlplus username/password@service_names, where service_name is the database name that has just been registered. If you cannot connect, most likely you will receive the error ORA-12154. This usually indicates that the client cannot find the Names Server. Refer to the trace files or error message log files to find details.
Scenario 4: Upgrading from a Native Naming Adapter
This scenario is based on gradually upgrading from a native naming adapter to Oracle Names 2.0 with the Dynamic Discovery Option.
. Set all clients NAMES.DIRECTORY_PATH parameter in the SQLNET.ORA file to include both Oracle Names 2.0 and other adapters such as NIS.
The default setting of the NAMES.DIRECTORY_PATH parameter in the SQLNET.ORA file will be in the following order:
- other naming adapter (NIS)
You can arrange the order of the names this parameter according to your preference. For non-default settings, for example, if you want to use DDO, you must change the file so that ONAMES will be first.
To do this, use the SQLNET.ORA Editor to set the parameter as follows:
NAMES.DIRECTORY_PATH=(ONAMES, NIS, TNSNAMES.ORA)
When the NAMES.DIRECTORY_PATH is set as shown above, the client will attempt to use a Names Server before using the NIS naming adapter.
. When a database listener is upgraded to Oracle 7.3, its definition can be dropped from the native naming adapter so that it can be automatically registered by the database and listener.
Attention: Databases should not be defined in both Oracle Names 2.0 and the native naming adapter.
. When all databases and listeners are upgraded to Oracle 7.3 and started to automatically register, the entire definition of the other native naming adapter can be dropped and the NAMES.DIRECTORY_PATH parameter in SQLNET.ORA can just be Oracle Names.
Non-default Parameters
In a Dynamic Discovery environment in which all default parameters are accepted, you do not need to have any configuration files except the LISTENER.ORA for each listener node created during installation. However, there may be times when some additional configuration files are needed. There are two major reasons you may need other configuration files:
- to add optional parameters to a SQLNET.ORA file
- to add elements to your network that cannot register themselves with the well-known Names Servers
Decision: If you have a lot of non-default parameters to add, and especially if you want to define a number of objects that cannot self-register, you may want to reconsider whether the Dynamic Discovery Option is appropriate for your network.
How to Create a SQLNET.ORA File
There are two ways to create a SQLNET.ORA file. Choose the method that best fits your situation.
- If you want to create a SQLNET.ORA file that is the same for many clients, you may want to use Oracle Network Manager to create a network definition that includes a description of one or more client profiles. Generate configuration files from that definition, and transfer the configuration files to the appropriate nodes. This method is most useful if you can use an identical SQLNET.ORA file for many clients, or if you need to use Network Manager to add other objects to the network definition. For instructions on how to use Network Manager, see the Oracle Network Manager Administrator's Guide.
- If you want to create SQLNET.ORA files for just a few clients, or if each client's SQLNET.ORA file contains unique values, use the SQLNET.ORA Editor, part of the Client Status Monitor, to create a SQLNET.ORA file with the specific parameters needed.
If you need more information, please see Oracle Network Products Troubleshooting Guide.
Parameters in a SQLNET.ORA File
A SQLNET.ORA file may contain a number of optional parameters. Most of the parameters control the behavior of clients. There are also some parameters that control servers, the Names Control Utility, and the TNSPING Utility.
All the SQLNET.ORA parameters are described in Understanding SQL*Net. This section describes the parameters you are most likely to want to include when using DDO.
Note: Unless otherwise noted, these parameters can be added to an existing SQLNET.ORA file using the SQLNET.ORA Editor or Network Manager.
Dead Connection Detection
Add this parameter to request SQL*Net to send a periodic probe to detect dead connections. A value of 10 (minutes) is recommended.
Logging and Tracing Parameters
You can set optional tracing and logging parameters for clients and servers in the SQLNET.ORA file. You can also set tracing parameters for the Names Control Utility and TNSPING. Use the SQLNET.ORA Editor for client and TNSPING parameters. Parameters for the server and the Names Control Utility must be added manually.
Dedicated Server
Set this optional parameter to ON if you want to request a dedicated Names Server process from a server configured as a multi-threaded Names Server.
Secure Network Services Parameters
If Secure Network Services is installed in your network, add parameters to request encryption, checksum, and authentication services. Use the SQLNET.ORA Editor to add them to the client side. Add them manually or with Network Manager for the Names Server.
Disable Out of Band Breaks
If you want to disable out of band breaks, add this parameter, set to ON. Out of band breaks are the default, unless there is an Interchange on the network.
Default Domains
If the naming convention in your network includes a domain, you can enable applications to request connections to servers without including the domain in the request by adding this parameter with the domain as the value.
Note: If you use Network Manager to create a SQLNET.ORA file, this parameter is included automatically, with .WORLD as the domain by default. If there is no domain in your network, use a text editor to delete this parameter in the SQLNET.ORA file before distributing it to individual clients.
Preferred Names Servers
You may want to have some of your clients contact one particular Names Server rather than another. In a Dynamic Discovery network all clients contact the Names Server on the node with the alias oranameserver0 first by default. To avoid bottlenecks, or to have the client contact the Names Server that is geographically closest, you may want to add this parameter to the SQLNET.ORA file. This concept is called network load balancing. See the following section for more details.
Network Load Balancing
If your network covers a wide geographic area, or if you want to balance the load among the Names Servers, you can add a parameter to the SQLNET.ORA file on the clients so that they contact a specific Names Server first. That parameter is:
NAMES.PREFERRED_SERVERS=(names_server_address)...
For example, suppose you have a network with a well known Names Server given the alias oranamesrvr0 in New York and another with the alias oranamesrvr1 in London. You might want your clients in Europe to contact the Names Server in London first. For this to happen, every European client would need a SQLNET.ORA file with the following line:
NAMES.PREFERRED_SERVERS=
(ADDRESS_LIST=(ADDRESS=
(PROTOCOL=TCP)
(HOST=ORANAMESRVR1)
(PORT=1575))
(ADDRESS=
(PROTOCOL=TCP)
(HOST=ORANAMESRVR0)
(PORT=1575)))
