Describe how MTS differs from a dedicated listener.
MTS and Dedicated Listener(Legacy, Deprecated)
SQL*Net version 1.0 requires 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 has 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 handles 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.
In general, MTS offers benefits such as reduced memory use, fewer processes per user, and 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.