Subject:  TECH: Known Problems with the Multi Threaded Server (MTS) 
Type:  REFERENCE 
Creation Date:  11-SEP-1994 
 
Introduction	
~~~~~~~~~~~~
        This short article outlines some of the limitations and known problems 
        when using Oracle Multi Threaded Server architecture (MTS). It gives 
        summary information on common problem areas only. The content is biased 
        towards Oracle on Unix but the main points apply across most platforms.

 
Where benefits may be seen:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
	Unix systems traditionally start to have problems when there are
	too many distinct processes waiting to run in that they start to
	spend more time choosing what to run next than actually running 
	anything useful. The chance of this increases as the number of 
	processes increases. MTS reduces the number of processes.
	There are no hard rules in this area as Unix scheduling algorithms
	are now much better. You need to monitor the run queue at different
	process loadings.

	Potential small memory saving.


Potential Problems with MTS:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	- It is nearly always slower than dedicated connections.
	  (obviously this depends a lot on the application but each
	   call the the server has to:
		be picked up by the dispatcher 
		placed on a queue in the SGA
		pulled of the queue by a shared server
		set context for that session
		executed
		put results into queue in SGA
		dispatcher read queue
		send result to client
	  )
	  The architecture is documented and shows a longer round trip per
	  call compared to dedicated connections.
	
	- Increased fragmentation of the shared pool 
	  This is not really documented as it is an observed problem.
	  Shared pool fragmentation has been an issue for a while and
	  Oracle are improving the server to cope with this. MTS makes
	  matters worse as there is much heavier allocation and freeing
	  of space for user context information.

	- Potential for 'false' deadlocks.
	  This is fully documented.

	- Bad session management for dead client sessions.
          This is not really documented. If a client session dies then the only 
          way to clear the session is to use an ALTER SESSION KILL command. 
          This leaves an entry in V$SESSION as KILL is intended to mark a 
          session as KILLED and inform the user with an error when they next 
          issue a call to the server. For 'dead' client sessions no call is 
          received so the entry stays in V$SESSION until the database is 
          bounced. If you limit connections per userid this can actually stop a 
          user from ever reconnecting. 

	  On dedicated connections you can use an operating system kill
	  on the server process.

	- Dead connection detection problems
	  This is related to bad session management and should now be fixed.
	  (7.2). Dead connection detection and MTS has had problems preventing
	  its use on earlier releases.

	- Memory saving not as great as expected.
	  In dedicated or MTS the user session requires a UGA (User
	  Global Area) - this is where most session memory is allocated. 
	  In dedicated connections this memory is in the dedicated server
	  process data space. In MTS the SAME SPACE is placed in the SGA.
	  This is NOT a saving but a moving of information. This is usually
	  the largest piece of private information.
	  What you do save is process stack space but this is typically
	  only a small percentage of the session memory.

	- Less proven code paths 
	  In any code there are well used code paths and lesser used code
	  paths. The risk of hitting a problem increases when using
	  lesser used code paths. MTS is much less widely used than the
	  dedicated code path. This is bourne of the reality that no
	  software product is 'bug free'.
	   
	- Database link issues
	  Unless DB links are very carefully defined then in an MTS
	  environment use of a DB link can tie a shared server process
	  permanently to a user session.
	  To avoid this you have to use SQL*Net V2 DB links and a very 
	  specific syntax for DB link connect strings.

	- Batch Jobs
	  This is more configuration than a problem but you should 
	  separate batch jobs to use dedicated connections if using
	  MTS. Without this the batch job can take out a shared server
	  slowing everyone else down.