3
Configuration Management Concepts

This chapter describes how configuration information for Oracle Net Services can be stored in localized configuration files or centralized in a directory server.

The topics covered include:

• Configuration Models
• Localized Configuration File Support
• Directory Server Support
• Oracle Names Support

Configuration Models

Configuration information can be stored in a localized configuration file or a centralized repository, as described in the Table 3-1.

Table 3-1  Oracle Net Configuration Models

Localized Configuration File Support

Depending on the configuration model used, network computers can be configured with the files described in Table 3-2.

Table 3-2  Oracle Net Configuration Files

Configuration files are typically created in $ORACLE_HOME/network/admin on UNIX operating systems and ORACLE_HOME\network\admin on Windows operating systems. However, configuration files can be created in a variety of places, because Oracle Net searches for the configuration files in a variety of places. The search order for sqlnet.ora and ldap.ora is as follows:

1. The directory specified by the TNS_ADMIN environment variable

   If the TNS_ADMIN environment variable is not defined as a variable on Windows NT, it may be in the registry.

2. The $ORACLE_HOME/network/admin directory on UNIX operating systems and the ORACLE_HOME\network\admin directory on Windows operating systems

The search order for cman.ora, listener.ora, names.ora, and tnsnames.ora is as follows:

1. The directory specified by the TNS_ADMIN environment variable

   If the TNS_ADMIN environment variable is not defined as a variable on Windows NT, it may be in the registry.

2. On UNIX operating systems, the global configuration directory

   For example, on the Solaris Operating System, this directory is /var/opt/oracle.

3. The $ORACLE_HOME/network/admin directory on UNIX operating systems and the ORACLE_HOME\network\admin directory on Windows operating systems.

   See Also: Oracle operating system-specific documentation

Directory Server Support

Today, network information is stored in multiple systems and in multiple directory formats. With new requirements for Internet computing and new e-business technologies, a common repository infrastructure is needed as a foundation for management and configuration of all data and resources. This kind of infrastructure reduces the cost of managing and configuring resources in a network.

Support of LDAP-compliant directory servers provides a centralized vehicle for managing and configuring a distributed Oracle network. The directory server can replace clientside and serverside localized tnsnames.ora files.

This section contains these topics:

• Directory Naming Overview
• Naming Configuration Storage in a Directory Server
• Directory Entries
• Adding or Modifying Entries in the Directory Server
• Client Connections Using Directory Naming
• Oracle Net Configuration and Directory Server Design

Directory Naming Overview

Oracle Net Services use a centralized directory server as one of the primary methods for storage of connect identifiers. Clients configured directory usage can use the connect identifiers in their connect string. The directory server resolves the connect identifier to a connect descriptor that is passed back to the client.

Figure 3-1 shows a client resolving a connect identifier through a directory server.

1. The client contacts the directory server to resolve a connect identifier to a connect descriptor.
2. The directory server resolves the connect identifier and retrieves the connect descriptor for the client.
3. The client sends the connection request to the listener, using the connect descriptor.

Figure 3-1 Client Using a Directory Server to Resolve a Connect Identifier

Naming Configuration Storage in a Directory Server

Directory servers store information in a tree structure called a directory information tree (DIT). Each node in the tree is called an entry. Oracle Net Services makes use of both the tree structure and specific entries in the tree. For example, consider Figure 3-2.

Figure 3-2 Database Service and Net Service Name in a Directory Server

The cn=sales and cn=db1 entries represent a net service name and a database service, respectively. Additional entries under cn=sales and cn=db1 contain the connect descriptor information. These entries are not represented in the graphic. The cn=sales and cn=db1 entries enable clients to connect to the database using connect strings CONNECT username/password@sales and CONNECT username/password@db1.

