If we were to log in to the database using a dedicated server, we would see a new process (or a thread on some other operating systems) get created just to service us. For example:
$ sqlplus system/foo@localhost:1521/PDB1
Now using the process status command, let’s view the dedicated server process:
$ ps -ef | grep $ORACLE_SID
Here’s a partial listing of the output showing only the dedicated server process:
oracle 24443 1 0 02:03 ? 00:00:00 oracleCDB (LOCAL=NO)
When we log out, the extra process/thread will go away. Figure 2-6 depicts the dedicated server configuration.
Figure 2-6. Typical dedicated server configuration
As noted, typically Oracle will create a new process for me when I log in. This is commonly referred to as the dedicated server configuration, since a server process will be dedicated to me for the life of my session.
For each session, a new dedicated server will appear in a one-to-one mapping. My client process (whatever program is trying to connect to the database) will be in direct communication with this dedicated server over some networking conduit, such as a TCP/IP socket. It is this server process that will receive my SQL and execute it for me. It will read datafiles if necessary, and it will look in the database’s cache for my data. It will perform my update statements. It will run my PL/SQL code. Its only goal is to respond to the SQL calls I submit to it.
Shared Server
Oracle can also accept connections in a manner called a shared server, in which you wouldn’t see an additional thread created or a new UNIX/Linux process appear for each user connection.
Note In older versions of Oracle, a shared server was known as a multithreaded server or MTS. That legacy name is not in use anymore.
In a shared server, Oracle uses a pool of shared processes for a large community of users. Shared servers are simply a connection pooling mechanism. Instead of having 10,000 dedicated servers (that’s a lot of processes or threads) for 10,000 database sessions, a shared server lets us have a small percentage of these processes or threads, which are (as the name implies) shared by all sessions.
This allows Oracle to connect many more users to the instance than would otherwise be possible. Our machine might crumble under the load of managing 10,000 processes, but managing 100 or 1000 processes is doable. In shared server mode, the shared processes are generally started up with the database and appear in the ps list.
A big difference between shared and dedicated server connections is that the client process connected to the database never talks directly to a shared server, as it would to a dedicated server. It can’t talk to a shared server because that process is, in fact, shared. In order to share these processes, we need another mechanism through which to “talk.” Oracle employs a process (or set of processes) called a dispatcher for this purpose.
The client process will talk to a dispatcher process over the network. The dispatcher process will put the client’s request into the request queue in the SGA (one of the many things the SGA is used for). The first shared server that is not busy will pick up this request and process it (e.g., the request could be UPDATE T SET X = X+5 WHERE Y = 2).
Upon completion of this command, the shared server will place the response in the invoking dispatcher’s response queue. The dispatcher process monitors this queue and, upon seeing a result, will transmit it to the client. Conceptually, the flow of a shared server request looks like Figure 2-7.
Figure 2-7. Steps in a shared server request
As shown in Figure 2-7, the client connection will send a request to the dispatcher. The dispatcher will first place this request onto the request queue in the SGA (1). The first available shared server will dequeue this request (2) and process it. When the shared server completes, the response (return codes, data, and so on) is placed into the response queue (3), subsequently picked up by the dispatcher (4), and transmitted back to the client.
As far as the developer is concerned, there is conceptually no difference between a shared server connection and a dedicated server connection. Architecturally, they are quite different, but that’s not apparent to an application.
Now that you understand what dedicated server and shared server connections are, you may have the following questions:
•\ How do I get connected in the first place?
•\ What would start this dedicated server?
•\ How might I get in touch with a dispatcher?
The answers depend on your specific platform, but the sections that follow outline the process in general terms.
