Oracle Names Administrator's Guide

Library

Product

Contents

Index

Introduction to the Dynamic Discovery Option

This chapter describes the Dynamic Discovery Option, or DDO, in detail. It covers the following topics:

What is Oracle Names with the Dynamic Discovery Option?

How a network works with the Dynamic Discovery Option

Oracle Names architecture with the Dynamic Discovery Option

Key components in Oracle Names with the Dynamic Discovery Option

Attention: The Dynamic Discovery Option only works on nodes that use SQL*Net release 2.3. Services will not be automatically registered if SQL*Net release 2.3 is not used, and clients will not be able to find the well-known Names Server.

What is Oracle Names with the Dynamic Discovery Option?

Oracle Names 2.0 with the Dynamic Discovery Option enables you to have configuration free networking while providing all the functionality of Oracle Names. The new features include the following:

well-known Names Server addresses

dynamic service registration

replication of service definitions

The following sections describe in detail each of the new Dynamic Discovery features.

Well-Known Name Server Addresses

Oracle Names 2.0 with the Dynamic Discovery Option allows you to define a well-known service address for up to five Oracle Names Servers.

In Dynamic Discovery networks, well-known Names Server addresses are hardcoded into both the Oracle Names Servers and their clients. Oracle Names Servers are available at these well-known addresses, so that clients do not need to be told, by way of configuration files, where to find the Names Server. This effectively eliminates the need for the administrator to distribute the SQLNET.ORA configuration file so that clients can find the appropriate Names Server.

Note: Your network can have no more than five well-known Names Servers, that is, Names Servers that use the Dynamic Discovery Option.

Dynamic Service Registration

Oracle Names 1.0 required administrators to enter the names and addresses of all databases in the network into Oracle Network Manager. Network Manager then created a network definition which it stored in a database. Each Names Server loaded the network definition when it is started.

Oracle Names 2.0 architecture using the Dynamic Discovery Option now supports dynamic service registration of Names Servers, network listeners, and database servers.

When a network listener using SQL*Net 2.3 is started, it automatically registers itself and the database(s) it listens for with a well-known Names Server.

Replication of Service Definitions

Since well-known Names Servers continually reconcile the contents of their cache with those of other active well-known Names Servers, registration with a single well-known Names Server is sufficient for an object to be known by all the well-known Names Servers on the network. This concept is known as service replication.

How a Network Works Using the Dynamic Discovery Option

When you create a new network that includes SQL*Net 2.3 and Oracle Names 2.0 with the Dynamic Discovery Option, you do not need to create any configuration files, and therefore you do not need to use Network Manager. The only configuration file you need is a LISTENER.ORA for every node with a database listener. This file is created automatically during installation.

Note: Other configuration files are required only if you want to have non-default values for some of your configuration parameters. For more information see "Non-default Parameters".

The administrator needs to provide YP or NIS aliases for each of the machines that will become well-known Names Servers. The required YP or NIS aliases are oranamesrvr0, oranamsrvr1, oranamesrvr2, oranamesrvr3, oranamesrvr4. The TCP/IP port used by the well-known Names Server is 1575. This information is hard-coded into clients and services in the SQL*Net 2.3 network.

Once the Names Server comes up, it listens at a well-known address. Then listener is started and registers itself and the services for which it listens, with a Names Server. The client, listener or service then attempts to register with the Names Server on a node given one of the following aliases oranamesrvr0-4. By default it will try to register first with oranamesrvr0. If that Names Server is not available, it tries to register with oranamesrvr1, and so on. When a Names Server receives a registration from a service, it immediately replicates that registration to all other well-known (and registered non well-known) Names Servers on the network. See your platform-specific documentation for details on how to perform aliasing for your network.

Once you have started DDO, the Names Server remembers the addresses of all databases. If a Names Server stops and starts, critical network definitions can either be downloaded from another well-known Names Server that is running, or checkpoint files can be retrieved and the integrity of the definition information saved. See the section "Checkpoint Files" later in this chapter for more information on checkpoint files.

Oracle Names Architecture With the Dynamic Discovery Option

Oracle Names with the Dynamic Discovery Option eliminates the need for preconfigured database addresses. By doing away with administration procedures such as manually configuring domains and regions, Oracle Names with the DDO significantly reduces the network maintenance responsibility of the administrator.

If your network is currently using a domain based naming model, or large enterprise-scale networks which requires the use of domains in the future, your network is not suitable for using the DDO. See "Choose Whether to Use the Dynamic Discovery Option" in Chapter 1.

Note: There are certain circumstances in which you may want to manually configure a Names Server. Please see "Non-default Parameters" for more information on how to manually configure your Names Server while using the Dynamic Discovery Option.

Change in the Treatment of Domains

