Advanced Topics
This chapter discusses the following advanced topics in detail:
- Defining a client profile
- Delegating authority from a central administrative region
- Remote domains and Names Server hints
- Defining local and foreign domains in Network Manager
- How names are resolved in delegated administrative regions
- Defining objects in foreign domains
Defining a Client Profile
All clients that belong to the same community, use the same Interchanges, and the same Names Servers can share a single client profile. Any variation requires a separate client profile.
Administrator`s Role
The administrator should advise each client as to which client profile is best suited to it. This takes basic planning of the network model in anticipation of how it will be used. As the details of the client profile change, the client must receive a new copy of the configuration files.
Consider the example in the following figure. The naming model is a basic hierarchy of two domains (DD1 and DD2), administered as a single administrative region (RAR). The network has two communities (C1 and C2), two Interchanges (I1 and I2), and three Names Servers (N1, N2, and N3).
Figure C - 1. Sample Client Profiles
Fully extrapolated, this could lead to a very large number of client profiles. Table C-1 lists the possible client profiles for the three clients shown in the following figure.
Table C - 1. Possible Client Profiles
| Table C-1
| Client
| Communities
| Interchange
| Default Domain
| Names Servers
|
| Possible Client
| Client 1
| C1
| I1, I2
| DD1
| N1, N2
|
| Profiles for Figure
|
| C1
| I1, I2
| DD1
| N2, N1
|
|
|
| C1
| I1, I2
| DD2
| N1, N2
|
|
|
| C1
| I1, I2
| DD2
| N2, N1
|
|
|
| C1
| I2, I1
| DD1
| N1, N2
|
|
|
| C1
| I2, I1
| DD1
| N2, N1
|
|
|
| C1
| I2, I1
| DD2
| N2, N1
|
|
|
| C1
| I2, I1
| DD2
| N2, N1
|
|
| Client 2
| C2
| I1, I2
| DD1
| N3, N2
|
|
|
| C2
| I1, I2
| DD1
| N2, N3
|
|
|
| C2
| I1, I2
| DD2
| N3, N2
|
|
|
| C2
| I1, I2
| DD2
| N2, N3
|
|
|
| C2
| I2, I1
| DD1
| N3, N2
|
|
|
| C2
| I2, I1
| DD1
| N2, N3
|
|
|
| C2
| I2, I1
| DD2
| N3, N2
|
|
|
| C2
| I2, I1
| DD2
| N2, N3
|
|
| Client3
| C1, C2
| -
| DD1
| N1, N2, N3
|
|
|
| C1, C2
| -
| DD1
| N1, N3, N2
|
|
|
| C1, C2
| -
| DD1
| N2, N1, N3
|
|
|
| C1, C2
| -
| DD1
| N2, N3, N1
|
|
|
| C1, C2
| -
| DD1
| N3, N1, N2
|
|
|
| C1, C2
| -
| DD1
| N3, N2, N1
|
|
|
| C1, C2
| -
| DD2
| N1, N2, N3
|
|
|
| C1, C2
| -
| DD2
| N1, N3, N2
|
|
|
| C1, C2
| -
| DD2
| N2, N1, N3
|
|
|
| C1, C2
| -
| DD2
| N2, N3, N1
|
|
|
| C1, C2
| -
| DD2
| N3, N1, N2
|
|
|
| C1, C2
| -
| DD2
| N3, N2, N1
|
This simple case can result in as many as 28 client profiles if you include all "not-null" permutations.
In practice, however, there are usually very few client profiles to describe all clients. The entire network shown may be serviced by having all clients be defined as:
Table C - 2. Possible Client Definitions
| Table C-2
| Client
| Communities
| Interchange
| Default Domain
| Names Servers
|
| Actual Client Profiles
| Client 1
| C1
| I1, I2
| DD1
| N1, N2
|
| Used in Installation
|
| C1
| I2, I1
| DD2
| N2, N1
|
|
| Client 2
| C2
| I1, I2
| DD1
| N1, N2
|
|
|
| C2
| I2, I1
| DD2
| N2, N1
|
|
| Client 3
| C1, C2
| -
| DD1
| N1, N2, N3
|
|
|
| C1, C2
| -
| DD2
| N2, N3, N1
|
Each client could then be identified based on which of these six client profiles best fits its needs. Basic load balancing is achieved on the Interchanges and Names Servers by making the different domain members use different preferred Interchanges and Names Servers first. Client 3 does not require Interchange definitions because it can connect to all nodes directly on C1 or C2, and thus would never use the Interchange.
During configuration, the SQL*Net administrator creates a default client profile for each of the communities and domains in the network. In many cases these are adequate for all clients sharing those properties.
Synchronizing Clients
The client profile consists of two configuration files-- TNSNAV.ORA which defines the Interchange preferences, and SQLNET.ORA which defines the Names Servers preferences.
Physically, clients may each have a copy of the files, or they may share a copy mounted on a distributed file system such as PC LAN or Network File System (NFS). In the latter case, the administrator can handle all initial distribution and updates without any exposure to the user. When the clients have individual copies, there are many ways to distribute the files. See Oracle Network Manager Administrator's Guide for information about distributing the configuration files.
Delegating Authority from a Central Administrative Region
The example in Figure C-2 is an illustration of a central region delegating authority to two administrative regions--US and UK. This example is used throughout the following sections.
Figure C - 2. A Central Region Using a Hierarchical Naming Model
The tasks an administrator must perform to delegate authority to another region are:
- Save and give a copy of the current network definition to the administrator of the delegated region.
- Decide which domains are going to be delegated.
- Delete any database/listener definitions which are "owned" by the delegated region.
- Mark the delegated domains as foreign in your network definition.
- Create a foreign region for each delegated region and allocate the delegated domains to those regions.
The tasks a delegated region's administrator must do in order to bring the definition in line with the "rest of the world" are:
- Mark domains in his or her administrative region as local.
- Delete databases and listeners that are not in the local region.
- Mark all other domains not in the local region as foreign.
- Create a foreign region for the ROOT region. Add all the ROOT region's domains into this region.
Note: Each region's administrator must have a separate version of the Network Manager in which to create or update the network definition.
To delegate administrative authority from one single, central administrative region (using a hierarchical naming model) to two administrative regions, use the following procedures.
Define the Local Region's Name
Create the region name by appending one of the domains that the region contains onto the end of the region name. It doesn't matter what domain name is appended to the region name, as long as it is one of the domains that reside in the region. By default, Network Manager puts the local region into the WORLD domain. For example, ROOT_REGION.ACME.COM would be an appropriate choice for this example. To define the name of the local region:
1. Select Region on the Network Manager: Object List window, and select LOCAL_REGION.WORLD, then select Edit. Change the name of the local region to ROOT_REGION.ACME.COM. To do this, change the name to ROOT_REGION and select Choose to display a list of domains in this region, then choose ACME.COM.
Because ACME.COM is one of the domains in the root region, it can be used to create the region name; in this case, ROOT_REGION.ACME.COM.
Note: If you are using a hierarchical naming model, it is recommended that you select a domain name other than WORLD.
After receiving a copy of the root region network definition, each of the delegated region administrators must update their network definitions to reflect their new region names, for example, US_REGION and UK_REGION.
Mark Domains in Local Region as Local
Each administrator must designate all domains in the local region as local. The root region must also do this after delegating authority to another region.
To mark domains in a local region as local:
1. Select the Region property sheet from the Network Manager: Object List window. Make sure all domains within the local region are listed in the Domains within Region list box. If necessary, go to the Domain property sheet for the domain, and make sure it is not marked as a foreign item.
Delete Databases No Longer in the Local Region
After receiving a copy of the network definition from the root region administrator, both the UK and the US administrators must delete databases and listeners that are not in their respective regions. Similarly, the root region administrator must delete databases and listeners that are no longer in the root region.
To delete databases from the local region:
1. Open the network definition for the local region.
2. Select the Database property sheet from the Network Manager: Object List window. Delete all the listeners and databases no longer in the local region. For example, the root administrator must delete all databases in the US and UK region, the UK region must delete databases in the root and US regions, and so forth.
3. Upon deleting databases and listeners, messages display indicating that the database will be invalidated, and asking whether you want to proceed. Select Yes.
There should no databases or listeners in any foreign regions in the local region's network definition.
Marking Domains Not in Local Region as Foreign Domains
The root administrator must mark all delegated domains as foreign in the root region's network definition. Similarly, the delegated administrators must mark all domains not in their local regions as foreign. For example, the UK administrator must mark all domains in the root region as foreign, and all domains in the US region as foreign.
To mark all foreign domains as foreign, individually select all foreign domains on the Network Manager: Object List window and mark them as foreign on their respective Domain property sheets.
1. Open the network definition for the local region, if it is not already open.
2. On the Network Manager: Object List window, select Domain, then select a foreign domain in the Names column. Mark all foreign domains as foreign by selecting Foreign Item.
The Network Manager displays a screen indicating it will update several different network objects, and a message asking "Do you want to proceed?" Select Yes.
On the Region property sheet, you should not see any foreign domains listed in the Domains within Region list box. Also, you should not see any Names Servers that are not in the local region.
Note: WORLD must also be marked as a foreign domain from the point of view of the UK and US regions. The WORLD domain is local to the ROOT region, even though it is not used in hierarchical configurations.
Define Foreign Regions
The root administrator and the delegated region administrators must define foreign regions and designate the domains as being in a specific foreign region.
To create a foreign region:
1. Select Local Region on the Network Manager: Object List window to display the Local Region property sheet.
The only domains that should display in the Domains within Region list are domains that are local to this region. The only Names Server(s) that should appear are those local to this region.
2. To define a second region, select Foreign Region from the Create Menu in the Menu Bar.
A default name appears which you can change if needed.
3. Select the Domains page and choose from the available list all of the domains that are part of this region.
4. Return to the General Page and define a name for this new region.
Do this by selecting any of the domains that the region contains. The domain name you select will be appended onto the end of the region name; for example, US_REGION.UK.ACME.COM.
For example, from the point of view of the UK administrator, a foreign region would be the root region or the US region.
Periodically, while updating the network definition, a screen may display indicating that network objects will be deleted and updated. Changes made in the network definition are automatically propagated to other property sheets in the same network definition. For example, the foreign region property sheet called UK_REGION should display NameServer_2.UK.ACME.COM.
Every region (other than ROOT) must define the root region as a foreign region in its network definition. The domains contained in the root region (ROOT, COM, ACME.COM, and WORLD) must be allocated as foreign domains. Upon defining the root region as a foreign region, Names Servers associated with the foreign region will be displayed in the Names Servers list box.
An administrative region only needs to have a record of network objects in its own region, in any child regions directly below it, and the root region. Foreign regions that have a sibling relationship do not have to be defined as foreign regions. For example, the UK region does not have to define the US region as a foreign region because the US region's domains are not children of the domains in the UK. In fact, the UK region only needs to have in its network definition addresses for any Names Servers in its own region, and any Names Servers in the root region.
The root administrative region must have in its network definition the addresses of Names Servers in the root region, and Names Server addresses of any direct child regions only.
Remote Domains and Names Server Hints
A domain that is not defined in the local region, the root region, or a direct child region may be listed in the Domains within Region list. Because the domain is not defined in the local region, root region, or any direct child regions, this domain is termed a remote domain or Names Server hint which tells the local region that this is a domain it will probably want to communicate with. If you define a remote domain, then the address of the Names Server handling that domain is "pre-cached". This saves the user from the performance overhead of the first request for a network object address within the remote domain.
When the Names Server starts up, it retrieves the Names Server addresses from that remote domain. For example, if the UK.ACME.COM domain is defined as a remote domain in the US region's network definition, when the US region asks for the address of HR.UK.ACME.COM, the US region's Names Servers will already have the address of the Names Servers in the UK region (which contains the UK.ACME.COM domain).
If this domain was not defined as a remote domain in the US region's network definition, when a client wants to connect to a network service in the UK.ACME.COM domain, the Names Server on their behalf will have to go first to the ROOT and ask the ROOT region's Names Server for the address of the UK region's Names Server.
Defining Local and Foreign Domains in Network Manager
The network administrator must enter the information for domains and other related data within that administrative region by using Network Manager. Domains within each administrative region are known as local (or "domestic") domains from that region's point of view, while all other domains are foreign.
Names are often retrieved across regions, resulting in data from one administrative region entering the Names Servers of another region. Clients never communicate directly with Names Servers in another region; rather, they communicate with a local Names Server and it forwards the request to the desired location. This process is described in more detail in the sections on resolving names to foreign domains.
The following figure shows a client with a default domain of EUROPE.ACME.
Figure C - 3. Domestic and Foreign Domains
From the point of view of the client in the AR2 region, the EUROPE.ACME and the ROW.ACME domains are domestic and the ACME and US.ACME domains are foreign. For example, the names ART.EUROPE.ACME or PASSPORTS.ROW.ACME are resolved directly using the client's local Names Server. Requests for DEATH.US.ACME or TAXES.US.ACME, however, can only be answered by a Names Server in AR1, because they refer to the foreign domain US.ACME. The client would contact a Names Server in the AR2 region, which in turn would forward the request to a Names Server in AR1.
Caching Foreign Data
When data is retrieved from a foreign region, the local Names Server returns the response to the client, and keeps the foreign data in its cache for a period of time. Foreign data that is retrieved and cached includes database addresses from foreign regions, and Names Server addresses that are not part of the system data.
Because the data is stable (that is, it is not likely the data will be redefined frequently relative to the Time to Live value), caching data retrieved from another region is a low-cost, effective way to increase performance in the system. If another user requests the same name, the local Names Server can respond with the details from the cached data without forwarding the request.
Data is not only cached in the Names Server supplying the client, it is stored in all Names Servers the name comes in contact with. Whenever data is encountered in any way, subsequent requests will be faster if more Names Servers know the answer.
Cached Foreign Data's Time To Live (TTL)
If all foreign data were stored indefinitely in other Names Servers, when changes occurred in a particular administrative region, this would invalidate many cached names in many Names Servers in the network.
Because of this, foreign names are only stored in the cache for a predetermined length of time (default is one day) after which they are dropped. This is known as the cached data's Time To Live (TTL) which literally counts down until the time expires and the name is dropped.
The implications are that the foreign data in the cache is never older than the configured TTL. By default, each Names Server will query once per day for each foreign name in its cache, and it will query the Names Server in the region where the foreign name was defined. Once a Names Server gets a foreign name it is valid for the length of time in the configured TTL. After that, if a client requests the name, the Names Server will query the region where the data is considered local.
The actual TTL value for a server is configured by using the Network Manager when the region is defined. All data in the region has the same TTL. You should choose the value based on the likelihood that the data will change, and the anticipation that it will be requested from other regions. Whenever a response is passed between regions, a TTL is set and begins counting down.
Short TTLs propagate changes more quickly, but decrease overall performance because more queries must be resolved at the data source; that is, names must be resolved by retrieving them from the Names Server in the region where the data is considered local.
In the event that source data in a particular region is changed by a network administrator, and the cached data is out of date for the remainder of the TTL, that name can be dropped (before the TTL expires) using the NAMESCTL command FLUSH_NAME.
Authoritative vs. Non-Authoritative Responses
Retrieved data is considered authoritative or non-authoritative.
Many administrators get nervous at phrases like "not guaranteed". Remember that non-authoritative data is simply a performance optimization to avoid having to retrieve data from its authoritative source every time. If the data in a particular Names Server is out of date (that is, the TTL has expired), the Names Server would look up the data in the region where the data is local.
How Names are Resolved in Delegated Administrative Regions
The term "delegated" refers to a network with multiple administrative regions. Many sites have a single administrative region.
Name resolution among regions is a highly optimized process that minimizes communication between servers. In the absolute case, a region can find any other region by asking a Names Server in the root administrative region for the address of a Names Server in that region. Like foreign name caching, data such as local Names Server addresses and delegated Names Server addresses are also cached (with a TTL) to avoid having to request this data each time a query is made. Also, like foreign data, only the first query to a region requires looking up a Names Server address; all subsequent requests from the local Names Server use the cached system data.
The following sections step through a simple and a complex case of name resolution across regions. Initially, the example assumes that no cross-region traffic has previously occurred, then subsequent requests are described.
Resolving Names from Foreign Domains
When a name is requested from outside the current administrative region, the following process occurs:
1. The Names Server looks in its foreign data cache for the address of the Names Server it believes is most likely to be authoritative for that name.
2. If the Names Server does not have the address of this Names Server, it queries the root administrative region for the addresses of Names Servers in that region. For the simple case, assume the root returns the address of the Names Server for that region (the authoritative Names Server).
3. The Names Server then forwards the request to the authoritative Names Server and the result is returned.
4. The Names Server stores that name and result in its foreign data cache, then returns the result to the client.
In most cases this is a simple transaction. Consider the following example:
1. The client in AR2 encounters the name DEATH.US.ACME and sends it to its preferred Names Server in the AR2 region.
2. The Names Server in AR2 determines that the domain is foreign and looks in its system data cache for the Names Server address of the foreign domain in AR1.
3. In this case, the foreign region is the root region (AR1), thus the request is forwarded to a Names Server in AR1 and the result is returned to the Names Server in AR2.
4. The local Names Server in AR2 stores the name in its foreign data cache and returns the name to the client.
No foreign system data is cached since the root administrative region's Names Servers are already part of every delegated region's defined system data.
Resolving Multi-Level Names Across Administrative Regions
Finding an authoritative server in a very large distributed administrative hierarchy can require iteration. If, for example, a Names Server asked for the address of a Names Server servicing a grandchild region of the root (two levels down), the root may only know the addresses of one of its direct children, which in turn can supply its children's addresses. In other words, the root forwards the request to its child region, which would forward the request to its child region for the answer.
Figure C - 4 shows this process and the sequence of events assuming that no data has been previously cached.
1. The client sends request to preferred Names Server in its local region (DR1).
2. The preferred Names Server in DR1 issues request for the Names Servers authoritative for the destination server (in region DR2.1).
Figure C - 4. Network Messages in a Multi-Level Foreign Name Resolution
3. The root Names Server does not have the answer (because root only knows about its direct child regions), but forwards the request to a Names Server in region DR2.
4. The receiving server in DR2 forwards the request to a Names Server in region DR2.1.
5. The name is retrieved from its authoritative Names Server in DR2.1.
6. The names Server in region DR2 caches the answer and returns it to the root.
7. The root caches the answer and returns it to the preferred Names Server in region DR1.
8. The preferred Names Server caches the answer and returns it to the client.
9. The client establishes a connection to the destination server.
For the duration of the TTL, subsequent requests for the same name to the same Names Server do not require step 9.
Also for the duration of the TTL, any subsequent requests in DR1 for names in the DR2.1 region are resolved by communicating directly with its servers.
More Examples of How Names are Resolved Across Administrative Regions
Additional examples will make this process clearer. Following are two examples: one which resolves a database service name across regions, and the second which resolves both a database link and a database service name across regions.
Note: These examples extend the naming model enough to explain detailed cross-region name resolution. If you are not using more than one level of delegation, it is not important that you read the sections on multi-level delegation. In practice, five level domain naming models, and three level administrative region delegation are rare.
Figure C - 5 shows a client in the administrative region AR4.1 (default domain JP.ROW.ACME) connecting to the database server BLUE.GA.US.ACME, which performs a distributed query to the database server JAY.LONDON.UK.EUROPE.ACME.
Figure C - 5. Name Resolution in a Complex Administrative Hierarchy
1. When the client issues the request, the Names Server in the AR4.1 region looks at the domain name (GA.US.ACME), recognizes it as foreign (not local), and issues a request to a root Names Server for Names Server addresses in the region with GA.US.ACME.
2. A root Names Server forwards the request to AR1.
3. The name is resolved and returned to a Names Server in the root region.
4. The Names Server in the root region returns the request to AR4.1.
5. The Names Server in region AR4.1 returns the name to the client.
6. The client establishes a SQL*Net connection to the database server BLUE.GA.US.ACME.
Note that the AR4 region is not involved. Resolution goes directly from the requesting region to the root, then to AR1 directly. Subsequent requests within AR4.1 for the same name will be resolved from the Names Server cache in AR4.1 until the Names Server TTL expires. (Refer to the "Cached Foreign Data Time to Live (TTL)" section earlier in this appendix) Subsequent requests for other names in the AR1 region by clients in AR4.1 will not contact the root.
The same process is followed when a user on the database BLUE.GA.US.ACME in AR1 uses the global database link JAY.LONDON.UK.EUROPE.ACME.
1. The database BLUE.GA.US.ACME contacts its preferred Names Server (in region AR1) with a request to resolve JAY.LONDON.UK.EUROPE.ACME.
2. The preferred Names Server in AR1 contacts the root region for the addresses of the servers in region AR3.1.
3. Because the root doesn't have them, it forwards the request to the AR3 region of the Name Server.
4. The Names Server in region AR3 contacts a Names Server in region AR3.1 with the name to be resolved.
5. The Names Server in region AR3.1 resolves the name and returns it to the server in region AR3.
6. The Names Server in region AR3 stores the name in its cache and returns the name to the root.
7. The root region's Names Server caches the name and returns it to AR1.
8. The Names Server in AR1 stores the name in its cache and returns it to the server BLUE.GA.US.ACME.
9. The server BLUE.GA.US.ACME establishes a connection to the server JAY.LONDON.UK.EUROPE.ACME. The global database link is complete.
Subsequent requests for the JAY.LONDON.UK.EUROPE.ACME global database link will be identical to the process in steps 1 and 8. As a local name, it is already optimized. Subsequent requests for the name JAY.LONDON.UK.EUROPE.ACME will be resolved in the foreign data cache. Subsequent requests for other names in the AR3 or AR3.1 regions will be made directly to those regions--the root region is not required.
Optimizing for Repeated Queries
The Oracle Names system is specifically optimized to ensure that the costs incurred in examples like the ones above are minimized. After a small number of inter-region queries, a Names Server will usually know all of the addresses of the Names Servers in the regions it will contact that day. It is very infrequent that the number of messages shown in the previous example is required.
Table C - 3 is a summary of the Names Servers involved in the client/server connection between the client in region AR4.1 and the server BLUE.GA.US.ACME in region AR1. It includes the Names Servers involved from each region, the information they learned (cached), and what they already knew (from the network definition database).
| Names Server in:
| Learned
| Already Knew
|
| region AR4.1
| Service name data:
BLUE.GA.US.ACME
Addresses of Names Servers in region AR1
| Addresses of Names Servers in region ROOT
|
|
|
|
|
|
|
|
|
| region AR1
| Nothing
| Addresses of Names Servers in region ROOT
Service name data:
BLUE.GA.US.ACME
|
|
|
|
|
|
|
|
|
|
|
|
|
Table C - 3. Foreign Data Storage in Name Resolution between the Client and BLUE.GA.US.ACME
Similarly, resolution of the global database link name JAY.LONDON.UK.EUROPE.ACME from the Names Server in the AR1 region is performed through the ROOT region, and down the hierarchy with the following foreign data stored, as shown in Table C - 4.
| Names Server in:
| Learned
| Already Knew
|
| region AR1
| Service name data: JAY.LONDON.UK.
EUROPE.ACME
Addresses of Names Servers in region AR3.1
Addresses of Names Servers in region AR3
| Addresses of Names Servers in region ROOT
|
| region AR3.1
| Nothing
| Addresses of Names Servers in region ROOT
Service name data: JAY.LONDON.UK.EUROPE.ACME
|
| region AR3
| Service name data: JAY.LONDON.UK.EUROPE.ACME
| Addresses of Names Servers in region ROOT
Addresses of Names Servers in region AR3.1
|
Table C - 4. Foreign Data Storage in Name Resolution between BLUE.GA.US.ACME and JAY.LONDON,UK.EUROPE.ACME
Defining Objects in Foreign Domains
In a network with distributed administration, the need to define aliases for network objects in foreign domains will occasionally arise. This need is most common with database links, as any user can create database links in any database where the user has an account and adequate database privileges. For this reason, the network administrator may need to define an alias for a global database in that foreign domain in Network Manager.
For instance, assume the following example is extended to include a second global database link in the Names Server in the AR1 region called HR, as shown in Figure C - 6.
Figure C - 6. Alias for a Database Defined in a Foreign Domain
If the database user happens to be in Japan, the name HR.GA.US.ACME can be added through the administrator in region AR4.1 by:
- defining the foreign domains US.ACME and GA.US.ACME
- creating the alias HR for the database BLUE within the foreign domain GA.US.ACME
Foreign domain definitions only require the name; all other system data is looked up by Oracle Names.
Optimizing Performance with Foreign Domain Lookup
To optimize Names Server performance, the network administrator defines all foreign domains in Network Manager. When you start a Names Server, it collects all foreign domain references defined in Network Manager for its administrative region, and requests the addresses of the Names Servers for their regions using the process described earlier in this chapter. The results are stored in the cache in anticipation of names in the foreign domain being requested. Any requests by clients for data in that administrative region can then forward name requests to the regions containing the foreign domains directly, without using the root domain to find them.
This initial operation is a series of system queries to store the foreign server addresses in advance of a foreign domain name request. The result is a performance optimization when clients request names from that domain.
Using the example in following figure:
- All Names Servers in region AR4.1, at startup, request the addresses of the Names Servers in the AR1 region from the root region. (This is because the GA.US.ACME domain is defined as a foreign domain in the network definition in the AR4.1 region.)
- A root region server returns the Names Server addresses and they are stored in the system data cache in the AR4.1 region.
When the client requests the database BLUE.GA.US.ACME in the AR1 region, the request is forwarded from the Names Server in region AR4.1 directly to a Names Server in the AR1 region.
Foreign Data and Names Servers
All Names Servers in an administrative region share the same local (or "domestic") data as well as the addresses of Names Servers in the root region. All Names Servers in a particular region start with the same pre-defined data, for example, local database names, root region's Name Server addresses, and Names Server addresses in foreign regions. Any other information learned through answering queries will stay in an individual Names Server cache, but other Names Servers in the same region may not have the exact same information at all times. After running for a while, each Name server cache in a region will be unique.
Within a region then, each Names Server may behave differently when resolving a foreign name, depending on its previous experiences and the state of its cache. In all but the rarest occasions, the query results will always be the same.
Network Support
In a multi-community TNS network, choosing a multi-protocol node as a Names Server minimizes the number of nodes that need to be installed for redundancy. There is certainly no requirement that the Names Server run on a multiple protocol node; it is a matter of minimizing administrative overhead for complete TNS network naming service coverage.
