Running and Managing Oracle Names
This chapter describes operations you need to perform to maintain individual Names Servers and the Oracle Names system.
These operations assume that you have successfully installed and configured the Names Servers as described in the previous chapters.
Note: Information on configuring and distributing configuration files, and performing initial testing is documented in the Oracle Network Manager Administrator's Guide.
Basic NAMESCTL Operations
This section describes a handful of common management tasks for the Names Servers, and the commands you can perform with the Names Control Utility program. By using this tool, you can execute such commands as STARTUP, SHUTDOWN, and so on. Additionally, you can view and change Names Server parameter settings, and perform other operations for Oracle Names.
See Appendix A, "Oracle Names Control Utility Reference," for more information on the Names Control Utility program.
Starting a Server
The STARTUP command loads the Names Server into memory and tells it to begin executing. At startup, the Names Server loads its configuration, loads its data, then becomes available to answer requests.
NAMESCTL> STARTUP
Shutting Down a Server
The SHUTDOWN command stops the execution of a Names Server. The program stops executing, and releases any machine resources being used.
NAMESCTL> SHUTDOWN
Handling Data Change Requests on a Names Server
A method for requesting to add, change, or delete network objects and their associated names from the Names Server is required. When a DBA installs a new database server or configures a database link, a form similar to the "Oracle Names Request Form"should be filed, either through an e-mail message, a phone message, a paper form, or other convenient method. The administrator can then modify the data and refresh the Names Servers at regular intervals.
The simplest method of organizing service requests in your organization is an electronic mail account either explicitly used for Oracle Names, or shared for general system requests. The benefit of a dedicated Oracle Names e-mail account is that messages are immediately received by the Names administrator. With a general electronic mail account, they are usually fielded by a dispatcher and forwarded to the Names administrator.
The following illustration shows a sample for the contents of an Oracle Names request form or e-mail template.
Figure 7 - 1. Oracle Names Request Form
Reloading Data
When any data from an administrative region changes, you must reload the Names Servers in that region for the changes to be read. This includes changes to the set of Names Servers in that region, or database names and database links that have been added, deleted, or changed by using the Network Manager. Reloading flushes all local data, then loads a new copy from the network definition.
You can also reload data by using Reload Names Servers from the Control menu in the Network Manager. All Names Servers in the region will be reloaded one at a time.
In distributed administration installations, any non-authoritative data stored in Names Servers is unaffected. To remove non-authoritative data from a Names Server's cache use the FLUSH command, or use the RESTART command instead of RELOAD. (RESTART preserves "live" cache; that is, foreign data whose TTL has not yet expired.)
Note: For more information about authoritative data and non-authoritative data, see Appendix C, "Advanced Topics".
Each Names Server also regularly checks to see if any data has changed since the last reload. This ensures that all changes are seen, even if the administrator forgets to reload. By default, the interval between checks is 10 minutes.
Testing Names Server Availability
To test that a Names Server is operating correctly, use the PING command. Following are ways to ping the Names Server LABRADOR in the US.ACME domain.
NAMESCTL> PING LABRADOR.US.ACME
You can also PING multiple Names Servers by using a single command, for example:
NAMESCTL>PING HUEY.UK.ACME DUEY.UK.ACME LOUIE.UK.ACME
The PING command responds with the time it takes to contact the server and return an acknowledgment.
If PING fails, make sure the server has been started. If it has been, double-check the configuration in the Network Manager, especially the defined address of the Names Server in question.
Maintaining Names Servers
All installations have the problem of physically maintaining computers. Many, but not all, activities can be performed remotely by the administrator.
Names Servers may be installed outside of central data center locations for greater availability to outlying clients. Wherever Names Servers are installed, one or more individuals need to be responsible for assisting in keeping them up and running.
Conditions Causing Oracle Names Failures
Failure is identified either by a timeout at the client when waiting for a response from the Names Server, or by the inability to contact the Names Server at all.
When an Oracle Names Server cannot be reached, the client will contact the next Names Server in its preferred Names Server list. The failure of a specific Names Server does not affect the operation of any other Names Server in that administrative region or any other region.
Testing Network Objects
To test that a network object exists, use the QUERY command. The syntax for this command is as follows:
NAMESCTL> QUERY global_object_name type
Database service names have the type A.SMD, and database links have the type DL.RDBMS.OMD. The following example shows a query of the database service name BUGSY in the MACS.ACME domain:
NAMESCTL> QUERY BUGSY.MACS.ACME A.SMD
The QUERY command returns the amount of time the transaction took and information about the network object.
Removing Foreign Data
In a distributed installation, you can remove all non-authoritative data from a server cache by using the FLUSH command:
NAMESCTL> FLUSH
As shown, this command flushes the current Names Server. If you want to flush another Names Server or multiple Names Servers, supply their names as arguments to the FLUSH command. Refer to Appendix A, "Oracle Names Control Utility Reference", for more information.
You would typically use this command only if the Names Server seems to be providing inaccurate responses. Removing non-authoritative data removes any data that may be incorrect. The cost is that all non-authoritative data must be looked up again.
Removing Data for Individual Network Objects
Once you have determined that an individual foreign object is out of date or inaccurate, you can flush data for this object only by using the command:
NAMESCTL> FLUSH_NAME FINANCE.UK.ACME
You can flush only one name at a time, and only from the current Names Server.
Testing from a Client
When the Names control commands such as PING and QUERY appear to be working, you should test a number of SQL*Net initiated connections that are resolved by the Names Server.
Client Configuration
The client requires a SQLNET.ORA file with one or more Names Server addresses defined in the NAMES.PREFERRED_SERVERS parameter. These Names Servers are contacted in order until a response is returned. Additionally, each client default domain is set with the NAMES.DEFAULT_DOMAIN parameter to simplify how domains are specified during connection requests and when using NAMESCTL.
Both parameters, as well as the rest of the SQLNET.ORA file, are generated by the Network Manager as part of the client profiles.
How Clients Request Network Objects
To request access to a network object, the client uses the familiar client/server connection syntax:
sqlplus scott/tiger@FINANCE
For details on connecting from a specific tool, see the manual for that tool. For general notes on initiating SQL*Net connections, see Understanding SQL*Net.
Testing Distributed Database Links
If you will be using Oracle Names in distributed databases, you should also test that database links are being properly resolved.
Server Configuration
The Names Server that will coordinate the transaction must also be able to function as a client, as described in the previous section. This means that the SQLNET.ORA file must contain a defined NAMES.PREFERRED_SERVERS parameter. You define this parameter in Network Manager, and Network Manager then generates this parameter as part of the SQLNET.ORA file for the client profiles.
Using Database Links with Oracle Names
When a server initiates the use of a database link, the Names Server is called, and the request is executed, as with locally defined database links (links defined in the local database data dictionary). Consider, for example, the SQL statement shown:
SELECT A.ITEM, B.COST
FROM PARTS A, PRICE@FINANCE.US.ACME B
WHERE A.PARTNO = B.PARTNO;
FINANCE.US.ACME is looked up in the Names Server. Then the link is established between the current database and the FINANCE database. (FINANCE is the name of the database service, as well as the name of the global database link.)
For more information on how to define global database links, refer to the following documents:
Database Link Security
Any database link stored in the Names Server with an explicit username and password should contain only data that is regarded as public. Storing such a name allows any user through any server to view the data in that account.
You can provide security by creating database links that omit the username and password. If you do not enter a username and password, whoever uses the database link will use their own username and password to make the connection. This requires that multiple user accounts in multiple systems have the same usernames and passwords. All users can request the use of the database link, but only users with valid accounts and access to the tables at the remote Names Server will be able to see the data.
Database Link Search Path
When a database link is used to select information from a remote database table (for example, SELECT * FROM EMP@HR.US.ORACLE.COM), Oracle searches for a connect descriptor in the following locations in the following order:
1. the user's private database links
2. the database public database links
3. the Oracle Names Server global database links
Oracle ends the search when a USING clause is found in either a private or public database link. If a USING clause is not found in a private or public link, then the global database link is used. If a connect descriptor is not found, the following message is returned:
ORA-02019: "connection description for remote database not found"
If a CONNECT TO clause (username/password) is found in any of the searched database links, the first one found is used. If none are found, then the current username and password will be used.
Diagnosing Names Server Failures
There is a small number of common problems when starting and using a Names Server as summarized in this section.
Names Not Retrieved
If a Names Server fails to return a name, try one or more of the following:
In all networks (central and distributed):
- Check the setting for the default domain using SHOW DEFAULT_DOMAIN. Remember that the default domain is appended to all unqualified names (names without a "."). To be sure that the default domain is not at fault, query the fully qualified name by using the command:
NAMESCTL>QUERY full_name type
The most common object type is a network address which is usually A.SMD.
Note: You can run these commands from any machine; you do not have to run them from the client or Names Server machine.
NAMESCTL>SET SERVER names_server
You may also want to try:
NAMESCTL>PING names_server
In a distributed administration network:
- Check to see if the Names Server responded with an authoritative or non-authoritative answer. To do so, use the following command against the responding Names Server:
NAMESCTL>QUERY name type
NAMESCTL>QUERY name type AUTHORITY
This forces the name to be looked up at its authoritative source. Notice that the line "Authoritative Answer: Yes" is included in the response.
- Compare the old value to the results of the second query. If the details are different, then the data did change. Be aware that other Names Servers may also have an old version of this name.
- If a name you know should exist is not being retrieved, try other names in the same domain, or the same administrative region. Try to identify whether the failure is on the individual name, or whether all names in the region are not being retrieved.
- Use the TRACE modifier on a QUERY to have the Names Server search path returned:
NAMESCTL>QUERY name type TRACE
- See if a Names Server serving the desired administrative region is accessed.
Names Server Not Found
Because the default Names Server is always in the client's community and administrative region, the failure is usually due to a configuration error, or because the network or the Names Server is unavailable.
STATUS names_server
If you receive the error:
NNL-00018: Warning: could not contact default name server
when loading NAMESCTL, it usually means that the configured Names Server is not available (that is, not started), or that it is incorrectly configured.
Parameter File Not Found
When starting either the Names Server or the NAMESCTL utility, each expects to find a parameter file with the startup details. If the file does not exist, a message will be returned indicating what file is expected.
For example, on UNIX if you attempt to start a Names Server when no NAMES.ORA file exists, you receive the following error message:
NL-00462 error loading parameter file /oracle/network/admin/names.ora
SNL-00821 File does not exist.
