Process Architecture

All connected Oracle users must run two modules of code to access an Oracle database instance.

- Application or Oracle tool: A database user runs a database application (such as a precompiler program) or an Oracle tool (such as SQL*Plus), which issues SQL statements to an Oracle database.

- Oracle database server code: Each user has some Oracle database code executing on his or her behalf, which interprets and processes the application's SQL statements.

Types of Processes

The processes in an Oracle system can be categorized into two major groups:

- User processes run the application or Oracle tool code.

- Oracle processes run the Oracle database server code. They include server processes and background processes.

Overview of User Processes

When a user runs an application program (such as a Pro*C program) or an Oracle tool (such as Enterprise Manager or SQL*Plus), Oracle creates a user process to run the user's application.

Overview of Oracle Processes (server processes and background processes)

Server Processes

Oracle creates server processes to handle the requests of user processes connected to the instance. In some situations when the application and Oracle operate on the same computer, it is possible to combine the user process and corresponding server process into a single process to reduce system overhead. However, when the application and Oracle operate on different computers, a user process always communicates with Oracle through a separate server process.

Background Processes

To maximize performance and accommodate many users, a multiprocess Oracle system uses some additional Oracle processes called background processes.

An Oracle instance can have many background processes; not all are always presetn. There are numerous background processes. See the V$BGPROCESS view for more information on the background processes. The background processes in an Oracle instance can include the following: Database Write Process (DBWn); Log Writer Process (LGWR); Checkpoint Process (CKPT); System Monitor Process (SMON); Process Monitor Process (PMON); Recoverer Process (RECO); Job Queue Processes; Archiver Processes (ARCn); Queue Monitor Processes (QMNn); Other Background Processes

On many operating systems, background processes are created automatically when an instance is started.

Database Writer Process (DBWn)

The database writer process (DBWn) writes the contents of buffers to datafiles. The DBWn Processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk.

When a buffer in the database buffer cache is modified, it is marked dirty.

The DBWn process writes dirty buffers to disk under the following conditions:

- When a server process cannot find a clean reusable buffer after scanning a threshold number of buffers, it signals DBWn to write. DBWn writes dirty buffers to disk asynchronously while performing other processing.

- DBWn periodically writes buffers to advance the checkpoint, which is the position in the redo thread (log) from which instance recovery begins. This log position is determined by the  oldest dirty buffer in the buffer cache.

Log Writer Process (LGWR)

The log writer process (LGWR) is responsible for redo log buffer management-writing the redo log buffer to a redo log file on disk. LGWR writes all redo entries that have been copied into the buffer since the las time it wrote.

The redo log buffer is a circular buffer. When LGWR writes redo entries from the redo log buffer to a redo log file, server processes can then copy new entries over the dentries in the redo log buffer that have been written to disk. LGWR normally writes fast enough to ensure that space is always available in the buffer for new entries, even when access to the redo log is heavy.

LGWR writes on contiguous portion of the buffer to disk. LGWR writes:

- A commit record when a user process commits a transaction

- Redo log buffers ( Every three seconds; When the redo log buffer is one-third full; When a DBWn process writes modified buffers to disk, if necessary

When a user issues a COMMIT statement, LGWR puts a commit record in the redo log buffer and writes it to disk immediately, along with the transaction's redo entries. The corresponding changes to data blocks are deferred until it is more efficient to write them. This is called a fast commit mechanism.

When a user commits a transaction, the transaction is assigned a system change number (SCN), which Oracle records along with the transaction's redo entries in the redo log. SCNs are recorded in the redo log so that recovery operations can be synchronized in Real Application Clusters and distributed databases.

Checkpoint Process (CKPT)

When a checkpoint occurs, Oracle must update the headers of all datafiles to record the details of the checkpoint. This is done by the CKPT process. The CKPT process does not write blocks to disk; DBWn always performs that work.

System Monitor Process (SMON)

The system monitor process (SMON) performs recovery, if necessary, at instance startup. SMON is also responsible for cleaning up temporary segments that are no longer in use and for coalescing contiguous free extents within dictionary managed tablespaces. If any terminated transactions were skipped during instance recovery because of file-read or offline errors, SMON recovers them when the tablespace of file is brought back online. SMON checks regularly to see whether it is needed. Other processes can call SMON if they detect a need for it.

Process Monitor Process (PMON)

The prcess monitor (PMON) performs process recovery when a user process fails. PMON is responsible for cleaning up the database buffer cache and freeing resources that the user process was using.

Archiver Processes (ARCn)

The archiver process (ARCn) copies redo log files to a designeated storage device after a log switch has occurred. ARCn processes are present only when the database is in ARCHIVELOG mode, and automatic archiving is enabled.

An Oracle instance can have up to 10 ARCn processes (ARC0 to ARC9). The LGWR process starts a new ARCn process whenever the current number of ARCn processes is insufficient to handle the workload. The alert log keeps a record of when LGWR starts a new ARCn process.