In dedicated server mode, there will be a one-to-one mapping between a client connection and a server process (or thread, as the case may be). If you have 100 dedicated server connections on a UNIX/Linux machine, there will be 100 processes executing on their behalf. Graphically, it looks as shown in Figure 5-1.

Figure 5-1. Typical dedicated server connection
Your client application will have Oracle libraries linked into it. These libraries provide the APIs you need in order to talk to the database. These APIs know how to submit a query to the database and process the cursor that is returned.
They know how to bundle your requests into network calls that the dedicated server will know how to unbundle. This piece of software is called Oracle Net, although in prior releases you might have known it as SQL*Net.
This is the networking software/protocol that Oracle employs to allow for client/server processing (even in an n-tier architecture, there is a client/server program lurking). Oracle employs this same architecture even if Oracle Net is not technically involved in the picture.
That is, even when the client and server are on the same machine, this two-process (also known as two-task) architecture is still employed. This architecture provides two benefits:
•\ Remote execution: It is very natural for the client application to be executing on a machine other than the database itself.
•\ Address space isolation: The server process has read-write access to the SGA. An errant pointer in a client process could easily corrupt data structures in the SGA if the client process and server process were physically linked together.
In Chapter 2, we saw how these dedicated servers are spawned or created by the Oracle listener process. I won’t cover that process again; rather, we’ll quickly look at what happens when the listener isn’t involved.
The mechanism is much the same as it was with the listener, but instead of the listener creating the dedicated server via a fork()/exec() in UNIX/Linux or an interprocess communication (IPC) call in Windows, the client process itself creates it.
Note There are many variants of the fork() and exec() calls, such as vfork() and execve(). The call used by Oracle may vary by operating system and implementation, but the net effect is the same. fork() creates a new process that is a clone of the parent process; on UNIX/Linux, this is the only way to create a new process. exec() loads a new program image over the existing program image in memory, thus starting a new program. So, SQL*Plus can fork (copy itself) and then exec the Oracle binary, the dedicated server, overlaying the copy of itself with this new program.
We can see this parent/child process creation clearly on UNIX/Linux when we run the client and server on the same machine, connecting to the root container as SYS:
$ sqlplus / as sysdba
SQL> select a.spid dedicated_server, b.process clientpid from v$process a, v$session bwhere a.addr = b.paddr and b.sid = sys_context(‘userenv’,’sid’);
Here, I used a query to discover the process ID (PID) associated with my dedicated server (the SPID from V$PROCESS is the operating system PID of the process that was being used during the execution of that query). The output of /bin/ps –fp includes the parent process ID (PPID) and shows the dedicated server process, 12380, is the child of my SQL*Plus process: process ID 12379.