MTS Configuration and Operation

5.1 MTS Architecture     ~~~~~~~~~~~~~~~~         The Oracle Multi-Threaded Server requires a listener. An example         architecture is shown in figure 5.1 below.             Figure 5.1:    Example MTS Process Architecture                 |--->Listener                                    +--------+                                    |         |             |--->IPC-Dispatcher     |    SGA  |                                             |         |       Shared-Server            |--->TCP-Dispatcher     |        |                                    |         |                                    +--------+                    |-- = a listen end point             The dispatchers belong to a specific instance and are protocol         specific message handlers. When a dispatcher starts it locates a         RANDOM unused address to listen on for its given protocol.         It then registers this address with the listener and then WAITS         for a call.           Dispatchers can be seen in the process listing (ps command) as         'ora_dNNN_SID' where 'NNN' is a number.         Shared servers can be seen in the process listing as 'ora_sNNN_SID'.         The number of servers and dispatchers are not related.     5.2 Registering with the Listener     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~         This section describes how an MTS service gets registered with the         listener.                     a) The listener is started and listens on the listed addresses.               At this point in time the only services it knows of are the               pre-defined services listed in listener.ora.                                            +----------+                        IPC,KEY=mysid |--->| Listener |                                          |          |                   TCP,HOST=..,PORT=.. |--->|           |                                         +----------+                  |--- = listen end point                     b) When an Oracle instance is started which is configured for               MTS each dispatcher firstly gets its OWN listen address.               This address is a random listen point for the given protocol.                    TCP,             +------------+                  HOST=myhost |--->| Dispatcher |                  PORT=random      +------------+                c) Each dispatcher then calls the listener using the address               specified in the init.ora parameter 'MTS_LISTENER_ADDRESS'               (or LOCAL_LISTENER in Oracle8).  In 8.x and onward, PMON               calls the listener.                    TCP,             +------------+          +----------+                  HOST=myhost |--->| Dispatcher |---->|--->| Listener |                  PORT=random      +------------+          |          |                                                      |--->|        |                                                         +----------+                                                                      d) The dispatcher then tells the listener the protocol it               is using and the address on which it is listening.              e) The listener adds the dispatchers 'MTS_SERVICE' and its               address to its list of known services.  Note: MTS_SERVICE               is depreciated in 8 and replaced with SERVICE_NAMES.                            TCP,             +------------+                          HOST=myhost |--->| Dispatcher |                          PORT=random      +------------+                                                  +----------+                        IPC,KEY=mysid |--->| Listener |                                          |          |                   TCP,HOST=..,PORT=.. |--->|           |                                          +----------+                f) Any connect requests for the newly registered service / protocol               can now be told the address of the dispatcher.                NOTE: Until a dispatcher has registered its service with the                  listener connection requests CANNOT be put through to it.     5.3 Client Connections to MTS     ~~~~~~~~~~~~~~~~~~~~~~~~~         A client process wanting to connect to an Oracle instance using MTS         should go through the following steps:                  a) Call the listener                b) The listener tells it to call back on the address where                   the dispatcher is listening (a REDIRECT)                c) The client calls the dispatcher and establishes a connection.                d) The dispatcher now has a CLIENT connection ESTABLISHED and                   will also continue to listen for any new connections.                e) The client sends a SQL message to the dispatcher.                f) The dispatcher unwraps this message packet and places the                   request onto a queue in the SGA (System Global Area).                   This queue has NOTHING to do with SQL*Net. The SQL*Net                   layer ends in the dispatcher.                g) A shared server will pick up the request from the SGA queue                   and process it. When there is any result this is placed                   on a separate queue in the SGA ready for the dispatcher.                h) The dispatcher picks up the response message from the SGA                   and wraps this into a SQL*Net message. This is passed                   back to the client.     5.4 Configuration     ~~~~~~~~~~~~~         MTS is configured on a 'per-instance' basis and is set in the         init<SID>.ora file.           The main parameters are explained below:               MTS_SERVICE (Depreciated in 8.x, use SERVICE_NAMES)                Defines the SERVICE name that the dispatchers will register                with the listener. As pre-configured services use the                ORACLE_SID for the service name there are 2 options for setting                the MTS_SERVICE.                        a. If you choose the SAME name as the ORACLE_SID                           then connections requesting a particular SID will                           get an MTS connection if available (Unless the                           client calls asking for (SERVER=DEDICATED).                           If MTS is not available they will get a dedicated                           connection.                        b. If you choose an MTS_SERVICE different to the                           ORACLE_SID clients can explicitly request and MTS                           or a non MTS connection using separate aliases.                           If MTS is requested and is not available they will                           NOT get defaulted to a DEDICATED connection.               MTS_LISTENER_ADDRESS or LOCAL_LISTENER                This should be an address on which the listener is KNOWN                to be listening as it tells the dispatchers where to                register.                              MTS_DISPATCHERS                Several lines can list the protocol and number of dispatchers                for that protocol.                NOTE: Some protocols do NOT support MTS. A dispatcher MUST                      be able to handle existing connections AND be notified                      of any new connect requests. If a protocol or its                      operating system interface cannot support this mode of                      operation the protocol cannot be used for MTS connections.             MTS_MAX_DISPATCHERS                Maximum number of dispatchers to allow.               MTS_MAX_SERVERS                Maximum number of shared servers to allow.               MTS_SERVERS                Initial number of shared servers.             Note that as shared servers and dispatchers may be started at         database startup OR at a later point in time any interim changes to         the SQL*Net configuration files may be picked up by newly started         processes. This can lead to some confusion - it is advisable to         restart all processes if there have been any major configuration         changes.     5.5 Example additions to 'init<SID>.ora'     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~           # ---------------------------------------------------------------------         # Example init.ora extension to start MTS dispatchers         #         mts_service=         "MV713"     <-- Choose a SERVICE name for MTS                 # This is the ADDRESS of a LISTENERs Listen End Point so we can         # register our service         mts_listener_address="(ADDRESS=(PROTOCOL=ipc)(KEY=mysid))"                 mts_dispatchers= "(pro=ipc)"          <-- Start 1 IPC dispatcher         mts_dispatchers= "(pro=tcp)"          <-- And 1 TCP dispatcher                 mts_max_dispatchers=10                <-- No more than 10         mts_max_servers=10                    <-- and no more than 10 servers         mts_servers=4                         <-- Start 4 servers at startup         5.6 Checking an MTS connection     ~~~~~~~~~~~~~~~~~~~~~~~~~~         a) Configure ALL SQL*Net files and start the listener. You are            advised to use the environment variable TNS_ADMIN to point to            the directory where the SQL*Net configuration files reside.           b) Add the MTS configuration required to the init<SID>.ora file.           c) Start up the database.           d) Do a process listing to check what 'ora_..._SID' processes            exist for your ORACLE_SID. There should be 'ora_sNNN_SID' and            'ora_dNNN_SID' for the shared servers and dispatchers that you            have configured. If not check the 'BACKGROUND_DUMP_DEST' directory            (as specified in your initSID.ora file) for RDBMS trace files or            entries in the alert log. (Default location for these files is            $ORACLE_HOME/rdbms/log)           e) Use the command:                  lsnrctl services              This should list the dispatchers that have registered with the            listener. If no dispatchers have registered check for RDBMS trace            files as in step (d).           f) Check the output of 'lsnrctl services' to ensure that all            dispatchers (or prespawned servers) show valid listen end points.             Ie: (ADDRESS=...) shows a valid address. If not they may not be                contactable.            Eg: For TCP/IP if (HOST=0.0.0.0) then it is likely that your system                does not have 'hostname' set OR the hostname that IS set is not                defined in your /etc/hosts file.             g) Use 'sqlplus system/manager@mtsalias' where mtsalias is an            alias in the tnsnames.ora file that will try to connect to            an MTS service for your database.           h) Once connected check that you have an MTS connection thus:                  select username, program, server from v$session                where audsid=userenv('sessionid');              This should return a row for your session that shows server as            SHARED. If it shows 'DEDICATED' you have a DEDICATED connection.                  5.7 Common Problems with MTS     ~~~~~~~~~~~~~~~~~~~~~~~~        1. Error:  ORA-00101: invalid specification for parameter mts_dispatchers                ORA-00102: network protocol XXX cannot be used by dispatchers         Cause:  The selected protocol adapter is either not linked into the                'oracle' executable or it is linked in but does not support                MTS.         Check:  Check the MTS_DISPATCHERS parameter in init<SID>.ora has a                         valid entry.                Check the protocol adapter is installed thus:                        grep -i adapter $ORACLE_HOME/orainst/unix.rgs                If not, then install it.                Check the adapter is linked in to the 'oracle' executable:                        cd $ORACLE_HOME/bin                        adapters oracle                If not, then shutdown all instances running from this                        ORACLE_HOME and:                        cd $ORACLE_HOME/rdbms/lib                        make -f oracle.mk install                If the adapter is installed and you still get this error it                        is most likely that the adapter does NOT support MTS.                         See details above about the parameter 'MTS_DISPATCHERS'                                      2. Error:  Dispatchers start but are not listed by lsnrctl services         Cause:  Dispatchers have not registered with the listener.         Check:  Check the RDBMS alert log ($ORACLE_HOME/rdbms/log/alert_SID.log)                        You should find an error of the form:                       "dispatcher 'D001' encountered error connecting to                                                      listener"                Check your MTS_LISTENER_ADDRESS (init.ora) matches an address                       where the listener is actually listening (defined in                       listener.ora).          3. Error:  Dispatchers do not appear to start         Cause:  Early SQL*Net dispatchers aborted if they could not contact                       the listener.         Check:  See '1' and '2' above.          4. Error:  Connection was made but it is a DEDICATED connection.         Cause:  Various         Check:  First check the alias you connected with                  a. Check which tnsnames.ora file you have used.                     (Remember $HOME/.tnsnames.ora is used if present)                  b. The expanded alias must NOT specify (SERVER=DEDICATED)                  c. Check you have AUTOMATIC_IPC=FALSE set in sqlnet.ora                  d. Make sure there are not multiple definitions of your                     alias.                Now check what is reported by 'lsnrctl services'. Does it                  show DISPATCHERS for the service your alias requested ?                  Are there dispatchers for the PROTOCOL you are using. Eg: Are                  you asking for a service over IPC but there is only a TCP                  dispatcher ?                Double check the output of 'lsnrctl services' to ensure that                  the dispatcher 'ADDRESS=' parameters are valid - notably                  (HOST=0.0.0.0) implies the machine 'hostname' is not set up.                Finally turn on tracing for the client an listener to see                  what is happening.