Understanding SQL*Net
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. 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.