As seen in the previous sections in this book, each Oracle instance has a large chunk of memory called the SGA that it uses, for example, to do the following:
•\ Maintain many internal data structures that all processes need access to.
•\ Cache data from disk; buffer redo data before writing it to disk.
•\ Hold parsed SQL plans.
•\ And so on.
Oracle has a set of processes that are “attached” to this SGA, and the mechanism by which they attach differs by operating system. In a UNIX/Linux environment, the processes will physically attach to a large shared memory segment, a chunk of memory allocated in the OS that may be accessed by many processes concurrently (generally using shmget() and shmat()).
Under Windows, these processes simply use the C call, malloc(), to allocate the memory, since they are really threads in one big process and hence share the same virtual memory space.
Oracle also has a set of files that the database processes or threads read and write (and Oracle processes are the only ones allowed to read or write these files). In a single- tenant architecture, these files hold all of our table data, indexes, temporary space, redo logs, PL/SQL code, and so on. In a multitenant architecture, the container database will hold all of the Oracle-related metadata, data, and code; our application data will be separately contained in a pluggable database.
If you were to start up Oracle on a UNIX/Linux–based system and execute a ps command, you’d see that many physical processes are running, with various names.
For example, if you wanted to view the system monitor process, you would execute the following:
$ ps -ef | grep smon
oracle 19362 1 0 00:29 ? 00:00:00 ora_smon_CDB
I cover these processes in Chapter 5, so just be aware for now that they are commonly referred to as the Oracle background processes. They are persistent processes that make up the instance, and you’ll see them from the time you start the instance until you shut it down.
It is interesting to note that these are processes, not individual programs. There is only one Oracle binary executable on UNIX/Linux; it has many “personalities,” depending on what it was told to do when it starts up.
The same binary executable that was run to start the smon was also used to start the checkpoint background process. There is only one binary executable program, named simply oracle. It is just executed many times with different names.
Connecting toOracle
In this section, we’ll take a look at the mechanics behind the two most common ways to have requests serviced by an Oracle server: dedicated server and shared server connections. We’ll see what happens on the client and the server in order to establish connections, so we can log in and actually do work in the database.
Lastly, we’ll take a brief look at how to establish TCP/IP connections; TCP/IP is the primary networking protocol used to connect over the network to Oracle. And we’ll look at how the listener process on our server, which is responsible for establishing the physical connection to the server, works differently in the cases of dedicated and shared server connections.