Each entry is uniquely identified by a distinguished name (DN). The DN tells you exactly where the entry resides in the directory server's hierarchy. The DN for db1 is dn:cn=db1,cn=OracleContext,dc=jp,dc=acme,dc=com, and the DN for sales is dn:cn=sales,cn=OracleContext,dc=jp,dc=acme,dc=com. Note that the format of a DN places the lowest component of the DIT to the left, then moves progressively up the DIT. Each DN is made up of a sequence of relative distinguished names (RDNs), much the way a directory path contains a sequence of directories. In the entry for db1, the RDN is cn=db1. A RDN is made up of a set of attributes. For example, in cn=db1, cn is one of the entry's attributes. The attribute, along with its value, uniquely identifies the entry.

Notice that db1 and sales reside under cn=OracleContext. This entry is a special RDN called an Oracle Context. The entries under the Oracle Context support various directory-enabled features, such as directory naming and enterprise user security.

During directory server usage configuration, a default directory entry that contains an Oracle Context is selected. The client uses this entry as the default location to look up connect identifiers in the directory server. The default Oracle Context affects the connect string. For example, if a client needs to access the db1 and sales entry frequently, a reasonable Oracle Context would be dc=jp,dc=acme,dc=com. The cn=OracleContext does not have to be explicitly specified in the connect string. If a client's directory entry does not match the directory entry where the service is located, then the client must specify an entry's absolute name in the connect string, as described in "Client Connections Using Directory Naming".

Net Service Alias Entries

In addition to database service and net service name entries, directory naming enables you to create net service alias entries. A net service alias is an alternative name for a net service name or database service. A net service alias entry does not have connect descriptor information. Instead, it only references the location of the entry for which it is an alias. When a client requests a directory lookup of a net service alias, the directory determines that the entry is a net service alias and completes the lookup as if it is the referenced entry. For example, in Figure 3-3, a net service alias of db1alias is created for a database service of db1. When db1alias is used to connect to a database service, as in CONNECT username/password@db1alias, it will actually resolve to and use the connect descriptor information for db1.

Figure 3-3 Net Service Alias db1alias in a Directory Server

There are several uses for using net service aliases. As shown in Figure 3-3, a net service alias can be useful as a way for clients to refer to a net service name by another name. Another use is to have a net service alias in one Oracle Context for a database service or net service name in a different Oracle Context. This enables a database service or net service name to be defined once in the directory server, but referred to by clients that use other Oracle Contexts.

In Figure 3-4, database service db1 resides in dc=jp,dc=acme,dc=com. A net service alias named db1 is created in dc=us,dc=acme,dc=com. This enables clients in both Japan and the United States to use the connect string CONNECT username/password@db1 as opposed to clients in the United States needing to specify CONNECT username/password@db1.jp.acme.com.

Figure 3-4 Net Service Alias db1 in a Directory Server

Directory Entries

DITs are commonly structured using:

• A Domain Name Space (DNS) structure
• A geographical and organization structure

Other structures are also permitted, but Oracle Corporation provides support for these structures.

Figure 3-5 shows a DIT structured according to DNS domain components.

Figure 3-5 Domain Component DIT

Figure 3-6 shows a DIT structured according to country, organization, and organizational units. This structure is commonly referred to as an X.500 DIT.

Figure 3-6 X.500 Style DIT

Adding or Modifying Entries in the Directory Server

A database service entry is created with Database Configuration Assistant during or after some modes of installation. Net service name and net service alias entries can be created with Oracle Net Manager. Oracle Net Manager can also be used to modify the Oracle Net attributes of the database service entries. Figure 3-7 shows how Database Configuration Assistant and Oracle Net Manager interface with the directory server.

Figure 3-7 Creating Entries in the Directory Server with Applications

Clients configured for directory server usage, as described in "Client Connections Using Directory Naming", can connect to a database using entries created by these configuration tools.

To use these configuration tools to add entries, an Oracle Context must exist. You create the Oracle Context by completing directory server usage configuration using Oracle Net Configuration Assistant. If you are using Oracle Internet Directory, then an Oracle Context is automatically created at the root of the DIT structure. This root Oracle Context has a complete DN of dn:cn=OracleContext. For most deployments, you will need to create additional Oracle Contexts.