Dynamic Discovery networks are not subdivided into regions and domains. All services that register are replicated to all well-known Names Servers in the network. Therefore, there is no need for Names Servers to forward a client's query to another Names Server in another region or domain. If there are Names Servers from previous releases of SQL*Net on the network, the well-known Names Servers act as one region, and the rest of the Names Servers work as they did in previous SQL*Net releases.

A single region within a multiple region network can use the Dynamic Discovery Option. For more information on the procedures for this particular network setup, see Appendix C, "Advanced Topics".

Since the names and their definitions are replicated to all Names Servers on the network, and are not subdivided between domains, there is no longer any real meaning to the domain portion of a name. Names may include periods within them, but the domain portion will not get interpreted.

For example, when a name is registered with a well-known Names Server there is no restriction on the domain portion of the name. Since the Names Server is not managing any particular domain, it is not required that all names it stores have the same domain(s) in their name.

Note: If, for any reason you decide to divide the network into domains Oracle strongly recommends that you continue to use a consistent naming convention in your network. That is, if you are using .WORLD, continue to use the naming convention .WORLD.

Default Domains

Since DDO is designed to eliminate the need for configuration and configuration files, there is no need for a default_domain to be set in your network. If you are upgrading a network that has existing database domains, Oracle recommends that you continue to maintain the default_ domain parameter from existing SQLNET.ORA file.

If there is no default_domain parameter set, then the service names are stored by the Names Server exactly as they are registered. (The name which is registered originates from the database name provided in the LISTENER.ORA file generated at the time of installation. If the database name is EMP, clients use EMP to successfully connect to the database. If this name is EMP.ACME.COM the clients will use EMP.ACME.COM.

If there is a default_domain set using SQLNET.ORA, the default_domain will be appended to both unqualified names names being registered, and unqualified names being queried. If the default domain is WORLD, a database registered as EMP will be EMP.WORLD. A database registered as SALES.ACME.COM will not have the default_domain file appended because that name is fully qualified.

Clients using EMP as a connect string get the default_domain appended during the name lookup (EMP.WORLD) and this will allow the connection to succeed. A query for SALES will also be appended with the .WORLD, but this will not match the name registered for the SALES database. Clients must use the full name, SALES.ACME.COM to retrieve the address of the SALES database.

Simple names can be made fully qualified by appending a period ".". For example, the name "ACME." will not have the default domain appended to it during registration or queries.

Key Components of Oracle Names with the Dynamic Discovery Option

The following section describes the key components of Oracle Names, when the Dynamic Discovery Option is enabled.

With the Dynamic Discovery Option, a network using the Oracle Names Service consists of:

one or more Oracle Names Servers

We recommend that you set up at least two Names Servers for fault tolerance. Note: There must be at least one, but no more than five well-known Names Servers when you use the Dynamic Discovery Option

one or more databases

one or more listeners

one or more clients

Figure 2-1 shows the components described above with the Dynamic Discovery Option enabled .

Figure 2 - 1. Components of a Network Using Oracle Names with the Dynamic Discovery Option

Components of a Names Server

The Oracle Names Server is a network service comprised of multiple components. Each Oracle Names Server contains :

the cache--the Names cache is an in-memory database of all data required to resolve names. The cache contains the following types of data:

system information--includes the service addresses of all of the Names Servers.

registration information--includes all registered TNS services which includes other Names Servers and information automatically generated by the Names Server when it was installed.

All cache data is always in memory to guarantee high performance.

request processor--receives incoming address requests and looks through the cache for the answer.

forwarder --takes queries for names and forwards the query on to the appropriate Names Server.

Figure 2-2 shows the components of the Names Server using the Dynamic Discovery Option and their relationships.

Figure 2 - 2. Oracle Names Server Components Using the Dynamic Discovery Option

Checkpoint Files

The checkpoint files are internal configuration files. They are described here for your information only. If at any time during operation, the Names Server cannot get the information it needs to function, it uses the checkpoint files. When first started, at regular intervals, and when stopped, each Names Server writes to operating system files known as checkpoint files.

Note: These text files are internal to Oracle Names and should not be altered. All changes to this file will be overwritten at the next update interval.

The following is a description of checkpoint files and their function:

ckpcch.ora - dynamic registration data cache checkpoint , which contains all of the dynamic information before the Names Server was stopped. After a crash or restart of the Names Server, the previously cached data is loaded from the checkpoint.

ckpcfg.ora - Checkpoint configuration , which includes the current settings of all configuration parameters . This is used to start the Names Server when normal startup information is not available.

Checkpoint files are read only when the Names Server is started, or restarted. If a Names Server is started and another Names Server cannot be reached, the latest cache checkpoint file is used. This provides the Names Server with the latest available data. The cache checkpoint is written at every update to capture the latest changes to dynamic information.

Prev Next

Library

Product

Contents

Index