Release 1 (9.0.1)
Part Number A90154-01
 Home |
 Book List |
 Contents |
 Index |  Master Index |  Feedback |
| Oracle9i Net Services Administrator's Guide Release 1 (9.0.1) Part Number A90154-01 |
|
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 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
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, 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 the following order:
sqlnet.ora file, the current working directory from where an application is run.
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.
For Sun Solaris, this directory is /var/opt/oracle. Windows NT does not have a central directory.
$ORACLE_HOME/network/admin directory on UNIX, and the ORACLE_HOME\network\admin directory on Windows operating systems.
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 heterogeneous networks.
Support of LDAP-compliant directory servers provides a centralized vehicle for managing and configuring a distributed Oracle network. The directory server can act as a central repository for all data on database network components, user and corporate policies, and user authentication and security, thus replacing clientside and serverside localized tnsnames.ora files.
This section contains these topics:
Oracle Net Services use a centralized directory server as one of the primary methods for storage of connect identifiers. Clients configured to use the directory server, 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.
Oracle Net Services support Oracle Internet Directory and Microsoft Active Directory.
|
Note: JDBC drivers support directory naming. See the Oracle9i JDBC Developer's Guide and Reference for further information. |
To understand how Oracle Net Services use a directory server, consider Figure 3-2.
Each node in the tree is an entry. The branch on the right represents the entry for a database service called sales, which resides under a hierarchical domain structure of dc=uk,dc=acme,dc=com.
This hierarchy of entries is called the directory information tree (DIT). 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 sales is (dn:cn=sales,cn=OracleContext,dc=uk,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 sales, the RDN is cn=sales. A RDN is made up of a set of attributes. For example, in cn=sales, cn is one of the entry's attributes. The attribute, along with its value, uniquely identifies the entry.
Table 3-3 lists the common attributes referred to in this chapter.
Table 3-3 LDAP Directory Common Attributes
Notice that sales resides under cn=OracleContext. The common name cn=OracleContext is a special entry in the directory server called an Oracle Context. The entries under the Oracle Context support various directory-enabled features, such as directory naming and enterprise user security.
In this example, the Oracle Context contains an entry for the sales database service.
During directory server usage configuration, a default directory entry that contains an Oracle Context (cn=OracleContext) is selected. The client uses this entry as the default place to locate and look up connect identifiers in the directory server.
The configured directory entry affects the connect string. For example, if a client needs to access the sales entry frequently, a reasonable default directory entry would be dc=uk,dc=acme,dc=com. Note that cn=OracleContext does not have to be explicitly specified, which enables the client to use the following connect string:
CONNECT scott/tiger@sales
The sales entry is relative to the Oracle Context.
If a client's directory entry does not match the directory entry where the service is located, the connect string must specify an entry's absolute name, as described in "Client Connections Using Directory Naming".
DITs can be structured in many ways, using:
Figure 3-3 shows a DIT structured according to DNS domain components.
Figure 3-4 shows a DIT structured according to country, organization, and organizational units. This structure is commonly referred to as an X.500 DIT.
A database service entry is created with Oracle Database Configuration Assistant during or after installation. Net service name 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-5 shows how Oracle Database Configuration Assistant and Oracle Net Manager interface with the directory server.
Clients configured for directory server access, as described in "Client Connections Using Directory Naming", can connect to a database using entries created by these applications.
In order to use these applications to add entries, an Oracle Context (cn=OracleContext) must be created. The Oracle Context is created during directory server access configuration with Oracle Net Configuration Assistant.
To create a database service entry, the administrator using Oracle Database Configuration Assistant must be a member of the OracleDBCreators group (cn=OracleDBCreators,cn=Oraclecontext). Likewise, the administrator using Oracle Net Manager to add net service names or Oracle Net attributes for database service or net service names entries must be a member of the OracleNetAdmins group (cn=OracleNetAdmins,cn=OracleContext). The directory user that created the Oracle Context is automatically added to both these groups, making this user the Oracle Context administrator. Other users can be added to this group by the directory administrator.
Most clients only need to perform name lookups in the directory server. To perform a lookup, the following minimum requirements must be met:
Oracle Net Configuration Assistant typically performs the necessary directory server access configuration during client installation and stores the following information in a read-only ldap.ora file:
The client reads this file to locate the directory server and Oracle Net entries to access.
|
See Also:
Chapter 8, "Setting Up Directory Server Usage" for information about configuring directory server access |
In the same way they might use other naming methods, clients make connections to a database using one of the two types of connect identifiers stored in the directory server. Database service and net service entries can be referred to by their common names, or they can require additional directory location information in the connect string. How the connect identifier is specified in a connect string depends on how the client's default directory entry is configured.
With directory naming, an entry may be identified in one of two ways:
JDBC OCI drivers support both relative and absolute naming. JDBC Thin drivers support absolute naming only when the complete DN is used. See the Oracle9i JDBC Developer's Guide and Reference for further information.
Note:
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 client is configured with a default directory entry that matches the directory location for the entry.
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-6. If the client is configured with a default directory entry of o=acme,c=us, a connect string that uses sales can be used.
Consider the same directory structure as shown Figure 3-6, but with a client configured with a default directory entry of o=acme,c=uk.
Because the client is configured with a directory entry 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:
CONNECT scott/tiger@cn="sales,cn=OracleContext,o=acme,c=us"
CONNECT scott/tiger@sales.acme.us
|
See Also:
"Absolute Name Specification for Directory Naming" for further information about absolute names |
If you are responsible for designing directory servers for directory naming, consider the following issues:
Connect identifiers are stored in a directory server for all clients to access. Oracle Net uses a directory lookup for the requested name, resulting in heavy use of the directory server.
During a 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.
Because administrative clients can create and modify entries in the directory server, security is essential. This section covers the following security-related topics:
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. Oracle 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-4.
Table 3-4 LDAP Directory Authentication Methods
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:
ACLs are established for a group of users. During Oracle Context creation, the OracleDBCreators and OracleNetAdmins groups are created under the Oracle Context entry.
|
Note: Additional groups are created during Oracle Context creation, as described in the Oracle Directory Service Integration and Deployment Guide. |
The user who creates the Oracle Context with Oracle Net Configuration Assistant is automatically added as the first member of these groups.
Table 3-5 describes ACL requirements for these groups and anonymous users and their relation to Oracle Net entries in the directory server.
Table 3-5 LDAP Directory User Groups
| Group | ACL Requirements |
|---|---|
|
OracleNetAdmins group users |
Members of OracleNetAdmins ( In addition to the Oracle Context creator, other users can be added to this group by the directory administrator. See Also: "Adding Users to and Removing Users from the OracleNetAdmins Group" for information on adding users to the OracleNetAdmins group |
|
Anonymous users |
All Oracle Net attributes and objects in the directory server have read access for the anonymous user. Read access of these objects for anonymous is also applied to the Oracle Context. This enables anonymous users to browse directory naming entries contained within the Oracle Net Configuration Assistant sets up this access right during client installation. |
|
OracleDBCreators group users |
Members of OracleDBCreators ( In addition to the Oracle Context creator, other users can be added to this group by the directory administrator with Oracle Enterprise Security Manager. See Also: Oracle Advanced Security Administrator's Guide for further information about the OracleDBCreators group |
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-6 for database service and net service name entries.
Table 3-6 Oracle Net LDAP Main Object Classes
| Object Class | Description |
|---|---|
|
|
Defines the attributes for database service entries |
|
|
Defines the attributes for net service name entries |
Table 3-7 lists the object classes used by orclDbServer and orclNetService.
These object classes use attributes that specify the contents of connect descriptors.
|
See Also:
Oracle9i Net Services Reference Guide for further information about these object classes and their attributes |
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.
|
Note: In future releases, Oracle Names will not be supported as a centralized naming method. Because no new enhancements are being added to Oracle Names, consider using directory naming or migrating an existing Oracle Names configuration to directory naming, as described in Chapter 10, "Exporting Naming Data to a Directory Server". The material presented here is primarily for reference to enable you to maintain your current Oracle Names environment. |
This section contains these topics:
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-7 shows how Oracle Names works to help establish a connection between a client and server:
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.
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 system, 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.
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.
Table 3-8 describes the types of data stored in an Oracle Names server.
Table 3-8 Data Stored in an Oracle Names Server
| Data | Description |
|---|---|
|
Net service names |
If you register net service names with the Oracle Names Control utility or Oracle Net Manager, an Oracle Names server stores them. An Oracle Names server also stores gateways to non-Oracle databases and Oracle RDB databases. |
|
Global database names and addresses |
The Oracle Names server retrieves information about the database, including the global database name (database name and domain) and address, from the listener. Global database names and addresses can be registered with the Oracle Names server, using either the Oracle Names Control utility or Oracle Net Manager. |
|
Other Oracle Names server names and addresses |
An Oracle Names server stores the names and addresses of all other Oracle Names servers in the same administrative region. If a network has more than one administrative region, the Oracle Names server stores the name and address of at least one Oracle Names server in the root administrative region and each of the immediate subregions. You do not need to register this information. |
|
Global database links |
Database links enable a database to communicate with another database. The name of a database link is the same as the global database name of the database to which the link points. Typically, only one database link should exist for the database. The following types of database links can be created:
Global database links, as well as user name and password credentials for them, can be registered with the Oracle Names server using Oracle Net Manager. These global database links may be supplemented with link qualifiers defined through the Oracle Net Manager. Global database links can be superseded with private and public database links created by individual users. See Also: Oracle9i Database Administrator's Guide |
|
Aliases |
An Oracle Names server stores aliases or alternative service names for any defined net service name, database service, or global database link. Aliases can be registered with the Oracle Names server, using either the Oracle Names Control utility or Oracle Net Manager. |
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:
The single domain naming model is useful if your network is small, and names are not duplicated. Figure 3-8 shows a typical flat naming structure using a single domain name, world.
In this environment, database service names are automatically 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 enables more than one database with the same simple name in different domains.
Figure 3-9 shows a hierarchical structure of domains including root domain acme and subdomains us.acme, europe.acme, and row.acme.
Notice in Figure 3-9 both weather and history are repeated, but the names remain unique, that is, history.row.acme and history.europe.acme.
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-9, the default domain name europe.acme.com is appended to the requested name so that the name becomes wine.europe.acme.com.
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.
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.
The root administrative region contains the root domain. There can only be one root administrative region. The root administrative region contains the following information:
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-10 shows a network with five domains and three administrative regions: the root, acme, and two delegated regions, row and asia.
All administrative regions below 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:
Oracle Names version 8 and 9 differs significantly from earlier versions. The differences between the versions are described in the following topics:
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.
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:
| The well-known host names for TCP connections | The well-known computer names for Named Pipes connectionsFoot 1 |
|---|---|
oranamesrvr0 oranamesrvr1 oranamesrvr2 oranamesrvr3 oranamesrvr4 |
ORANAMESRVR0 ORANAMESRVR1 ORANAMESRVR2 ORANAMESRVR3 ORANAMESRVR4 |
|
1
Well-known Oracle Names server names for Named Pipes must be in all uppercase. |
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.
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 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 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:
sqlnet.ora file
If the client is unable to find the first Oracle Names server using the above methods, one of the following alternate methods can be used:
|
 Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|