To create entries with Database Configuration Assistant or Oracle Net Manager, you must be a member of the following groups:

• OracleDBCreators group (cn=OracleDBCreators,cn=OracleContext...) or the OracleContextAdmins group (cn=OracleContextAdmins,cn=Groups,cn=OracleContext...) to create a database service entry with Database Configuration Assistant
• OracleNetAdmins group (cn=OracleNetAdmins,cn=OracleContext...) or the OracleContextAdmins group to create net service names or net service aliases with Oracle Net Manager

The directory user that created the Oracle Context is automatically added to these groups. Other users can be added to these groups by the directory administrator.

The OracleContextAdmins group is a super-user group for the Oracle Context. Members of the OracleContextAdmins group can add all supported types of entries to the Oracle Context.

Client Connections Using Directory Naming

Most clients only need to perform name lookups in the directory server. To perform a lookup, the following minimum requirements must be met:

• The client's Oracle home must be configured for directory server usage
• The directory server must allow anonymous authentication

  Directory servers usually do this by default.

You can use Oracle Net Configuration Assistant to perform the necessary directory server usage configuration during client installation. When directory usage configuration completes, directory usage information is stored in an ldap.ora file. The client reads this file to locate the directory server and the default Oracle Context.

In the same way they might use other naming methods, clients make connections to a database using connect identifiers. The connect identifiers can be a database service, net service name, or net service alias. These can be referred to by their common names, or they can require additional directory location information. The default Oracle Context determines how the connect identifier must be specified.

An entry may be identified in one of two ways:

• Using the Entry's Relative Name
• Using the Entry's Absolute Name

  Note: The JDBC OCI Driver supports both relative and absolute naming. The JDBC Thin Driver supports absolute naming only when the complete DN is used. See the Oracle9i JDBC Developer's Guide and Reference for further information.

Using the Entry's Relative Name

In the following example, an entry is identified by its relative name, and the service can be referred to by its common name. A relative name can be used if the entry is in the same Oracle Context that was configured to be the default Oracle Context for the client's Oracle home.

Consider a directory server that contains an entry for a database called sales with a DN of dn:cn=sales,cn=OracleContext,o=acme,c=us, as shown in Figure 3-8. If the client is configured with a default Oracle Context of cn=OracleContext,o=acme,c=us, then the connect identifier can simply be sales.

Figure 3-8 Relative Naming

Using the Entry's Absolute Name

Consider the same directory structure as shown Figure 3-8, but with the client's Oracle home configured with a default Oracle Context of cn=OracleContext,o=acme,c=jp.

Because the client is configured with an Oracle Context that does not match the location of sales in the directory server, a connect string that uses sales does not work. Instead, the client must specifically identify the location of sales, which can be done in one of two ways:

• The entry's complete DN can be used in the connect string, for example:

  CONNECT username/password@"cn=sales,cn=OracleContext,o=acme,c=us"
  
  

  Many applications do not support the use of a DN.

• The entry can be referred to by a fully-qualified name, a name that includes the name of the object and its location in the directory server, for example:

  CONNECT username/password@sales.acme.us
  
  

Oracle Net Configuration and Directory Server Design

If you are responsible for designing directory servers for directory naming, consider the following issues:

• Performance
• Security
• Schema

Performance

Connect identifiers are stored in a directory server for all clients to access. Depending on the number of clients, there can be a significant load on a directory server.

During a connect identifier lookup, a name is searched under a specific Oracle Context. Because of the scope of the lookup, you probably want users to experience relatively quick performance so that the database connect time is not affected. Users may begin to notice slow connect times if lookups takes more than one second.

You can resolve performance problems changing the network topology or implementing replication.

Security

Because administrative clients can create and modify entries in the directory server, security is essential. This section covers the following security-related topics:

• Authentication Methods
• Access Control Lists

Authentication Methods

Clients that perform lookups for information in the directory server typically use anonymous authentication.

Clients that add or modify entries in a directory must authenticate with the directory server. Database Configuration Assistant or Oracle Net Manager may be used to add or modify the entries. Only authenticated users with proper privileges can modify entries. Use one of the authentication methods listed in Table 3-3.

