MTS and Dedicated Listener(Legacy, Deprecated)

SQL*Net version 1.0 required the listener to spawn a new process as a distinct operating-system task for each new connection. (We will explore the spawning process more in the next lesson.) But with the introduction of MTS with SQL*Net version 2.0, Oracle enabled the listener connection to dispatch numerous connections through the same sub-process. Unlike a traditional Oracle listener that assigns separate UNIX process IDs (PIDs) for each remote connection, MTS handled all incoming requests through a set of pre-allocated dispatcher processes. This translates into faster performance for most online tasks and less resource consumption on the part of the Oracle server.

Question: Does the "Oracle Shared Server" from Oracle 9i handle all incoming requests through a set of pre-allocated dispatcher processes?
In the Oracle Shared Server architecture, introduced in Oracle 9i, all incoming requests are handled through a set of pre-allocated dispatcher processes. The Shared Server architecture is designed to allow many user processes to share very few server processes, thereby maximizing system resources and enabling the system to support a greater number of users. When a client sends a request, it first reaches a dispatcher. The dispatcher's role is to route the request to a shared server process. If all shared server processes are busy, the dispatcher places the request in a request queue.
It's important to note that the dispatcher processes themselves do not process requests. Instead, they act as a communication layer between the client and the shared server processes. They manage the routing of the client requests to the shared server processes and the returning of the results from the shared server processes back to the appropriate client.
In a well-tuned Oracle Shared Server environment, a dispatcher process is created for each network protocol, ensuring efficient use of resources while minimizing potential communication bottlenecks. Thus, Oracle Shared Server optimizes system resources and improves the system's ability to scale with increased user demand. It is a valuable feature for environments with a large number of connections performing a high volume of short, quick tasks.

In general, MTS offered benefits such as

1. reduced memory use,
2. fewer processes per user, and
3. automatic load balancing.

However, be aware that MTS is not a panacea, especially when you want to invoke a dedicated process for your program. For Pro*C programs and I/O-intensive SQL*Forms applications or any process that has little idle time--you may derive better performance using a dedicated process as opposed to using MTS. This is why many Oracle servers have two listener processes, a dedicated listener for high I/O tasks and an MTS listener for all other tasks.
It can be very confusing to tell whether the MTS is turned on, much less working properly. In order to determine if you are using the MTS, you must query v$parameter, or check your init.ora file for MTS parameters. To query the status of the MTS, you must query the v$dispatcher and v$queue views; non-MTS systems require a check only of the listener. The next lesson takes a closer look at MTS and the dedicated listener.