Re: Question on Dedicated Server, Recovery

From: Yassir Khogaly <yassir_at_khogaly.freeserve.co.uk>
Date: Wed, 25 Nov 1998 11:16:30 -0000
Message-ID: <73gov3$knc$1@newsreader4.core.theplanet.net>

With regards to (Q1) use dedicated server with MTS. Please read attached article.

MTS Architecture

The Oracle Multi-Threaded Server requires SQL*Net V2 and 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.

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'.

    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.

     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.


    h) 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:

Call the listener
The listener tells it to call back on the address where the dispatcher is listening
The client calls the dispatcher and establishes a connection.
The dispatcher now has a CLIENT connection ESTABLISHED and will also continue to listen for any new connections.
The client sends a SQL message to the dispatcher.
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.
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.
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
  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.
   i) 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.
         ii) 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

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= "ipc, 1" <-- Start 1 IPC dispatcher mts_dispatchers= "tcp, 1" <-- 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

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.
Add the MTS configuration required to the init<SID>.ora file.
Start up the database.
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)
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_at_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

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 adaptor 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'
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).
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.
Error: Connection was made but it is a DEDICATED connection. Cause: Various Check: First check the alias you connected with
1. Check which tnsnames.ora file you have used. (Remember $HOME/.tnsnames.ora is used if present)
2. The expanded alias must NOT specify (SERVER=DEDICATED)
3. Check you have AUTOMATIC_IPC=FALSE set in sqlnet.ora
4. 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.

Received on Wed Nov 25 1998 - 05:16:30 CST