Oracle Database Proccesses

Oracle Processes
Oracle server processes running on the operating system perform all the database operations, such as inserting and deleting data. These Oracle processes, together with the memory structures allocated to Oracle by the operating system, form the working Oracle instance. There is a set of mandatory Oracle processes that need to be up and running for the database to function at all. In addition, other processes exist that are necessary only if you are using certain specialized features of the Oracle databases (e.g., replicated databases). This section's focus is on the set of mandatory processes that every Oracle instance uses to perform database activities.
Processes are essentially a connection or thread to the operating system that performs a task or job. The Oracle processes you'll encounter in this section are continuous, in the sense that they come up when the instance starts, and they stay up for the duration of the instance's life. Thus, they act like Oracle's "hooks" into the operating system resources. Note that what I call a process on a UNIX system is analogous to a thread on a Windows system.
Oracle instances need two different types of processes to perform various types of database activities. This distinction is made for efficiency purposes and the need to keep client processes separate from the database server's tasks. The first set of processes is called user processes. These processes are responsible for running the application that connects the user to the database instance. The second and more important set of processes is called the Oracle processes. These processes perform the Oracle server's tasks, and you can divide the Oracle processes into two major categories: the server processes and the background processes. Together, these processes perform all the actual work of the database, from managing connections to writing to the logs and data files to monitoring the user processes.
Interaction Between the User and Oracle Processes
User processes execute program code of application programs and that of Oracle tools such as SQL*Plus. The user processes communicate with the server processes through the user interface. These processes request that the Oracle server processes perform work on their behalf. Oracle responds by using its server processes to service the user processes' requests.
When you connect to an Oracle database, you have to use software such as SQL Net, which is Oracle's proprietary networking tool. Regardless of how you connect and establish a session with the database instance, Oracle has to manage these connections. The Oracle server creates server processes to manage the user connections. It's the job of the server processes to monitor the connection, accept requests for data, and so forth from the database, and hand the results back from the database itself. All selects, for example, involve reading data from the database, and it's the server processes that bring the output of the select statement back to the users.
You'll examine the two types of Oracle processes, the server processes and the background processes, in detail in the following sections.
The Server Process
The server process is the process that services the user process. The server process is responsible for all interaction between the user and the database. When the user submits requests to select data, for example, the server process checks the syntax of the code and executes the SQL code. It will then read the data from the data files into the memory blocks. If another user intends to read the same data, the new user's server process will read it not from disk again, but from Oracle's memory, where it usually remains for a while. Finally, the server process is also responsible for returning the requested data to the user.
The most common configuration for the server process is where you assign each user a dedicated server process. However, Oracle provides for a more sophisticated means of servicing several users through the same server process called the shared server architecture, which enables you to service a large number of users efficiently. A shared server process enables a large number of simultaneous connections using fewer server processes, thereby conserving critical system resources such as memory.
The Background Processes
The background processes are the real workhorses of the Oracle instance. These processes enable large numbers of users to use the information that is stored in the database files. By being continuously hooked into the operating system, these processes relieve Oracle software from having to constantly start numerous, separate processes for each task that needs to be done on the operating system server.
BACKGROUND PROCESS
PROCESS FUNCTION
Database writer
Writes modified data from buffer cache to disk (data files)
Log writer
Writes redo log buffer contents to online redo log files
Checkpoint
Signals database to flush its contents to disk
Process monitor
Cleans up after finished and failed processes
System monitor
Performs crash recovery and coalesces extents
Archiver
Archives filled online redo log files
Recoverer
Used only in distributed databases
Dispatcher
Used only in shared server configurations
Coordination job
Coordinates job queues to expedite job processes queue process
I discuss in detail the main Oracle background processes in the following sections.
The Database Writer
The database writer (DBW) process is responsible for writing data from the memory areas known as database buffers to the actual data files on disk. It is the database writer process's job to monitor the usage of the database buffer cache and help manage it. For example, if the free space in the database buffer area is getting low, the database writer process has to make room there by writing some of the data in the buffers to the disk files. The database writer process uses an algorithm called least recently used (LRU), which basically writes data to the data files on disk based on how long it has been since someone asked for it. If the data has been sitting in the buffers for a very long time, chances are it is "dated" and the database writer process clears that portion of the database buffers by writing the data to disk.

The Process Monitor
The process monitor (PMON) process cleans up after failed user processes and the server processes. Essentially, when processes die, the PMON process ensures that the database frees up the resources that the dead processes were using. For example, when a user process dies while holding certain table locks, the PMON process would release those locks, so other users could use them without any interference from the dead process. In addition, the PMON process restarts failed server processes. The PMON process sleeps most of the time, waking up to see if it is needed. Other processes will also wake up the PMON process if necessary.
In Oracle9i, the PMON process automatically performs dynamic service registration. When you create a new database instance, the PMON process registers the instance information with the listener. (The listener is the entity that manages requests for database connections. This dynamic service registration eliminates the need to register the new service information in the listener.ora file, which is the configuration file for the listener.
The System Monitor
The system monitor (SMON) process, as its name indicates, performs system monitoring tasks for the Oracle instance. The SMON process performs crash recovery upon the restarting of an instance that crashed. The SMON process determines if the database is consistent following a restart after an unexpected shutdown. This process is also responsible for coalescing free extents if you happen to use dictionary managed tablespaces. Coalescing free extents will enable you to assign larger contiguous free areas on disk to your database objects. In addition, the SMON process cleans up unnecessary temporary segments. Like the PMON process, the SMON process sleeps most of the time, waking up to see if it is needed. Other processes will also wake up the SMON process if they detect a need for it.
The Archiver
The archiver (ARCH) process is used when the system is being operated in an archive log mode—that is, the changes logged to the redo log files are being saved and not being overwritten by new changes. The archiver process will archive the redo log files to a specified location, assuming you chose the automatic archiving option in the init.ora file. If a huge number of changes are being made to your database, and consequently your logs are filling up at a very rapid pace, you can use multiple archiver processes up to a maximum of ten. The parameter log_archive_maximum_processes in the initialization file will determine how many archiver processes Oracle will invoke. If the log writer process is writing logs faster than the default single archiver process can archive them, it will be necessary to enable more than one archiver process.
Note that besides the processes discussed here, there are other Oracle background processes that perform specialized tasks that may be running in your system. For example, if you use Oracle Real Application Clusters (ORAC), you'll see a background process called the lock (LCKn) process, which is responsible for performing interinstance locking. If you use the Oracle Advanced Replication Option, you'll notice the background process called recoverer (RECO), which recovers terminated transactions in a distributed database environment.