Understanding SQL*Net

Listener Load Balancing

The listener load balancing feature provides for the distribution of connections among listeners for Oracle7 Servers. By having connections distributed among a number of listeners, no single listener is likely to be overburdened, and connection time will be faster.

Note: You may have a many-to-many relationship between listeners and equivalent database instances.

Once randomly selected, the listeners behave as they have in previous releases, distributing connection requests to the dispatchers on the basis of their load (for multi-threaded servers) or to dedicated servers.

How Listener Load Balancing Works

There can be multiple listeners for a single database or multiple listeners for two or more equivalent databases.

Multiple Listeners for a Single Database

You can have more than one listener for a single database of any kind. The listeners for a dedicated server must be on the same node as the server. Listeners for a multi-threaded server can be distributed on different nodes; the dispatchers are able to register with listeners across nodes.

Suppose there were listeners on two different nodes that were listening for a single multi-threaded server, as shown in Figure 2 - 4.

Figure 2 - 4. Multiple Listeners for a Multi-Threaded Server

All dispatchers register with all the listeners listed in the database parameter file, and the client randomizes between the listeners. The listener passes the address of the least-used dispatcher to the client, and the client connects using that dispatcher.

Multiple Listeners for Equivalent Databases

If there is a set of databases configured to provide equivalent service (such as a replicated database) on the network, you can use listener load balancing among several listeners that all listen for more than one instance of the database. An example of this is shown in Figure 2 - 5.

Figure 2 - 5. Multiple Listeners for Equivalent Databases

In this figure, both listeners listen for two database instances. The client randomizes between the listeners. The listener passes the address of the least-used dispatcher to the client, regardless of whether the dispatcher is for Emp or HR, because they are virtually identical.

Note: Oracle Parallel Servers have their own method of listener load balancing. See your Oracle Parallel Server and platform-specific documentation on how to configure parallel servers. Use the listener load balancing method you prefer.

Listener load balancing may be particularly useful in replicated environments, where a particular group of users may have a schema that's the same across different databases, even though other things on the database may be different. In such a case, you could allow the users to update any of the replicas they happened to get connected to, and synchronize them later.

How Connections Are Made

The dispatcher for each multi-threaded server registers with all listeners designated in the MTS_LISTENER_ADDRESS parameters in the database parameter file. When a connection request is made, the client interface code randomizes among listeners within the same community. The listener redirects the client connection request to the least-used dispatcher, which connects the client to a shared server process.

Similarly, the clients that want to connect to a dedicated server randomize their connection requests among the listeners on the same protocol for that server, as listed in the TNSNAMES.ORA file, or stored in the Names Server cache. All listeners for a dedicated server must be on the same node. The randomly selected listener spawns a server process and hands off the incoming connection to the server.

Note: You cannot have listener load balancing with prestarted dedicated servers, because a prestarted dedicated server process registers only with the listener that started it.

Configuring Listener Load Balancing

For information about how to configure listener load balancing, see "Configuring Listener Load Balancing" in Appendix A.