Oracle Names Architecture
This chapter describes the architecture of Oracle Names. Included in this chapter are discussions on policies and working rules within which the product is designed to operate.
Overview of Oracle Names
Using Oracle Names requires that you adhere to a set of organizational rules. The two most significant organizational entities when you are using Oracle Names without the Dynamic Discovery Option are domains and administrative regions.
The following section discusses how Oracle Names 2.0 architecture is designed to function on most SQL*Net networks composed of clients and databases.
Note: The difference between Oracle Names version 1.0 and version 2.0 is the Dynamic Discovery Option. If you choose not to use the Dynamic Discovery Option, then the Names Servers are basically the same. Both versions are compatible with services on SQL*Net version 2.0 and above.
Basic Oracle Names Architecture
Architecturally, Oracle Names is a network service that provides name resolution to Oracle clients and servers. The Oracle Names service consists of one or more administrative regions. An administrative region is a set of global object names and Oracle Names Servers that are administered together through a single installation of Oracle Network Manager.
Each administrative region has a single installation of the Oracle Network Manager through which Oracle Names and other Oracle network products can be configured. The tool enables the administrator to configure and administer all database listeners, global database links, clients, Interchanges, and Names Servers in that administrative region.
Each administrative region has:
- one or more Oracle Names Servers
- one or more databases, listeners and clients
Figure 3 - 1 shows the relationship of the components described above with a single administrative region.
Figure 3 - 1. Components of a Network Using Oracle Names
Without the Dynamic Discovery Option
Oracle Network Manager creates a network definition based on input from the administrator, then generates configuration files that can be fine tuned for each client.
Components of a Name Server
The Oracle Names Server is a network service comprised of multiple components. Each Oracle Names Server without using DDO contains:
- system and topology data--includes the network data and addresses of Names Servers in other administrative regions. (Network data includes all communities and MultiProtocol Interchanges in the entire network, and Names Server addresses in the root administrative region.)
All cache data is always in memory to guarantee high performance.
- forwarder --takes queries for names in foreign regions and forwards the query on to the appropriate Names Server.
Figure 3-2 shows the components of the Names Server without using the DDO and their relationships.
Figure 3 - 2. Oracle Names Server Components
The sequence of steps involved in the process of resolving a global name is outlined in the sections on resolving global names later in this chapter.
Network Models
There are two simultaneous views of the layout of the network that should not be confused:
Figure 3 - 3. Community-Based Network Model
Note that EANIE and MOE are in the same community but different domains. EANIE MEANIE, and MINIE are all in the same naming domain, but are in different MultiProtocol Interchange community combinations (TCP/IP and DECnet, respectively).
In this example, the two communities, MultiProtocol Interchange, and the four database services comprise the network data entered into the Network Manager.
Figure 3 - 4. Domain-Based Network Model
Be sure you understand the difference between the community-based network and the domain-based naming model before configuring the network.
Naming Models
There are two basic models for naming objects in the network:
- Hierarchical naming model
Flat Naming Model
All names are unique within a single domain--the WORLD domain. The WORLD domain is predefined in the Oracle Network Manager for customers choosing a flat naming model.
Note: A flat naming model should be used when the actual number of services is small (under 100), when the likelihood of future growth of network services is minimal, and the entire SQL*Net network is centrally administered.
Figure 3 - 5 shows a flat naming model. The actual database service names are appended with ".WORLD" as in CONFIG.WORLD, FLIGHTS.WORLD, etc.
Figure 3 - 5. Flat Naming Model
All names in the WORLD domain must be unique. The Network Manager has a validation feature that ensures that all names you enter are unique.
Hierarchical Naming Model
You can divide names into a hierarchical structure to allow for future growth or greater naming autonomy. For example, if a requirement is that administrators in Europe must be able to assign names without consulting US administrators, they can do so from within different domains. This does not mean they must maintain different administrative regions, just different domains. A single administrative region can contain and thus control many domains.
Domains
All network names include one or more domains. A domain is a group of machines and network services. Domains are usually hierarchically related for organizational and administrative purposes. However, all network names could instead reside in a single domain--the WORLD domain.
The top level domain is the predefined root domain. All other domains are hierarchically below the root.
Note: The WORLD domain always appears in Network Manager. Because it is not used in hierarchical configurations, however, it is not shown in the following figures.
Figure 3 - 6 shows a hierarchical naming model with five domains: the (ROOT) domain, ACME domain, US.ACME, EUROPE.ACME, and ROW.ACME (Rest of World) domains.
Figure 3 - 6. Hierarchical Naming Model
Within each domain all names must be unique, but across domains they can be repeated. Notice that both WEATHER and HISTORY are repeated, but the full global names are unique (that is, HISTORY.ROW.ACME vs. HISTORY.EUROPE.ACME).
Network domains are similar to file directories used by many operating systems (such as UNIX) in that they are hierarchical; however, unlike file systems, network domains may or may not correspond to any physical arrangement of databases and other objects in a network; they are name spaces.
You can extend this hierarchy to any number of levels (for example, you could divide EUROPE further into UK, GREECE, and so forth.) but each additional level increases the knowledge users must retain to request names.
Dividing the set of names into three domains does not necessarily require three administrative regions. Administrative regions simply represent individual Network Manager installations. ACME may well determine that names can be assigned (or decided upon) by the administrator in EUROPE or ROW, but forwarded to the administrator at the ACME world headquarters in Boise, Idaho to be entered into the Network Manager.
Default Domains
Each client has a default domain in the naming model. The default domain is the domain within which most of the client's name requests are conducted. This is usually the domain the client resides in, but it could 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 will be automatically appended to the database service or database link name requested.
Figure 3 - 7 shows a client with a default domain of EUROPE.ACME.
Figure 3 - 7. Default Domains
For more information on domains, refer to Understanding SQL*Net and Oracle7 Server Concepts.
Multiple Domains
Multiple domains are related hierarchically from the 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, UK, and so forth. Each Oracle Names system is responsible for at least one domain, but will commonly have more.
Note: Do not confuse domains with SQL*Net communities. A SQL*Net community is a group of machines that can communicate using the same transport protocol. Clients, servers, Interchanges, and Names Servers can be members of one or more communities; however, they can be members of only one domain.
Administrative Regions
A network is made up of one or more administrative regions. Network objects are configured within administrative regions. Each administrative region contains:
- an installation of the Network Manager
- one or more Oracle Names Servers
- one or more network services or database links
Each administrative region contains one or more Oracle Names Servers. Names Servers are used to translate global service names into their network addresses. Although having just one Names Server per administrative region is technically allowed, at least two Names Servers per region are recommended to provide highly reliable access to the details of the network.
A network can be administered with one of the following types of regions:
- central administration (one administrative region)
- delegated administration (several administrative regions)
Every region must have a unique name. The region, although it contains domains, is defined to "reside" in one of the domains that it contains. The region name is formed by appending one of the domain names onto the end of the region name. For example, a region containing the US.ACME and UK.ACME domains could be called either region_name.US.ACME or region_name.UK.ACME. A name outside that region, such as region_name.CA.ACME, would be rejected. (The Network Manager's validation feature would disallow an invalid region name.)
Central Administration
A central administrative region has a single installation of the Network Manager.
Central administration can use either the flat or hierarchical naming model. Figure 3 - 8 shows two alternative centralized administrative region configurations.
Note: Most customers with small installations may prefer to use central administration with a flat naming model. Or, it might be more beneficial to your network to use Oracle Names with the Dynamic Discovery Option. See the section "Choose Whether to Use the Dynamic Discovery Option"![[*]](jump.gif)
for more information.
Figure 3 - 8. Two Centralized Administration Alternatives
Each Names Server in an administrative region resolves address requests for that region. In the most common case of a single, central administrative region, all Names Servers contain identical data, and give identical results.
As changes are made to network objects within a particular administrative region (such as adding or changing database or Names Server addresses) the network administrator refreshes the cache of the Oracle Names Servers using the Network Manager (or the Names Control Utility). Each of the Names Servers then gets a new copy of the relevant contents of the network definition database, making the data quickly available to all clients.
Delegated Administration
If an organization is diverse enough that central administration is not possible, or if the volume of data being maintained warrants decentralization, configuration and administration can be delegated to any number of sites. To delegate administrative regions, you must have a hierarchical naming model because each administrative region must control one or more different domains.
Each administrative region includes an installation of the Network Manager. Each network definition created with the Network Manager must include references to other administrative regions as discussed later in this section.
In the case of multiple administrative regions, the network administrator uses the Network Manager to record the details of the local region, and Names Server addresses and domains of the root region, and any child regions (of the local region).
Delegating Administrative Regions
Administrative regions can be "delegated" from the top of the hierarchy in any granularity down to the number of domains in the naming model. For example, a naming model with ten domains can have between one and ten administrative regions. The domain at the top of the 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.
All administrative regions other than the root are hierarchically delegated directly or indirectly from it. Figure 3 - 9 shows a network with five domains and three administrative regions: the ROOT, and two delegated regions (DR1, DR2).
Note: The WORLD domain always appears in Network Manager. Because it is not used in hierarchical configurations, however, it is not shown in the following figures.
Figure 3 - 9. Delegated Administrative Regions
Rules for Delegating:
Figure 3 - 10. Invalid Administrative Regions
In this example, the DR2 region's domains are not contiguous, that is, they do not share the same parent domain. (ASIA's parent is ACME, and FRANCE's parent is EUROPE.) Even though the EUROPE domain can be traced back to the common ancestor domain ACME, it is in a different administrative region than the FRANCE domain. If the DR1 and DR2 regions are combined into one region, it becomes valid because the EUROPE, ASIA, and FRANCE domains now all share a common ancestor domain--ACME.
The infrastructure required to support the root region and delegated regions is discussed in the next two sections.
The Root Administrative Region
The root administrative region has a special role in the Oracle Names system. Hierarchically, it is the common thread among all delegated administrative regions. Additionally, it is where all backbone data is maintained.
The root administrative region requires:
The communities, and the Interchanges connecting them, and the Names Servers in the root region define the limits of the network.
Data does not exist within the root domain (ROOT) itself. If the root administrative region contains only the root domain, then this region will have no database service names, database link names, or aliases. However, if the root administrative region contains other domains, then data can exist in the other domains.
Delegated Administrative Regions Below Root
All administrative regions below the root are considered delegated administrative regions. Each delegated region requires:
- all communities in the network
- all MultiProtocol Interchanges in the network
- addresses of Names Servers in the root administrative region
- The domains and Names Server addresses in its own (local) administrative region.
Communicating Changes to Administrators of Delegated Regions
In a delegated administrative installation, changes to the initial network (backbone) data (which includes all communities and MultiProtocol Interchanges in the entire network, and all Names Servers in the root administrative region) need to be sent to all the administrators of the delegated regions. This should be done by the root region administrator. Working out a policy to handle the changes might include how much time in advance each administrator should be informed, when each administrator is expected to make the changes, and the details of the changes themselves.
When the group of administrators is small, a simple format like an e-mail mailing list, or one or more telephone conference calls, or both informing all administrators of the changes should be sufficient.
Using the Oracle Network Manager to Define the Network
The Oracle Network Manager is the "window" into the contents of the administrative region. Refer to the Oracle Network Manager Administrator's Guide for information on how to create a network definition. You use the Network Manager to configure:
For a given network, all of these objects are stored together in the Network Manager network definition database. In a network without Oracle Names, the network definition can be saved to either a database or an operating-system file; however, with Oracle Names, the network definition must be saved in a database.
How Names are Resolved for a Client/Server Connection in a Central Region
The sequence of steps in name resolution is very straightforward in the single, central administrative region configuration.
Role of the Client
The client is the software that requests the name to be resolved. The name itself typically comes from the user's application, or the actual user.
In a client-server connection, the client is obvious. In a distributed database, each database link is treated as a separate connection identical to a client-server connection. In general, the initiating server is considered the "client" for each outgoing database link.
When the name is successfully resolved, the client uses it to connect to the intended destination. All interaction with the Names Server and use of the results is transparent to the user. Only an unsuccessful attempt is seen by the client or user.
Role of the Names Server
The Names Server has a single purpose: to resolve, or assist in resolving, a client-initiated name request. It interprets the request, then looks up the name in its cache, or it calls a Names Server in another region. The response or error conditions are passed back to the client.
Figure 3 - 11 shows a client requesting access to a Names Server named POULTRY and a Names Server providing the answer. A flat naming model is assumed.
Note: The service name is the same as the global object name. For example, a global database name might be POULTRY.WORLD, which is also the service name.
Figure 3 - 11. Client-Server Connection
The sequence of events is as follows:
1. The client application issues a connection request to SQL*Net of the form:
sqlplus scott/tiger@POULTRY
where POULTRY is a database service name defined in the Oracle Names Server.
SQL*Net determines from the client configuration in the SQLNET.ORA file that the client's default domain is WORLD and the preferred Names Server is the one shown. SQL*Net sends the Names Server a request to resolve the name POULTRY.WORLD.
2. The Names Server receives the request, looks it up in the cache, then sends the response back to the client.
3. The client receives the answer and substitutes the address in place of the initial name POULTRY.
4. The client contacts POULTRY and establishes a standard SQL*Net client-server connection.
Only step 1 and the acknowledgement of Step 4 are seen by the user, unless an error occurs.
For information about resolving a name across delegated administrative regions, see "How Names are Resolved in Delegated Administrative Regions", in Appendix C.
How Names are Resolved for a Distributed Database Connection
in a Central Region
Name resolution in a distributed database in the single administrative region configuration is similar to names resolution in a decentralized administrative region. The global database link name must be the same as the global database name. (Refer to the section "Distributed Database Management" in Understanding SQL*Net for more information on how database links are resolved.
Figure 3 - 12. Distributed Database Connection
The sequence of events is as follows:
1. Server TOM receives the SQL statement shown and checks its data dictionary for a private or public database link called JERRY. When it does not find one, SQL*Net determines from the client configuration in the SQLNET.ORA file that the client's default domain is WORLD and the preferred Names Server is the one shown. SQL*Net then sends the Names Server a request to resolve the database link name JERRY.WORLD.
2. The Names Server receives the request, looks it up in the cache, then sends the response back to the server TOM.
3. Server TOM receives the answer and substitutes the response in place of the initial name.
4. Server TOM contacts server JERRY and establishes a standard SQL*Net distributed database connection.
