Oracle Names Control Utility Reference
Issues and DDO
This appendix covers complex network issues that are relevant to configuring and managing Oracle Names 2.0 with the Dynamic Discovery Option.
Because Oracle does not recommend using the Dynamic Discovery Option on complex networks, this appendix is a reference, or informational chapter to be used by administrators who are exploring the possibility of upgrading a complex network to Oracle Names 2.0 with the Dynamic Discovery Option.
Note: If you are gradually upgrading your network to use DDO, when you finally upgrade to a complete network that uses DDO, it will be necessary to perform additional manual administration steps to ensure your network is a pure DDO network.
The Function of Network Components
When you configure and run a network with Oracle Names 2.0 and the Dynamic Discovery Option, there are three main network components that must be able to communicate and find each other:
- Oracle7 Servers--Oracle7 Servers must know how to find a Names Server in order to register themselves automatically. If they are not registered automatically, they need to be defined in the network definition using Network Manager.
- Clients--Clients on the network must know how to find the Names Servers.
Constraint Issues
This appendix discusses the following complex network issues:
- Local backward compatibility constraints - issues that arise within the local region, when you are mixing versions of Oracle Names and SQL*Net
- Community constraints -constraints that need to be considered when you configure a network with the DDO with more than one community
- Multiple region constraints-using Oracle Names 2.0 with the DDO in a complex network with multiple regions
Note: Remember, if you have a network that stays the same for long periods of time, whether large or small, converting the network to the DDO may not be worth the effort. Administrators of networks might find the Dynamic Discovery Option more troublesome to use than its benefits warrant.
The following table illustrates further compatibility issues when you are considering upgrading a complex network.
| In Order for....
| You Need to Do One of the Following...
|
| the client to be able to find the Names Server
| -Assign a well-known Names Server address
-Configure a Names Service address in the
NAMES.PREFERRED_SERVER parameter in
the SQLNET.ORA file.
|
| the database name and address to be provided to the Names Server
| -automatic registration using the listener
-enter the databases name and address into the network definition using Network Manager
-manual registration of the service using
NAMESCTL
|
| Names Server name and address to find the well-known Names Server
| -Assign a well-known Names Server address
-enter the Names Server name and address using Network Manager
-manual registration of the service using
NAMESCTL
|
| the addresses of all Names Servers from certain foreign regions to to be known to local Names Servers, therefore ensuring Names Server
topology
| -enter the addresses into the network definition using Network Manager
|
Points to Remember
- When a new Names Server enters a region, that new Names Server needs to find an existing well-known Names Server. When the new Names Server finds the existing well-known Names Server, it downloads the current cache information from the existing well-known Names Server and registers itself to all well-known Names Servers in that region, based on the cache information that it was given when it downloaded.
- Each region cache in a multi-region network must know about all of the Names Servers in all of its own subregions, along with the ROOT region.
- Manually configuring a multi-region network is not advised for DDO. If your network is that complex, you might find the DDO more troublesome to use than its benefits warrant.
Local Backward Compatibility Constraints
You must determine whether your network has any local backward compatibility constraints. Read this section if your network includes clients and servers using earlier releases of SQL*Net and Oracle7. These rules tell you whether you can use a well-known Names Server.
The following must all be true, regardless of the underlying community structure:
- all local Names Servers are upgraded to 2.3
This means that Names Servers will work even if the region spans multiple communities. As long as the network definition is necessary for pre-2.3 support, there will be no community issues to resolve.
- New Oracle Names Servers must also be defined in the network definition as long as there are SQL*Net 2.2 (or earlier) clients on the network that have not been upgraded.
The network definition is the source of the NAMES.PREFERRED_SERVERS parameter in the SQLNET.ORA file, which the pre--2.3 clients use to find their Names Servers.
- Since all Names Servers must read the network definition, and all Names Servers are defined in the network definition, Names Servers do not need well-known Names Servers to know about each other.
- All Names Servers will continue to use the network definition because they must get information for 7.2 databases whenever the data is modified.
- New and upgraded Names Servers can use well-known addresses as long as the new well-known Names Servers are defined in the network definition using oranamesrvr0-4.
- Clients, databases, and listeners on an existing network already have a NAMES.PREFERRED_SERVERS defined in their SQLNET.ORA file enabling them to find all local Names Servers, regardless of whether they are using a well-known Names Server.
These are configured addresses that are provided to Oracle Names clients, and SQL clients and listeners. They are also provided to other Names Servers in the network definition.
- When all SQL*Net 2.2, (or earlier) clients have been upgraded, the Names Server definitions can be dropped from the network definition.
In this case there must be at least one well-known Names Server and no community constraints. For more information on this issue, see "Community Constraints" later in this appendix.
- When all databases and listeners in the region are upgraded to Oracle 7.3, service information in the network definition can be dropped because services are now automatically registered.
- When the previous two items are true, the network definition and the NAMES.PREFERRED_SERVERS can be dropped entirely. All of the Names Servers and all of the clients are now upgraded and the network definition is unnecessary in the Dynamic Discovery network.
Community Constraints
This section discusses community constraint issues within an existing hierarchy.
A community is defined as the set of all machines that may be directly connected using a given transport protocol. Communities are generally joined by MultiProtocol Interchanges.
In networks or regions which consist of multiple communities, the well-known Names Server mechanism is not sufficient to enable clients to find all local Names Servers. Therefore, it is necessary to maintain the NAMES.PREFERRED_SERVERS parameter in the SQLNET.ORA file even if there are no local backward compatibility constraints.
To enable Names Servers to find out about each other you must do one of the following:
- maintain the network topology data in the network definition
- manually "prime" the Names Server by using the NAMESCTL command to register another existing Names Server.
After this is done, restart the Names Server using the NAMESCTL>STARTUP command.
Multiple Region Constraints
There are several constraint issues for networks with multiple regions that exist within a regional hierarchy:
- New or additional Names Servers must be defined in any relevant multiple region network definition.
If there are other regions (most likely SQL*Net 2.1 or 2.2 regions), the Names Servers in those region will need the new well-known Names Server address to forward queries to any Names Servers in those region.
- There must be a local network definition that includes the network topology data describing the relevant multiple regions in that network.
- If multiple regions exist in the same community, and the same TCP domain, then well-known Names Servers should not be used anywhere.