Table 3-3  LDAP Directory Authentication Methods

Access Control Lists

Authentication is used with access control lists (ACLs) to make decisions about whether clients can modify or add information in the directory server. ACLs are created at the same time as the Oracle Context with Oracle Net Configuration Assistant during directory server access configuration.

ACLs specify the following:

• The entries that the user can access
• The authentication method used to access the entry
• The access rights, or what the user can do with the object (read/write)

ACLs are established for a group of users. During Oracle Context creation, the OracleDBCreators, OracleNetAdmins, and OracleContextAdmins groups are created.

The user who creates the Oracle Context with Oracle Net Configuration Assistant is automatically added as the first member of these groups.

Table 3-4 describes ACL requirements for these groups and anonymous users and their relation to Oracle Net entries in the directory server.

Table 3-4  LDAP Directory User Groups

Schema

Directories must be populated with the correct version of the Oracle schema before Oracle Contexts or a database service or net service name entry can be created. The Oracle schema defines the type of objects, called object classes, that can be stored in the directory server and their attributes. Table 3-5 lists the object classes for database service, net service name, and net service alias entries.

Table 3-5  Oracle Net Services LDAP Main Object Classes

Table 3-6 lists the object classes used by orclDbServer, orclNetService, and orclNetServiceAlias.

Table 3-6  Oracle Net Services LDAP Derived Object Classes

These object classes use attributes that specify the contents of connect descriptors.

Oracle Names Support

Like directory naming support, Oracle Names provides a distributed naming service to help simplify the setup and administration of global, client/server computing networks. Directory naming uses an LDAP-compliant directory server, which can have other functions in addition to supporting Oracle services. Oracle Names, however, is Oracle proprietary, providing support only for Oracle services.

This section contains these topics:

• Oracle Names Overview
• Administrative Regions
• Domains
• Oracle Names As Data Repository
• Data Stored in an Oracle Names Server
• Organization of Network Components
• Multiple Regions to Decentralize Administrative Responsibilities
• Differences Between Versions of Oracle Names
• About Discovery

Oracle Names Overview

Oracle Names establishes and maintains an integrated system of Oracle Names servers which work together like a directory service. The system stores addresses for all the services on a network and makes 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 refer their connection requests to an Oracle Names server. The Oracle Names server attempts to resolve the service name provided by the client to a network address. If the Oracle Names server finds the network address, it then returns that information to the client. The client can then use that address to connect to the service.

Figure 3-9 shows how Oracle Names works to help establish a connection between a client and server:

1. A database service is registered with an Oracle Names server.
2. A client seeks to locate a service on the network by contacting an Oracle Names server to retrieve the protocol address.
3. The client transparently connects to the service.

Figure 3-9 Oracle Names

Administrative Regions

Many networks have one central point of administration, that is, one administrative region. With Oracle Names, an administrative region refers to a collection of Oracle Names servers that administer services in a network. All connect information is stored in a single data repository that has the authority to interpret a service name. All Oracle Names servers within an administrative region query information from this data repository. If the administrative region uses a database for storage, there is one database for each administrative region. There can be any number of Oracle Names servers.

Oracle Names provides support for one or more administrative regions. This enables each data center to independently define and manage the services in its own environment. At the same time, all service addresses remain available to all clients across the enterprise. Oracle Names servers transparently forward client name resolution requests in one administrative region to the region which can service the request.

Domains

A domain is a logical group of computers and network services. Within each domain, all names must be unique: Across domains, simple service names can be repeated.

Any administrative region contains one or more domains. 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 name spaces developed to prevent name space conflicts.

Oracle Names As Data Repository

Data in Oracle Names servers is updated through continuous replication between all the Oracle Names servers in the region or by writing to and reading from a common Oracle database. For smaller workgroup environments, administrators can configure Oracle Names servers to replicate data continuously among themselves.

