Oracle Server Architecture (Connections)

When an instance starts, the network listener process opens and establishes a communication pathway through which users connect to Oracle. Then each dispatcher process gives the listener process an address at which the dispatcher listens for connection requests. When a remote connection is detected the listener:

1. Examines the request
2. Determines whether the user process can use a shared server process
3. If so, the listener returns the address of the dispatcher process that has the lightest load
4. The user process connects to the dispatcher directly

In legacy versions of Oracle, prior to Oracle 9i, some user processes (such as those that connected using SQL*Net version 1) could not communicate with the dispatcher. For SQL*Net version 1, requests that use the TWO_TASK connect string (e.g., t:host:sid), the listener spawned a dedicated process.

Dispatchers manage multiple requests with the request queue and the response queue. When a user makes a remote request, the dispatcher places the request on the request queue, where it is picked up by the next available shared server process. The request queue is in the SGA and is common to all dispatcher processes of an instance. The dispatcher processes check the common request queue for new requests, picking them up on a first-in-first-out basis. One shared server process picks up one request in the queue and makes all necessary calls to the database to complete that request. When the server completes the request, it places the response on the calling dispatcher's response queue. Each dispatcher has its own response queue in the SGA. The dispatcher then returns the completed request to the appropriate user process.

For example, suppose a customer-entry clerk connects to a dispatcher. Each request made by the clerk is sent to that dispatcher, which places the request in the request queue. The next available shared server process picks up the request, services it, and puts the response in the response queue. When the clerk's request is completed, the clerk remains connected to the dispatcher, but the shared server process that processed the request is released and is now available for other requests. While one clerk is talking to a customer, another clerk can use the same shared server process.
The diagram below illustrates how user processes communicate with the dispatcher across the program interface and how the dispatcher communicates users' requests to shared server processes.

The code below shows shared server processes in UNIX with the ps command.

dilbert> ps -ef|grep s0
  oracle 23970 38450   0 14:12:00  pts/0  0:00 grep s0 
  oracle 33156     1   0 14:10:54      -  0:00 ora_s001_fred 
  oracle 33644     1   0 14:10:54      -  0:00 ora_s000_fred

The next lesson concludes this module.