Release 8.0
A58230-01
 Library |
 Product |
 Contents |
 Index |
| Oracle Net8 Administrator's Guide Release 8.0 A58230-01 |
|
Oracle Names is a distributed naming service developed for Oracle environments to help simplify the setup and administration of global, client/server computing networks.
This chapter describes features and functionality available with the version 8 release of Oracle Names. It also outlines procedures for configuring and controlling Oracle Names using the Oracle Net8 Assistant.
This chapter includes the following sections:
Oracle Names establishes and maintains an integrated system of Names Servers which work together like a directory service storing addresses for all the services on a network and making them available to clients wishing to make a connection.
Much like a caller who uses directory assistance to locate a telephone number, clients configured to use Oracle Names will refer their connection requests to a Names Server. The Names Server will attempt to resolve the service name provided by the client to a network address. If the Names Server finds the network address it will then return that information to the client. The client can then use that address to connect to the service.
Figure 6-1 depicts how Oracle Names works to help establish a connection between a client and server.
Oracle Names provides an alternative to file-based or `local' name resolution methods, where service names and addresses must be configured and maintained with each individual client. By maintaining this information in a central administrative location, Oracle Names reduces the work effort associated with adding or relocating services.
Names Servers may be configured and started on any node where Net8 is installed. You may use the Oracle Names Control Utility (NAMESCTL), or the Oracle Net8 Assistant to define service names and aliases and their associated values for use with Oracle Names. Alternatively, you may configure a network listener to register its services automatically with a Names Server. As services are started and shut down, the listener will dynamically register and de-register the connect descriptor and service name to a Names Server appropriately.
Oracle Names also supports different modes for storing service registration data. For smaller workgroup environments where all of the services are registered dynamically, administrators may configure Names Servers to replicate data continuously among themselves. When a network listener registers a new service, information about that service will immediately be passed along to other Names Servers in the administrative region.
Alternatively, administrators in large environments will normally want to store their registration data in an Oracle database. If the Names Servers are configured to use an Oracle database as a repository, all service registrations (both static and dynamic) will be written to the database. Each Names Server in a given administrative region will periodically poll the region database for updated registrations. In this way, new registrations are communicated in a timely manner to all of the Names Servers in a given region. At the same time, it relieves Names Servers of the necessity to communicate directly with each other, as well as provides better reliability.
Oracle Names also provides support for one or more administrative regions. An administrative region consists of a collection of Names Servers which share a common service registry. They do this either through continuous replication between all the Names Servers in the region, or by writing to and reading from a common Oracle database (also called the region database).
Most enterprise environments with multiple data centers and many Oracle instances will probably choose to take advantage of multiple administrative regions. This allows each data center to independently define and manage the services in its own environment. At the same time, all service addresses are continuously available to all of the clients in the environment. Names Servers transparently forward name resolution requests from clients in foreign administrative regions to the proper Names Server.
Table 6-1 describes the type of data stored in a Names Server.
To configure and control a Names Server, use the Oracle Net8 Assistant.
Figure 6-2 depicts the graphical user interface used to manage a Names Server using the Oracle Net8 Assistant.
To configure a Names Server using the Oracle Net8 Assistant, proceed as follows:
Preferences will be saved in the Oracle Names configuration file (NAMES.ORA). For a complete list of parameters that are available in your Oracle Names configuration file, refer to "Oracle Names Parameters (NAMES.ORA)" in Appendix B, "Configuration Parameters".
To start a Names Server using the Oracle Net8 Assistant, proceed as follows:
Figure 6-3 depicts the Control tab panel from the Manage Server pull down option.
To load information from a local naming configuration file into a Names Server, proceed as follows:
If you decide to store your Names Server information in a database, you will need to create the database for the region. To do this, proceed as follows:
If you wish to create a database to store Names Server information in a delegated region, proceed as follows:
When you use Oracle Names, objects such as databases in a networked environment will need to be named in a way as to ensure that they are unique within the network. There are two basic models for naming objects in a network:
The use of the single domain naming model is useful if your network is small, and there is no duplication of names. Figure 6-4 depicts a typical flat naming structure using a single domain name .WORLD.
In this environment, database service names will automatically be appended with a ".WORLD" extension (for example, PROD.WORLD, FLIGHTS.WORLD, and so forth).
Hierarchical naming models divide names into a hierarchical structure to allow for future growth or greater naming autonomy. This type of naming model will allow more than one database with the same simple name in different domains. Figure 6-5 depicts a hierarchical structure of domains including the (ROOT) domain, ACME domain, US.ACME, EUROPE.ACME, and ROW.ACME (Rest of World) domains.
Notice in Figure 6-5 both WEATHER and HISTORY are repeated, but the global names remain unique (that is, HISTORY.ROW.ACME and HISTORY.EUROPE.ACME).
A domain is a logical group of machines and network services. Within each domain all names must be unique, but across domains simple unqualified names can be repeated.
Network domains are similar to file directories used by many operating systems in that they are hierarchical. Unlike file systems however, network domains may or may not correspond to any physical arrangement of databases or other objects in a network. They are simply names spaces developed to prevent name space conflicts.
Note: Although they appear similar, the domains of an Oracle network are completely independent of Domain Name Service (DNS) name spaces. For convenience, you may choose to mirror the DNS conventions in your Oracle network.
The default domain is the domain within which most of the client's name requests are conducted. This is usually the domain in which the client resides, though it could also be another domain from which the client often requests services. A client can request a network service within its default domain using the service's simple, unqualified name, that is, without specifying a domain name. If a user requests a name without a "." character in it, the default domain name is automatically appended to the database service or database link name requested.
Figure 6-6 depicts a client with a default domain of EUROPE.ACME.COM. When it makes a request for the service name "WINE", the default domain name EUROPE.ACME.COM is appended to the requested name so that the name becomes WINE.EUROPE.ACME.COM.
For more information on domain names, refer to Oracle8 Server Concepts.
Multiple domains are related hierarchically to a root domain (the highest-level domain in the hierarchy) in a series of parent-child relationships. For example, under the root might be several domains, one of which is called COM. Under the COM domain might be several more domains, one of which is ACME. Under the ACME domain might be several domains, such as US, EUROPE, and so forth.
In previous releases of SQL*Net and Oracle Names, a network with only one domain, would by default be called ".world". This is no longer a requirement with Net8 and Oracle Names version 8. You may, however, want to keep the same convention to be backward compatible, as well as to avoid having to rename all your databases.
Most networks have one central point of administration, that is, one administrative region. A region is an administrative name space that defines a population of Names Servers. It is used to divide administrative responsibilities.
If you are using Oracle Names and your network is large or widely distributed geographically, you may choose to have several points of network administration. For example, if your network includes both the United States and Europe, you might want to have administrative decisions about the network made locally.
To delegate administrative regions, you must use a hierarchical naming model with each administrative region controlling one or more different domains.
Networks with multiple administrative regions must have one root administrative region and one or more delegated administrative regions.
The domain at the top of a hierarchy is known as the root domain. Similarly, the administrative region that encompasses the root domain is known as the root administrative region. The root defines the reference point within which the naming model and the administrative model function. The root administrative region provides a common thread among all delegated administrative regions in a hierarchical naming structure. The root administrative region requires:
Administrative regions can be "delegated" from the top of the hierarchy down to other domains in the naming model. For example, a naming model with ten domains can have between one and ten administrative regions.
All administrative regions other than the root are hierarchically delegated directly or indirectly from it. Figure 6-7 depicts a network with six domains and three administrative regions: the ROOT, and two delegated regions (DR1, DR2).
All administrative regions below the root are considered delegated administrative regions. Each delegated region must know:
