Understanding SQL*Net

Naming Considerations

When you name objects such as databases in networked environments, you need to make sure they are unique within the network. This can be a challenge if your company is large, and network administration is not handled centrally. You may be able to guarantee that all services in your building or jurisdiction have unique names, but that does not guarantee that the name is unique within the corporation. Your goal should be to avoid the occurrence of duplicate names if multiple independent TNS communities are joined by installing an Interchange between them.

Domain Names

Figure 3 - 3. Naming Domains at ACME

In this figure, each of the boxes represents a separate domain. The domains are related hierarchically; that is, FIN and HR are the children of HQ, which is one of the children of ACME. A network object (such as a database server or an Interchange) within a given domain has a unique name within that domain. This is generally manageable because one or at most a few people have authority to pass out names for that domain. The global name for that object includes the parent domains.

For example, consider the corporation shown in Figure 3 - 3. The sales organization (the SALES domain) could have a server named VAULT. The Human Resources group (the HR domain) could also have a server named VAULT. The global names of these servers would be unique. The Sales group's server would have the global database name:

VAULT.SALES.ACME

while the global database name of the Human Resources server would be:

VAULT.HR.HQ.ACME

Names can go to the company level (the ACME stem) or can go to the Internet level (for example, the ACME.COM stem) in support of inter-company communications such as mail or Electronic Data Interchange (EDI). If your organization belongs to the Internet, or you expect that it might join the Internet in the future, the domain names should include the appropriate stem (such as COM, GOV, or EDU).

Note: This naming structure applies whether you are using TNSNAMES.ORA name lookup files, Oracle Names Servers, or Oracle Native Naming Adapters (in conjunction with native name services) to resolve names to addresses. Every network object must have a global object name such as VAULT.HR.HQ.ACME.

If your organization already has global naming conventions, your network components should follow those conventions.

Note: Refer to the Oracle Names Administrator's Guide for a more detailed discussion of naming conventions.

Default Domain .WORLD Appended to Network Components

Oracle Network Manager automatically appends the domain .WORLD to the name of all network components unless you provide alternative domain names. See the Oracle Names Administrator's Guide for further information.

Hierarchical Domains Not Used by the Dynamic Discovery Option

If you are using Oracle Names release 2.0 and the Dynamic Discovery Option, the object names you provide are not interpreted as including hierarchical domains. A name such as VAULT.HR.HQ.ACME or PROD.WORLD is interpreted as a flat name that happens to include dots (.). Therefore, you must be particularly careful in assigning unique names in the network.

Note: If you are using the DDO in a network that has SQLNET.ORA files with default domain parameters included (from an earlier network definition), no default domain will be added to the object name if it contains a dot (.).

Default Domain

Unless you are using Oracle Names and the Dynamic Discovery Option, every client and server has a default domain listed in its SQLNET.ORA file. The default domain is the domain to which the majority of the clients' connection requests are directed. When clients connect to servers in the default domain, they do not need to specify fully qualified service names in their connection requests. For example, a client can connect to a database in its default domain with the service name (global database name) PROFITS.SALES.ACME.COM by specifying the following command:

% sqlplus scott/tiger@profits

However, if the PROFITS database is not in the client's default domain, the client needs to specify the fully-qualified service name (global database name) in the connection request:

% sqlplus scott/tiger@profits.sales.acme.com

Note: The default domain is not necessarily the same as the domain of the client itself. For example, clients in one domain may frequently access Oracle servers in another domain.

If you have a network configured for an older version of SQL*Net and you upgrade to a SQL*Net version 2.1 (or later) network, the older names are changed to include a domain. If you don't provide any domain information for the network, when you upgrade to release 2.1 or 2.2, the Oracle Network Manager provides the suffix .WORLD, the default flat domain name, to the network component names.

For example, you might have a database service name defined in version 2.0 as HRFACTS. The same database in release 2.1 and 2.2 would be defined as HRFACTS.WORLD.

Oracle Network Manager automatically includes the following parameter in the SQLNET.ORA file:

NAMES.DEFAULT_DOMAIN=WORLD

This parameter allows the version 2.0 database service name to be recognized as the same as the database service name defined in the release 2.1 (or later) network.

Note: If you are using Oracle Names release 2.0 and the Dynamic Discovery Option, no SQLNET.ORA file is automatically generated for each client and server, and therefore there is no default domain. If you want to include a default domain for compatibility with other parts of the network, you must create the appropriate parameter in a SQLNET.ORA file. To do so, you can either use Oracle Network Manager to create a SQLNET.ORA file for a group of similar clients, or use the SQLNET.ORA Editor, which is part of the Client Status Monitor, to create SQLNET.ORA files for individual clients. The Client Status Monitor is described in Chapter 4 of the Oracle Network Products Troubleshooting Guide.

See theOracle Names Administrator's Guide and Oracle Network Manager Administrator's Guide for further information.