Oracle9i Net Services Administrator's Guide
Release 1 (9.0.1)

Part Number A90154-01
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index


Go to previous page Go to next page

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

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

Network Configuration Model  Description 

Localized management 

Network address information stored in tnsnames.ora files on each computer in the network. 

Centralized management 

Network address information is stored in centralized directory services, including a LDAP-compliant directory server or an Oracle Names server.

Note: In future releases, Oracle Names will not be supported as a centralized naming method. 

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 File  Description 


Located on the database server and client computers configured for centralized management features, this file contains parameters necessary to access a directory server. 


Located on the database server, this configuration file for the listener includes:

  • Protocol addresses it is accepting connection requests on

  • Database and nondatabase services it is listening for

  • Control parameters used by the listener



Located on the Oracle Names server, this file includes the location, domain information, and optional configuration parameters for an Oracle Names server. 


Located on client and database server computer, this file may contain:

  • Client domain to append to unqualified service names or net service names

  • Order of naming methods the client should use when resolving a name

  • Logging and tracing features to use

  • Route of connections

  • Preferred Oracle Names servers

  • External naming parameters

  • Oracle Advanced Security parameters

  • Database access control parameters



Located on the clients, this file contains net service names mapped to connect descriptors. This file is used for the local naming method.  

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:

  1. For sqlnet.ora file, the current working directory from where an application is run.

  2. 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.

  3. The node's global configuration directory.

    For Sun Solaris, this directory is /var/opt/oracle. Windows NT does not have a central directory.

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

    See Also:

    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 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:

Directory Naming Overview

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.

  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

Text description of net81059.gif follows
Text description of the illustration net81059.gif

Oracle Net Services support Oracle Internet Directory and Microsoft Active Directory.


JDBC drivers support directory naming. See the Oracle9i JDBC Developer's Guide and Reference for further information. 

Naming Configuration Storage in a Directory Server

To understand how Oracle Net Services use a directory server, consider Figure 3-2.

Figure 3-2 Database Service in a Directory Server

Text description of net81048.gif follows
Text description of the illustration net81048.gif

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

Attribute  Description 

commonName (cn

Common name of an entry 

country (c

Name of country 

domain component (dc

Domain component 

organization (o

Name of organization 

organizationalUnitName (ou

Name of a unit within an organization 

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.

See Also:

Oracle Advanced Security Administrator's Guide for further information about 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".

Directory Entries

DITs can be structured in many ways, using:

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

Figure 3-3 Domain Component DIT

Text description of net81049.gif follows
Text description of the illustration net81049.gif

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.

Figure 3-4 X.500 Style DIT

Text description of net81050.gif follows
Text description of the illustration net81050.gif

Adding or Modifying Entries in the Directory Server

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.

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

Text description of net81062.gif follows
Text description of the illustration net81062.gif

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.

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:

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:

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 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.

Figure 3-6 Relative Naming

Text description of net81051.gif follows
Text description of the illustration net81051.gif

Using the Entry's Absolute Name

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:


JDBC Thin drivers support absolute naming only when the complete DN is used. 

See Also:

"Absolute Name Specification for Directory Naming" for further information about absolute names 

Oracle Net Configuration and Directory Server Design

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.

See Also:

Directory server vendor documentation for details on resolving performance issues 


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

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 Method  Description 

Native Authentication 

The directory server uses operating system user credentials.  

Simple Authentication 

The client identifies itself to the directory server by means of a DN and a password, which are sent in the clear over the network. The server verifies that the DN and password sent by the client match the DN and password stored in the directory server.  

Strong Authentication 

Directories provide strong authentication by using public-key encryption available with Secure Sockets Layer (SSL). In public-key encryption, the sender of a message encrypts the message with the public key of the recipient. Upon delivery, the recipient decrypts the message using the recipient's private key. 

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:

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


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 (cn=OracleOracleNetAdmins,cn=OracleContext) have create, modify, and read access to Oracle Net objects and attributes. Oracle Net Configuration Assistant establishes these access rights for this group during Oracle Context creation.

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 cn=OracleContext RDN. This does not include objects used for enterprise user security.

Oracle Net Configuration Assistant sets up this access right during client installation. 

OracleDBCreators group users 

Members of OracleDBCreators (cn=OracleDBCreators,cn=OracleContext) have create and read access to database service objects and attributes. Oracle Net Configuration Assistant establishes these access rights for this group during Oracle Context creation.

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.

Table 3-7 Oracle Net LDAP Derived Object Classes

Object Class  Description 


Defines a listener protocol address 


Defines a list of addresses 


Specifies a connect descriptor containing the protocol address of the database and the connect information to the service 


Defines a list of connect descriptors 

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 

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.


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 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-7 shows how Oracle Names works to help establish a connection between a client and server:

  1. A listener registers database service 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-7 Oracle Names

Text description of net81030.gif follows
Text description of the illustration net81030.gif

See Also:

"Configuring the Oracle Names Method" for configuration information 

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.


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.


Although they appear similar, the domains of an Oracle network are completely independent of DNS name spaces. For convenience, you may choose to mirror the DNS directory structure in the Oracle Names domain structure. 

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-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 


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. 

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

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.

Figure 3-8 Single Domain Naming Model

Text description of net81013.gif follows
Text description of the illustration net81013.gif

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


In previous releases of SQL*Net and Oracle Names, a network with only one domain would default to .world. This convention is no required with Oracle Net Services and Oracle Names version 8 and 9. You may, however, want to keep this convention to be backward compatible, as well as to avoid having to rename all your databases. 

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-9 shows a hierarchical structure of domains including root domain acme and subdomains us.acme, europe.acme, and row.acme.

Figure 3-9 Hierarchical Naming Model

Text description of net81014.gif follows
Text description of the illustration net81014.gif

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.

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 When this client makes a request for the service name wine in Figure 3-9, the default domain name is appended to the requested name so that the name becomes

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:

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-10 shows a network with five domains and three administrative regions: the root, acme, and two delegated regions, row and asia.

Figure 3-10 Delegated Administrative Regions

Text description of net81016.gif follows
Text description of the illustration net81016.gif

Delegated Administrative Regions Below Root

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:

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

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.

See Also:

"Configuring Connections to Non-Oracle Database Services" for configuration information 

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-9 Well-Known Oracle Names Servers
The well-known host names for TCP connections   The well-known computer names for Named Pipes connectionsFoot 1 
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.

See Also:

Oracle Names Administrator's Guide, Release 2.0, for configuration information 

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:

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 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 on port 1575

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:

Go to previous page Go to next page
Copyright © 1996-2001, Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index