Network Layout and Naming Issues
This chapter describes some of the decisions you need to make about the structure of the network. Read this chapter carefully before using Oracle Network Manager to configure the network. This chapter includes discussions of the following topics:
Suggestion: When planning your SQL*Net network, think about future needs as well as present requirements. Select a layout that is flexible and expandable. If you foresee your network growing, select computers that have the capacity to handle additional connections. When naming the components in your system, think about how your naming conventions can be extended to handle future components.
Plan the Network Layout
It is a good idea to draw a picture of your network layout as you make decisions about its composition. Especially if your network includes multiple communities, Interchanges and Names Servers, it is much easier to understand and modify if you have a diagram. Two types of diagrams are useful:
Physical diagrams show every component in a network, including the physical connections among them. A physical diagram can help show what pieces are required and demonstrate the connections between components.
Logical diagrams show the relationships between network components without going into detail about their physical placement. The figures throughout this book are good examples of the sort of graphical representation that is needed. In general, the more complex the network, the more necessary a visual mapping.
Select Protocols
The first decision to make when designing a network is whether it will include only one protocol or more than one protocol. As explained in Chapter 2, "SQL*Net Version 2 Architecture," SQL*Net runs above TNS, which in turn runs over a transport level protocol, with an Oracle Protocol Adapter acting as an interface between TNS and the protocol of choice. The specific hardware below the transport layer is irrelevant to how SQL*Net functions.
You may be able to choose a single transport level protocol that works well on all the components in your network. Protocol adapters are available for most of the major protocols on many platforms. If you have only one protocol in your network, as shown in Figure 3 - 1, then all the components are members of the same community.
Figure 3 - 1. A Single Community Network
For reasons of necessity or efficiency, you may choose to have more than one protocol running in your network. You may do this by having multiple protocol adapters on the computers in your network, or, more efficiently, you may have an Interchange between the computers running one protocol and the computers running another. Using SQL*Net and the MultiProtocol Interchange, individual computers can communicate across the protocols that are most compatible with their operating systems. For example, you can have personal computers running Novell's SPX/IPX connected to a VAX server that uses the DECnet protocol. If your network uses one or more Interchanges, as shown in Figure 3 - 2, it is a multi-community network.
Figure 3 - 2. A Multicommunity Network
Choose Nodes as Interchanges
If you decide on a multi-community network, you must choose what nodes to use for Interchanges to connect the communities. Considerations include:
- What computers work well on all the protocols they connect?
- What computers have the capacity to handle the anticipated traffic?
- Should the computers chosen be dedicated to the Interchange service, or can they handle other applications as well?
For further information about Interchanges, see the Oracle MultiProtocol Interchange Administrator's Guide.
Choose the Location of the Network Manager
The configuration files for SQL*Net and the other Oracle networking products are created and maintained by using Oracle Network Manager. This product, which is included with SQL*Net release 2.3, provides a graphical user interface through which the network administrator can quickly and efficiently create and modify configuration information for the network components. The Network Manager requires a workstation running Microsoft Windows 3.1, Windows95, or Windows NT. In addition, if your network includes Oracle Names, the Network Manager must have access to an Oracle database.
Select a location for the Network Manager from which it is relatively easy to transfer configuration files to other network components. Network Manager includes a utility, NetFetch, which helps you do this, but a SQL*Net network (version 2 or later) must be up and running before it can be used.
For further information about using Oracle Network Manager to create SQL*Net configuration files, see the Oracle Network Manager Administrator's Guide
Most networks have one central point of administration, that is, one installation of Oracle Network Manager. However, if you are using Oracle Names and your network is quite large or widely distributed geographically, you may choose to have several points of network administration. For example, if your enterprise-wide network includes both the United States and Europe, you might want to have administrative decisions about the network made locally. A network administrator in Chicago could have jurisdiction over the names and locations of network services in the United States, while someone in Brussels would be responsible for administrative decisions about the network in European countries.
Alternatively, if your network is not very large and dispersed, you may choose to use Oracle Names with the Dynamic Discovery Option. If so, you may not need to use Network Manager at all, because very few configuration files are needed. See the following section for more information about this option.
For further information about centralized and decentralized administration, see the Oracle Names Administrator's Guide.
Choose Whether to Use Oracle Names and the Dynamic Discovery Option
Oracle Names version 2, which is included with this release of SQL*Net, contains an option that provides dynamic registration of servers with well-known Names Servers on the network and automatic replication of data between Names Servers. If you use Oracle Names to provide a naming service for your network, you must decide whether to use the Dynamic Discovery Option.
If you use Oracle Names, with or without the Dynamic Discovery Option, you must decide what nodes should contain Names Servers, which provide name and address information to enable connections throughout the network. You should have a Name Server in every community. In general, Oracle recommends that Names Servers in a multi-community network be placed on Interchange nodes, thereby minimizing the number of Names Servers required. A Names Server located on an Interchange node can serve both communities.
Oracle Names with the Dynamic Discovery Option
If you choose to use the Dynamic Discovery Option in your network, you may not need to use Oracle Network Manager to create configuration files. If you are using SQL*Net for the first time, and if you are willing to accept all default parameters, with the Dynamic Discovery Option, the only configuration file needed is a LISTENER.ORA for each listener, and that file is created as part of the installation procedure.
If you are adding SQL*Net release 2.3 to an existing network, or if you have a lot of non-default parameters in your configuration files, then you may want to continue to use Oracle Network Manager even if you are using Oracle Names release 2.0 and the Dynamic Discovery Option.
Use Oracle Names release 2.0 and the Dynamic Discovery Option if you are installing SQL*Net for the first time, and if you expect your network to grow and change. If you already have an established network, you can add Oracle Names release 2.0 and the Dynamic Discovery Option if you wish. As your network grows, all new nodes that use SQL*Net 2.3 can use the dynamic registration option while the rest of the network uses configuration files generated by Oracle Network Manager.
For further information about Oracle Names, see the Oracle Names Administrator's Guide.
Naming Considerations
When you name objects such as databases in networked environments, you need to make sure they are unique within the network. This can be a challenge if your company is large, and network administration is not handled centrally. You may be able to guarantee that all services in your building or jurisdiction have unique names, but that does not guarantee that the name is unique within the corporation. Your goal should be to avoid the occurrence of duplicate names if multiple independent TNS communities are joined by installing an Interchange between them.
Domain Names
A recommended network naming technique is to use hierarchical groups or domains in which each administrative unit is assigned to a unique domain based on the function it provides. Many of the examples in this guide feature the fictitious company,ACME Inc., which has segregated its naming domains as shown in Figure 3 - 3.
Figure 3 - 3. Naming Domains at ACME
In this figure, each of the boxes represents a separate domain. The domains are related hierarchically; that is, FIN and HR are the children of HQ, which is one of the children of ACME. A network object (such as a database server or an Interchange) within a given domain has a unique name within that domain. This is generally manageable because one or at most a few people have authority to pass out names for that domain. The global name for that object includes the parent domains.
For example, consider the corporation shown in Figure 3 - 3. The sales organization (the SALES domain) could have a server named VAULT. The Human Resources group (the HR domain) could also have a server named VAULT. The global names of these servers would be unique. The Sales group's server would have the global database name:
VAULT.SALES.ACME
while the global database name of the Human Resources server would be:
VAULT.HR.HQ.ACME
Names can go to the company level (the ACME stem) or can go to the Internet level (for example, the ACME.COM stem) in support of inter-company communications such as mail or Electronic Data Interchange (EDI). If your organization belongs to the Internet, or you expect that it might join the Internet in the future, the domain names should include the appropriate stem (such as COM, GOV, or EDU).
Note: This naming structure applies whether you are using TNSNAMES.ORA name lookup files, Oracle Names Servers, or Oracle Native Naming Adapters (in conjunction with native name services) to resolve names to addresses. Every network object must have a global object name such as VAULT.HR.HQ.ACME.
If your organization already has global naming conventions, your network components should follow those conventions.
Note: Refer to the Oracle Names Administrator's Guide for a more detailed discussion of naming conventions.
Default Domain .WORLD Appended to Network Components
Oracle Network Manager automatically appends the domain .WORLD to the name of all network components unless you provide alternative domain names. See the Oracle Names Administrator's Guide for further information.
Hierarchical Domains Not Used by the Dynamic Discovery Option
If you are using Oracle Names release 2.0 and the Dynamic Discovery Option, the object names you provide are not interpreted as including hierarchical domains. A name such as VAULT.HR.HQ.ACME or PROD.WORLD is interpreted as a flat name that happens to include dots (.). Therefore, you must be particularly careful in assigning unique names in the network.
Note: If you are using the DDO in a network that has SQLNET.ORA files with default domain parameters included (from an earlier network definition), no default domain will be added to the object name if it contains a dot (.).
Default Domain
Unless you are using Oracle Names and the Dynamic Discovery Option, every client and server has a default domain listed in its SQLNET.ORA file. The default domain is the domain to which the majority of the clients' connection requests are directed. When clients connect to servers in the default domain, they do not need to specify fully qualified service names in their connection requests. For example, a client can connect to a database in its default domain with the service name (global database name) PROFITS.SALES.ACME.COM by specifying the following command:
% sqlplus scott/tiger@profits
However, if the PROFITS database is not in the client's default domain, the client needs to specify the fully-qualified service name (global database name) in the connection request:
% sqlplus scott/tiger@profits.sales.acme.com
Note: The default domain is not necessarily the same as the domain of the client itself. For example, clients in one domain may frequently access Oracle servers in another domain.
If you have a network configured for an older version of SQL*Net and you upgrade to a SQL*Net version 2.1 (or later) network, the older names are changed to include a domain. If you don't provide any domain information for the network, when you upgrade to release 2.1 or 2.2, the Oracle Network Manager provides the suffix .WORLD, the default flat domain name, to the network component names.
For example, you might have a database service name defined in version 2.0 as HRFACTS. The same database in release 2.1 and 2.2 would be defined as HRFACTS.WORLD.
Oracle Network Manager automatically includes the following parameter in the SQLNET.ORA file:
NAMES.DEFAULT_DOMAIN=WORLD
This parameter allows the version 2.0 database service name to be recognized as the same as the database service name defined in the release 2.1 (or later) network.
Note: If you are using Oracle Names release 2.0 and the Dynamic Discovery Option, no SQLNET.ORA file is automatically generated for each client and server, and therefore there is no default domain. If you want to include a default domain for compatibility with other parts of the network, you must create the appropriate parameter in a SQLNET.ORA file. To do so, you can either use Oracle Network Manager to create a SQLNET.ORA file for a group of similar clients, or use the SQLNET.ORA Editor, which is part of the Client Status Monitor, to create SQLNET.ORA files for individual clients. The Client Status Monitor is described in Chapter 4 of the Oracle Network Products Troubleshooting Guide.
See theOracle Names Administrator's Guide and Oracle Network Manager Administrator's Guide for further information.
Integrating Oracle into Your Native Naming Environment
Oracle Native Naming Adapters enable network administrators to integrate Oracle service names into their existing naming environment by storing Oracle service names in non-Oracle name services such as Network Information Services (NIS), DCE CDS, Banyan's StreetTalk, and Novell's NetWare Directory Services (NDS). Clients can then access Oracle network services stored in these naming services. Oracle Native Naming Adapters can be used instead of or in conjunction with Oracle Names Servers and TNSNAMES.ORA files to provide cross-environment name resolution. Service names can be resolved to network addresses by Oracle Names Servers, TNSNAMES.ORA name lookup files, or by a native naming service.
What Is a Name Service?
A name service maps, or "resolves," a network name to an address. A name service such as Oracle Names or Network Information Services (NIS) manages and tracks only two attributes--name and location. A client can enter a name and have it resolved to an address, but the client cannot enter an address and have it resolved to a name.
Benefits of Using Name Services
The benefits of using a name service are:
- Name services make administration of larger networks easier and less time-consuming.
- A name service names each network object, thus enabling a user, administrator, or developer to refer to the network object by name without regard to its physical location.
- Centralized repositories reduce complexity and mass duplication of information.
- A names service provides consistent information across the enterprise.
- Network services can be relocated without any change made to clients. Database servers can be relocated without any effect on users.
- Changes can be made in a central location somewhere in the network on a database server instead of having to be stored on each client and server.
- Changes can be made in a single location and made available to all users.
- In the case of Oracle Names, whenever a change is made to an existing server or a new server is added to the network, the change is made centrally through Network Manager. This eliminates the need for an administrator to make changes to what potentially could be hundreds or even thousands of clients.
- Name services provide a single unified naming space for all network objects or entities. They uniquely identify all network resources.
- Name services provide a way for people, resources, and applications on the network to find each other without having to know each other's network address--instead people can just specify a simple, user-friendly name.
Oracle Native Naming Adapters Let Users Access Oracle Services Stored in Native Naming Environments
Most large distributed computing systems have several naming services. Maintaining these is a significant task, for which administrators often spend a great deal of time learning and developing tools. Adding another service, such as Oracle Names, requires additional learning, modifying old tools or adding new ones. A typical administrator might ask "Why doesn't Oracle use one of the naming services I already have? That way I can use the tools I already have, and maintain it in ways I'm already familiar with."
Oracle Native Naming Adapters, released with SQL*Net release 2.2 and later, resolve service names stored in customers' native (non-Oracle) naming services. They include:
- OSF DCE CDS (Cell Directory Service)
- Sun's Network Information Service (NIS), formerly known as "Yellow Pages"
- NetWare Directory Service (NDS), Novell's directory service
Native naming adapters planned for future releases of SQL*Net are:
- Internet Domain Name Service (DNS)
- X.500: The ISO Standard Directory Service originally built for use with OSI
After administrators load Oracle service names and addresses into the name service, users can connect to databases and other Oracle services by specifying the Oracle service name.
Integrating Different Names Services into your Network Environment
Oracle Names can be used in the network along with the native naming service, to provide cross-environment naming integration. Customers who use several different name services in different parts of their environment can achieve connectivity for all Oracle services by using Oracle Names.
Two-Tier Model Allows Distributed Computing
There have been various approaches to using name services in distributed environments. The industry is converging on a common two-tier model for implementing name services, however, with local name services such as Oracle Names, DCE CDS, or NIS handling local domains and communicating with each other through a global name service such as DNS or X.500. This model consists of an upper-tier global name service and a lower-tier local name service.
Global Name Service
The upper tier is a global name service that provides a standard interface and interoperability between local name services (which may be standard, that is "open," or proprietary). The global name service is based on services such as the Internet's DNS (Domain Name Service) or X.500.
For example, DNS might be used as the global name service, and Oracle Names, TNSNAMES.ORA files, NIS, and DCE CDS might be used as local name services. In this case, the local name service could be open, as is DCE CDS, or it could be proprietary, as is Oracle Names, NIS, and Banyan's StreetTalk. Alternatively, Oracle Names could be used as the global name service if only Oracle services are used, as it works across heterogeneous networks with a mix of protocols such as TCP/IP, DECnet, and SPX/IPX.
Local Name Service
The lower tier can consist of a single local name service or several local name services. For example, Oracle Names could be used as a single local name service, or in combination with other local name services, such as NIS, CDS, Novell's NDS, or Banyan's StreetTalk.
Note: Native naming adapters to use with your SQL*Net network are available through purchase of the Oracle Advanced Networking Option.
When to Use TNSNAMES.ORA, Oracle Names, or Oracle Native Naming Adapters
If you have a simple distributed network with a small number of services (about 100 or fewer), TNSNAMES.ORA files are a good solution. TNSNAMES.ORA files can resolve service names to network addresses across networks running different protocols. However, keep in mind that when changes need to be made, they must be distributed to every client and server.
If your network is more complicated and has over 100 services, Oracle Names Servers are a good solution. Because people are typically using a mix of protocols such as TCP/IP, SPX/IPX, DECnet, and NetBIOS, Oracle Names Servers are an appropriate naming solution because, like TNSNAMES.ORA files, they can resolve names across a heterogeneous network running several different protocols. Oracle Names Servers are a simpler solution than TNSNAMES.ORA files because they do not have to be located on every client and server (as TNSNAMES.ORA files do), and typically two or three Oracle Names Servers can service an entire region consisting of thousands of clients. Therefore, administration such as adding or relocating services is made much simpler in that changes only need to be made in a few locations.
If you use Oracle Names release 2.0 with the Dynamic Discovery Option, you may not need to create configuration files for your network components, and new components register themselves with the well-known Names Servers so that expanding a network is very easy. However, integrating this feature into an existing network is tricky. If you already have a large network and it is relatively static, it may not be worth the trouble to use the Dynamic Discovery Option.
One disadvantage of using TNSNAMES.ORA files or Oracle Names for name resolution is that they both store network names and addresses for Oracle services only. If you have non-Oracle services in your network environnment, you need to store them in name services other than those provided by Oracle, such as NIS, DCE CDS, or DNS.
A disadvantage of native naming services such as NIS, DCE CDS, Novell's NDS, and Banyan's StreetTalk is that they are typically specific to an operating system or specific network environment. Oracle Names, on the other hand, is a name service that spans across the entire environment and provides name resolution regardless of the operating system or network environment installed at the customer site. Oracle Names can be used in heterogeneous networks with different protocols.
Oracle Names Can Be Used as a Local or Global Name Service
Oracle Names can be used as a single local or global naming service. It can be used in conjunction with other proprietary or open naming services to provide cross-environment name resolution. For example, Oracle Native Naming Adapters for DCE CDS, NIS, Banyan's StreetTalk or Novell NDS could be installed on all clients and servers in an enterprise network already running Oracle Names to provide name resolution across multiple name services.
Currently, many organizations are using a global naming service such as DNS or X.500, and using one or more local directory or name services such as Oracle Names, Banyan's StreetTalk, or Novell NDS for their proprietary naming systems. What name service(s) you choose to run in your network environment depends on what types of applications and services are running in your environment.
Because Oracle Names is a proprietary name service, that is, it stores and resolves names and addresses for Oracle databases only, you may want to store all your Oracle services in Oracle Names, and use a directory service such as DNS or X.500 as your global naming service. (Oracle Native Naming Adapters for DNS and X.500 are planned for future releases of SQL*Net.) Since DNS is already used on the Internet, and Oracle Names is patterned after DNS, this might be a likely choice. Most corporations and organizations are already connected to the Internet, and since DNS is the name service used on the Internet, this is a likely option for many organizations. It is certainly not a requirement that you use DNS as your global name service--it just happens to be widely used already.
Administrators Can Load Oracle Service Names into their Native Naming Service
Oracle Native Naming Adapters, which are available as part of the Oracle Advanced Networking Option, allow administrators to load Oracle service names into their native name service using tools and utilities with which they are already familiar. For example, after installing the DCE CDS naming adapter on all clients and servers in a network environment, the administrator can use familiar DCE utilities to load Oracle service names into the DCE environment. After this is done, users and applications can connect to Oracle applications and services by specifying the Oracle service name or alias.
After configuring Oracle databases with Oracle Network Manager, you generate configuration files, including a NATIVE.ORA file. You then load the NATIVE.ORA file, which contains the service names and addresses, into the native naming service. For example, if you are using NIS, you load the Oracle service names and addresses into a NIS zone map using a TNS2NIS utility provided. For information on how to load service names into the native naming service see the Oracle documentation for your platform.
Connecting to Databases with Oracle Service Name
After the Oracle service names and addresses have been loaded into their native naming service, users can connect to databases by specifying the Oracle service name (global database name). For example:
sqlplus scott/tiger@sales.us.oracle.com
They can specify just the database name if the database is located in the default domain:
sqlplus scott/tiger@sales
Multiple Name Services Allowed
With this release of SQL*Net, network administrators can specify that one or more native naming services, such as NIS or DCE CDS, in addition to Oracle Names and TNSNAMES.ORA, be contacted to resolve network names to addresses. Using Oracle Network Manager, administrators can list the naming services in any order of priority.
Prepare to Use the Network Manager
Oracle Network Manager is a product included with SQL*Net version 2.1 and later that enables you to create configuration files without having to type in the precise syntax of the files manually. Oracle Network Manager generates the files based upon standard defaults and the unique information you provide through its graphical user interface. Unless you are using Oracle Names and the Dynamic Discovery Option, you must use Network Manager to create the configuration files.
To use the Network Manager effectively you must have detailed information about the network at hand. This section describes the information you must have ready.
Note: You must use Network Manager to create all SQL*Net configuration files (except PROTOCOL.ORA, which must be created by hand). Configuration files created manually are not supported by Oracle Corporation. You can edit most values in the SQLNET.ORA file using the SQLNET.ORA Editor.
Know the Network
The Network Manager knows the syntax of the configuration files and it knows the default values for parameters in those files. However, it knows nothing about your network until you supply the information. In fact, supplying accurate information to the tool is your main task in using it.
Names
Choose names for the following:
- all domains (unless you are using only one domain--WORLD)
- all network listeners, and the computers (nodes) on which they run
Note: As of SQL*Net release 2.1 and the Oracle Server release 7.1, the service names you provide must match precisely the unique global database names assigned by the database administrator. To achieve this, it may be necessary to change some of the service names you have been using. For example, if your previously defined SQL*Net release 2.0 network has service names that do not match the global database names, those service names must be changed. Similarly, if the network includes some databases that were named before you established your current domain names, their global database names and service names must reflect the current domain structure.
- all Interchanges, if any, and the computers (nodes) on which they run
- all Names Servers, if any, and the computers (nodes) on which they run
- all client profiles (A client profile or client type is a group of clients with the same communication requirements.)
Note: Network Manager automatically generates names for Interchanges, Names Servers, and client profiles. You do not need to supply names for them unless you want to change the Network Manager-generated defaults.
Note that even if you have a one-protocol network, that is to say, a one community network, you must supply a name for that community. The community names should follow global naming conventions. See the section "Naming Considerations" earlier in this chapter. The name of each component within the network must be unique.
Addresses
Define addresses for the following:
- all Names Servers, if any
The addresses for these components consist of the names of the communities of which they are a part and protocol-specific information.
Protocol Specific Information
Different protocols require different protocol-specific information. The following table summarizes the keywords for the protocols currently supported in a TNS network.
| Protocol
| Keywords
|
| AppleTalk
| SERVICE
|
|
|
|
| ASYNC
| PHONENUMBER
|
|
| ASYNC_SERVER
|
|
| LOCAL_LOOKUP
|
|
|
|
| Banyan
| ITEM
|
|
| GROUP
|
|
| ORGANIZATION
|
|
|
|
| DECNet
| NODE
|
|
| OBJECT
|
|
|
|
| DCE
| SERVICE
|
|
| SERVER_PRINCIPAL
|
|
| CELL_NAME (optional)
|
|
|
|
| LU6.2/APPC
| LU_NAME
|
|
| LOCAL_LOOKUP
|
|
| TP_NAME
|
|
|
|
| Named Pipes
| PIPE
|
|
| SERVER
|
|
|
|
| OSI
| NSAP
|
|
| TSEL
|
|
| or
|
|
| HOST
|
|
| SERVICE
|
|
|
|
| SPX/IPX
| SERVICE
|
|
|
|
| TCP/IP
| HOST
|
|
| PORT
|
The Network Manager provides default values for many of these protocol-specific keywords. See the Oracle operating system-specific documentation for your platforms for information on what values to supply for the protocol keywords.
Connect Data
You must also provide the system identifiers (SIDs) for database servers. SID names typically match the database name; however, this is not a requirement.
SQL*Net V1 Connect Strings
If your network includes both SQL*Net version 1 and version 2, have available the names of the files that hold the Version 1 connect strings and their aliases, and know where in the file system they are stored.
Parameters
The LISTENER.ORA file includes a number of required and optional parameters that describe the listener. You should gather the parameter information and have it ready to use in the Network Manager. The parameters for LISTENER.ORA are described in Appendix A, "Contents of the Configuration Files."
MultiProtocol Interchange Information
The Network Manager creates configuration files for the Interchanges in your network, if you have them, based on information you supply. The files are described in Appendix A of the MultiProtocol Interchange Administrator's Guide.
Names Servers
If you are using Oracle Names without the Dynamic Discovery Option, the Network Manager creates a NAMES.ORA configuration file for each of the Names Servers in your network. See the Oracle Names Administrator's Guide for information about this file.
Multiple Network Managers
If your network includes Oracle Names, you may want to provide further information about the naming structure of your network. You may want to include delegated administrative regions, so that widely separated parts of your network have some autonomy in their administration. See the Oracle Names Administrator's Guide for further information.
Database Links
If you are using Oracle Names, you may want to specify additional information such as username and password for the global database link that is automatically created for each database defined in Network Manager. See Chapter 5, "Using SQL*Net," in this manual, and Chapter 5, "Entering Component Information" in the Oracle Network Manager Administrator's Guide, and Oracle7 Server Distributed Systems, Volume I and the Oracle Names Administrator's Guide for information on global database links.
Use the Oracle Network Manager
Once you have done the planning, made your decisions, and gathered the information you need, you are ready to configure the network. To do this, use Oracle Network Manager. This tool makes creating the configuration files relatively easy. Equally important, it helps you make them error free.
You will find complete instructions about the use of Network Manager in the Oracle Network Manager Administrator's Guide.
After you have created and distributed the configuration files, you can start and use the network. Information about using the network is![[*]](jump.gif)
, "Using SQL*Net".
