Oracle Processes

The second component of an Oracle instance is the Oracle process. There are two main types of process: user processes and Oracle processes.

User processes are on the client side and are requesting data from the server. Oracle
processes are those that run on the database server.

These fall into two categories: server processes and background processes.

Background Processes

Background processes perform much of the legwork between the memory structures and disks. Anytime data is written from memory to disk, it is done by a background process. The DBA needs to know what each process does and how to configure it. This is critical to
understanding how Oracle actually functions.

Like memory structures, background structures exist only when the database instance is running. To see the background processes for a particular database instance, enter the following Unix command: ps -ef | grep -i database_sid

Specifically, PMON, SMON, LGWR, DBWR, and CKPT (starting in Oracle 8) are required. If any of these processes die or are accidentally killed, the database will crash. The database instance cannot survive without all of these processes. Other processes, such as QMNn or ARCH, are required to provide additional database functionality.

System Monitor Process (SMON)

If an Oracle Instance fails, all information in memory not written to disk is lost. SMON is responsible for recovering the instance when the database is started up again. It does the following:

• Rolls forward to recover data that was recorded in a Redo Log File, but that had not yet been recorded to a datafile by DBWn. SMON reads the Redo Log Files and applies the changes to the data blocks. This recovers all transactions that were committed because these were written to the Redo Log Files prior to system failure.

• Opens the database to allow system users to logon.

• Rolls back uncommitted transactions.

• Coalesces free space

Coalesces (merges) free space on disk within dictionary managed tablespaces if the PCTFREE parameter is greater than 0. This applies to tables and indexes.

SMON also does limited space management.  It combines (coalesces) adjacent areas of free space in the database's datafiles for tablespaces that are dictionary managed.

• Deallocates temporary segments

It also deallocates temporary segments to create free space in the datafiles (Reclaim space used by temporary segments)

Process Monitor Process (PMON)

Rolling back transaction and releasing locks which are held during instance recovery

PMON cleans up abnormally terminated user process i.e it perform process recovery when server process terminate abnormally.

PMON can take a while to wake-up because killed user processes can exist for quite some time. I have seen user logins that have been killed at the Oracle level survive on the database for several days.

Although there are five required Oracle background processes for a running database instance (SMON, PMON, DBWR, LGWR, and CKPT), most DBAs verify if a database is up or down by checking for PMON. It is common to use the Unix command string ps -ef | grep -i pmon to verify if a database is running. This method is often used in Unix shell scripts to check if the database is up before attempting to access a database

It cleans up the database buffer cache and releases resources that were used by a failed user process.

Server Processes

A server process acts as a go-between for the user process and the Oracle memory structures. When a user process has a request for work, that work is done by a server process. Reading data from disk and placing it in memory also is done by the server process. For example, when a user process requests data, it is the server process that scans the database buffer cache to find it and, if the data is not in the cache, the server process reads the data block from memory into the buffer cache.

The method by which server processes support user processes depends on the database’s configuration:

Dedicated Server

MTS Server