Administrators can also choose to store the administrative region's data in an Oracle database, called the region database. A region database consists of tables that store Oracle Names information. Each Oracle Names server in a given administrative region periodically polls the region database for updated registrations. In this way, new registrations are communicated in a timely manner to all of the Oracle Names servers in a given administrative region. Using a region database also relieves Oracle Names servers of the necessity to communicate directly with each other and provides better reliability.

Data Stored in an Oracle Names Server

Table 3-7 describes the types of data stored in an Oracle Names server.

Table 3-7  Data Stored in an Oracle Names Server

Organization of Network Components

When you use Oracle Names, objects such as databases in a networked environment need to be named in a way that ensures they are unique within the network. The two basic models for naming objects in a network include:

• Single Domain Model
• Hierarchical Naming Model

Single Domain Model

The single domain naming model is useful if your network is small, and names are not duplicated. Figure 3-10 shows a typical flat naming structure using a single domain name, world.

Figure 3-10 Single Domain Naming Model

In this environment, database service names are automatically appended with a .world extension (for example, prod.world, flights.world, and so forth).

Hierarchical Naming Model

Hierarchical naming models divide names into a hierarchical structure to allow for future growth or greater naming autonomy. This type of naming model enables more than one database with the same simple name in different domains.

Figure 3-11 shows a hierarchical structure of domains including root domain acme and subdomains us.acme, europe.acme, and row.acme.

Figure 3-11 Hierarchical Naming Model

Notice in Figure 3-11 both weather and history are repeated, but the names remain unique, that is, history.row.acme and history.europe.acme.

Default Domains

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 most often requests services. A client can request a network service within its default domain by 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.

Consider for example, a client that is configured with a default domain of europe.acme.com. When this client makes a request for the service name wine in Figure 3-11, the default domain name europe.acme.com is appended to the requested name so that the name becomes wine.europe.acme.com.

Multiple Domains

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.

Multiple Regions to Decentralize Administrative Responsibilities

If you are using Oracle Names and your network is large or widely distributed geographically, you may choose to have multiple administrative regions. 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 subdivide, you must delegate regions and domains from a parent to a child or subregion.

To delegate administrative regions, you must use a hierarchical naming model in which each administrative region controls one or more different domains.

Networks with multiple administrative regions are composed of one root administrative region and one or more delegated administrative regions.

Root Administrative Regions

The root administrative region contains the root domain. There can only be one root administrative region. The root administrative region contains the following information:

• Oracle Names servers in the root region
• Domains that are administered in this region: the root domain and other domains.
• Delegated administrative region Oracle Names servers: the domains and Oracle Names server addresses in any alternate regions that act as direct child regions of the root.
• Data definitions for the root region: All of the net service names, database service names, database links, and aliases associated with the root administrative region.

Delegated Administrative Regions

Administrative regions can be delegated from the top of the hierarchy down to other domains in the naming model. For example, a network with 10 domains can have between one and10 administrative regions.

All administrative regions other than the root are hierarchically delegated directly or indirectly from it.

Figure 3-12 shows a network with five domains and three administrative regions: the root, acme, and two delegated regions, row and asia.

Figure 3-12 Delegated Administrative Regions

Delegated Administrative Regions Under Root

All administrative regions under the root are considered delegated administrative regions. Delegated administrative regions receive administrative responsibilities for a domain from other regions, such as the root administrative region. A delegated administrative region contains the following information:

• All Oracle Names servers and domains in the region.
• Domains and Oracle Names server addresses in any of this administrative region's child regions.
• Addresses of the Oracle Names servers in the root region. Having this data enables Oracle Names servers in delegated regions to contact any other region (through the root region).
• Data definitions, including all of the net service names, database service names, database links, and aliases for all of the domains in this local (delegated) administrative region.

Differences Between Versions of Oracle Names

Oracle Names version 8 and 9 differs significantly from earlier versions. The differences between the versions are described in the following topics:

• Oracle Names Version 1
• Oracle Names Version 2
• Oracle Names Version 8 and 9 (this release)

Oracle Names Version 1

