Configure multiple listeners to facilitate load balancing.
Configure Oracle Load Balancing
The most common multiple listener configuration is the case where each database instance has its own listener. However, it is also possible to define several listeners, one for each incoming protocol. Listener load balancing is the term used to describe the distribution of connections among Oracle listeners to ensure that incoming requests do not have to wait for a listener connection. By having connections distributed among a number of listeners, no single listener is likely to be overburdened, and connection time will be faster.
SELECT network "Protocol",
DECODE( SUM(totalq), 0, 'No Responses',
SUM(wait)/SUM(totalq) || ' hundredths of seconds')
"Average Wait Time per Response"
FROM
v$queue q,
v$dispatcher d
WHERE
q.type = 'DISPATCHER'
AND
q.paddr = d.paddr
GROUP BY network;
You can define multiple mts_listener_addressparameters in the init.ora file, one for each listener. For multiple listeners to be enabled for multi-threaded servers, the database init.ora file must include the DISPATCHERS parameter.
Randomizing Oracle Shared Server Connections
MTS Server was replaced by Oracle Shared Server beginning with the release of Oracle 9i.
In Oracle 9i, the dispatcher for each shared server registers with all listeners specified by the LISTENER parameter.
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 their tnsnames.ora. The randomly selected listener spawns a server process and hands off the incoming connection to the server.
In Oracle 11g R2, when using "pre-started dedicated server processes", the listener that starts the dedicated server process is the only one that registers it.
As a result, the pre-started dedicated server process will only be available to that listener and cannot participate in listener load balancing with other listeners.
This behavior contrasts with "shared servers", where any shared server process can register with multiple listeners, allowing load balancing across listeners.
To enable listener load balancing with dedicated servers, the server processes must be dynamically started by the listener. Pre-started dedicated servers are a fixed resource and do not register with other listeners, so they cannot participate in load balancing across multiple listeners.
The following diagram illustrates load balancing. Notice that 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.
This diagram represents a multi-threaded Oracle Database architecture using shared server processes.
Here's a breakdown of its components and features:
Components in the Diagram:
Client:
The client initiates the connection to the Oracle database through a network.
Listener:
Listeners (labeled as Listener) handle incoming client requests.
They establish communication between the client and the database by routing client requests to appropriate dispatchers or server processes.
Dispatchers:
Shared dispatchers are used for managing multiple client requests efficiently.
These dispatchers route client requests to the server processes.
Shared Server Processes:
Represented as yellow ovals labeled NY_VAX and NY_SEQ.
These shared server processes execute database requests for multiple clients simultaneously.
Databases:
Two separate databases or schemas (Emp and HR) are shown as green ovals.
These represent specific database resources or schema objects accessed by the server processes.
Features Highlighted:
Shared Server Architecture:
This architecture uses shared server processes (instead of dedicated server processes) to handle client requests, optimizing resource utilization.
Load Balancing:
Multiple listeners and shared server processes ensure that client connections are balanced across available resources.
This improves scalability and reduces the risk of bottlenecks.
Efficient Resource Utilization:
Shared server processes are used to minimize the number of server processes required to manage multiple clients.
Centralized Access:
All requests are routed through listeners, ensuring streamlined and centralized management of client connections.
Multiple Schema or Database Support:
The diagram demonstrates support for multiple schemas or databases (Emp and HR), illustrating the flexibility of the architecture.
This setup is typical for Oracle's **shared server mode**, which is often used in environments with high concurrency requirements to optimize server performance and memory utilization.
If a set of databases is 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. To configure listener load balancing, the administrator must configure multiple listeners for each database. There can be multiple listeners on the same platform as the database, or, for multi-threaded servers, the listeners can be on different nodes.
The next lesson discusses how to set up connection pooling.
