1. The server process

The server process is the process that executes the client session instructions.
The server process is responsible for receiving the SQL statement sent to the database by the application and executing it in the database.

2. Oracle connection method

Dedicated server connection:

With a dedicated server connection, you get a dedicated process on the server for that connection.
At this time, there is a one-to-one correspondence between the database connection and the server process (or thread).

Shared server connection:

When using a shared server connection, multiple sessions can share a server process pool in which the processes are generated and managed by the Oracle instance.
What is being connected is a database scheduler, not a dedicated server process created specifically for the connection.

The tasks of a dedicated server process and a shared server process are the same:

When you submit a SELECT * FROM EMP query to the database, there will be an Oracle dedicated/shared server process to resolve the query and put it in the shared pool.
This process has to formulate a query plan by itself, then execute it, and try to find the necessary data in the buffer cache, or read data from disk into the buffer cache.

In dedicated server mode, there is a one-to-one mapping between client connections and server processes. If there are 100 dedicated server connections on a UNIX/Linux host, there will be corresponding 100 processes executing.
Your client application is linked against the Oracle libraries that provide the APIs needed to communicate with the database. These APIs know how to submit queries to the database and handle the returned cursors. They know how to package requests into network calls, and dedicated servers know how to unpack them. This part of the software is called Oracle Net.
Oracle uses this software to support client/server processing, even in an n-tier architecture where there are also client/server programs lurking. That is, this dual-process architecture is used even if the client and server are on the same machine.

This architecture has two benefits:

Remote Execution: Client application and database can run on different machines.
Address space isolation: The server process can read and write to the SGA. If the client process and the server process are physically linked together, a wrong pointer in the client process can easily corrupt the data structures in the SGA.

Shared server connections require the use of Oracle Net, even if the client and server are on the same machine. You cannot use a shared server without using the Oracle TNS listener.
Client applications connect to the Oracle TNS listener and redirect or hand off to a dispatcher program.
Client applications are physically connected to a scheduler program. For an instance, multiple schedulers can be configured.
And one scheduler corresponds to hundreds of users.
The scheduler program is only responsible for receiving inbound requests from client applications and putting them into a request queue in the SGA.
The first available process in the shared server process pool (including some pre-created shared server processes) will sequentially obtain requests from the queue and attach the UGA of the relevant session.
The shared server process will process the request and put the resulting output in the response queue.
The scheduler program continuously monitors the response queue for results and passes the results back to the client application.
For the client, after connecting to the database, it is not clear whether it is a dedicated server connection or a shared server connection. They all look the same, and there is a significant difference between the two only at the database level.