In Oracle Names version 1, administrators configured Oracle Names servers using Oracle Network Manager and stored all topology data in a database. All the Oracle Names servers in a region shared the same information because they accessed the same database.

The clients had a list of preferred Oracle Names servers specified in the sqlnet.ora file. This list was created by the user, listing the order of preferred Oracle Names to contact. The first Oracle Names server in the list would be contacted first by a client.

Preferred Oracle Names servers may still be configured.

Oracle Names Version 2

In Oracle Names version 2, the administrator could choose between continuing Oracle Names server configuration, as in version 1 or using the Dynamic Discovery Option. The Dynamic Discovery Option was recommended only for a network with a single region and single DNS domain. The Dynamic Discovery Option uses well-known Oracle Names servers, which are precise names hard-coded into DNS or the hosts file on both the Oracle Names Server and its clients:

Table 3-8  Well-Known Oracle Names Servers

oranamesrvr0
oranamesrvr1
oranamesrvr2
oranamesrvr3
oranamesrvr4

ORANAMESRVR0
ORANAMESRVR1
ORANAMESRVR2
ORANAMESRVR3
ORANAMESRVR4

Oracle Names servers then become available at these well-known addresses, so clients do not need to be told, by way of a preferred Oracle Names server list, where to find an Oracle Names server.

If the Dynamic Discovery Option was chosen, each Oracle Names server automatically replicated its data to all other well-known Oracle Names servers in the administrative region. Listeners were configured to register themselves with well-known Oracle Names servers.

Oracle Names Version 8 and 9 (this release)

In Oracle Names version 8 and 9, the administrator may choose between continuing Oracle Names Server configuration as in version 1 or version 2, or using the new functionality. Oracle Names version 8 and 9 incorporates version 2 Dynamic Discovery Option features without the constraints of a single region and single domain. The main features of Oracle Names version 8 and 9 include:

• A service can register itself with any Oracle Names server it can find, and its name and address are made available to all Oracle Names servers in the region. Similarly, if an administrator manually registers a service to any Oracle Names server, that service information is available to all other Oracle Names servers. The address information is shared in one of two ways:
  • Region Database: If an Oracle database is used as the registration repository, the registration information is stored in the database and from there is accessible to all the Oracle Names servers.
  • Service Replication: In service replication, service information is stored in the cache of an Oracle Names server and is instantly replicated to the caches of all other Oracle Names servers.
• A list of Oracle Names servers to contact is created on a client through a discovery process rather than manual configuration, as described in "About Discovery".
• A clientside process may be run to create a client cache version of the data stored in Oracle Names servers, including database addresses and Oracle Names server protocol addresses, as well as other service information. As a result, the client does not have to contact an Oracle Names server for address information, which reduces address lookup time.
• Oracle Names version 8 and 9 does not require a database to hold topology information. However, an administrator may choose to use one, and it is recommended.

  See Also: "Configuring the Oracle Names Method" for configuration information

About Discovery

A list of Oracle Names servers can be created that enables a client or another Oracle Names server to contact an Oracle Names server. The process of creating the list is called discovery.

When a client tries to discover an Oracle Names server with the Oracle Names Control utility or Oracle Net Manager, one Oracle Names server is found first. Once the client finds an Oracle Names server, it pings all other Oracle Names servers in the region. A list of Oracle Names servers is then created on the client and saved to .sdns.ora on UNIX operating systems and sdns.ora on Windows operating systems. This list is sorted in order of response time.

To find the first Oracle Names server, discovery searches in the following order:

1. A preferred Oracle Names server configured in the sqlnet.ora file
2. A well-known Oracle Names server
3. A local Oracle Names server configured with TCP/IP, port 1575

If the client is unable to find the first Oracle Names server using one of these methods, one of the following alternate methods can be used:

• If you are using Oracle Net Manager, you will be prompted to specify the protocol address of an Oracle Names server
• If you are using the Oracle Names Control utility, the utility will fail. Rerun the command with the protocol address of a specified Oracle Names server.