Background Processes

When the instance starts, Oracle creates a set of background processes that consolidate through functions what would otherwise have to be handled by multiple Oracle programs, each running for each user process called. These processes perform I/O and monitor the other Oracle processes. The background processes created include Database Writer (DBWn), Log Writer (LGWR), Checkpoint (CKPT), System Monitor (SMON), Process Monitor (PMON), Archiver (ARCn), Recoverer (RECO), Job Queue processes (Jnnn), Dispatcher (Dnnn), Lock Manager Server (LMS), and Queue Monitor (QMNn).

Database Writer (DBWn)

Database Writer (a mandatory background process) writes all modified blocks from the database buffer cache out to the proper datafiles. The write occurs at the following conditions:

• Checkpoint, normal or incremental

• Dirty buffers threshold reached

• No free buffers available for a process

• Timeout occurs

• RAC ping request

• Tablespace (either normal or temporary) offline

• Tablespace set to read-only

• DROP TABLE command

• truncate Table command

• BEGIN BACKUP TABLESPACE command

Typically, one Database Writer process (DBW0) is sufficient to handle the demands of most systems; you can, however, configure additional Database Writer processes (DBW1 through DBW9 and DBWa through DBWj) to improve the write performance of a system that modifies data heavily. The initialization parameter (more on the initialization files and their parameters in Chapter 4, "Managing an Instance") that handles the allocation of the extra processes is DB_WRITER_PROCESSES, and the parameter entry that would set the number of Database Writer processes to 6, for example, follows:

 DB_WRITER_PROCESSES=6 

Oracle uses write-ahead logging, which means that database writer does not need to write out the data blocks as soon as a transaction commits. Database writer, instead, is designed to perform its batched writes, making the writing of changed data blocks highly efficient. Ordinarily, it writes out these changes only when there is more data to be read into the SGA and too few database buffers to hold it. The least recently used data is written out to the datafiles first.

Log Writer (LGWR)

The Log Writer process (a mandatory background process) writes redo log entries from the redo log buffer out to the online redo logs on disk. If your database has multiplexed redo logs, log writer writes the redo log entries to the entire group of online redo log files and commits only when all the redo has been written to disk. Log writer performs sequential writes to the redo log files under the following conditions:

• Transaction commit

• More than 1MB of changed records in the redo log buffer cache

• Redo log buffer cache one-third full

• Before database writer writes modified blocks out of the buffer cache

• Every 3 seconds

Checkpoint (CKPT)

An event, a checkpoint, occurs when the Oracle background process DBWn is triggered by the CKPT process to write all the modified database buffers from the SGA out to the datafiles, including any committed or noncommitted data. This ensures that the data blocks in memory that change frequently are written out to files regularly. Because of the LRU algorithm of DBWn, a data block updated frequently may never age out because it never qualifies as a least recently used block. A checkpoint makes sure that this data gets written out. Because all the database changes up to the checkpoint have been recorded in datafiles, the redo log entries from before the checkpoint are no longer needed to be applied to the datafiles if an instance recovery is needed; therefore, checkpoints can expedite a media recovery situation. The checkpoint (a mandatory background process) ensures that the checkpoint number is written into the datafile headers andalong with the log sequence number, archive log names (if the database is in archive log mode), and the system change numbersis written into the control file.

CKPT does not write blocks to disk; DBWn always performs this task. CKPT triggers DBWR to write the blocks out to their respective files.

A checkpoint occurs whenever there is a log switch in the online redo log files or whenever either of the following two parameters' settings is met:

• LOG_CHECKPOINT_INTERVAL Sets the checkpoint intervals to occur whenever a particular volume of data has been changed

• LOG_CHECKPOINT_TIMEOUT Sets the checkpoint intervals to occur whenever a given period of time has elapsed

System Monitor (SMON)

The System Monitor process (a mandatory background process) performs instance recovery when a failed instance starts up again. In a Real Application Clusters environment, the SMON process of one of the instances can perform instance recovery for one or more other instances that may have failed. SMON recovers any terminated transactions that might have been skipped during recovery because of file-read errors or offline errors. These failed transactions are eventually recovered by SMON whenever the tablespace or file is brought back online. SMON is also responsible for coalescing free extents in any dictionary managed tablespaces so that the free space is contiguous and easier for Oracle to allocate if pctfree is set to a number greater than 0.

Process Monitor (PMON)

The Process Monitor (a mandatory background process) process performs process recovery when a user process fails (how's that for a bunch of processes!). PMON is responsible for cleaning up the cache and freeing resources that the failed process was using and for checking on the dispatcher and server processes and restarting them if they have failed. It cleans up after failed processes by doing the following:

• Rolling back the user's current transaction

• Releasing all currently held table or row level locks

• Freeing any resources currently reserved by the user

• Restarting dead dispatches

Archiver (ARCn)

Archiver (an optional process) copies the online redo log files to archival storage after a log switch has occurred for databases running in archive log mode. Although a single archiver process (ARC0) is usually sufficient for most systems, you can specify up to 10 ARCn processes by using the dynamic initialization parameter LOG_ARCHIVE_MAX_PROCESSES. If the archiving workload gets to be too much for the current number of archiver processes, log writer automatically starts another archiver process up to the maximum of 10 processes. ARCn is active only when a database is in ARCHIVELOG mode and automatic archiving is enabled.

Recoverer (RECO)

The Recoverer (an optional process) is used to resolve any distributed transactions left pending due to a network or system failure in a distributed database. At timed intervals, the local RECO attempts to connect to the associated remote databases and, if it is successful, automatically complete the commit or rollback of the local portions of any pending distributed transactions.

Job Queue Processes (Jnnn)

Job Queue processes (an optional process) are used for automating batch processing and are managed dynamically. This enables job queue clients to use more or fewer job queue processes when required. The resources used by any new processes spawned are released when they are idle. It is important to note, however, that you need to be using the DBMS_JOB functionalities for the Job Queue processes to accomplish anything, regardless of to what the initialization parameters are set.

The initialization parameter relevant to the Job Queue processes is the JOB_QUEUE_PROCESSES parameter. This parameter allows you to set, as a numeric, the number of Job Queue processes that you want to have available to run on your instance. The default value is 0.

To get information on the Job Queue processes in the database, you would query the Data Dictionary views listed in Table 1.2. Table 1.2 provides information on the relevant view and the information you can find there.

Table 1.2. Job Queue Process Data Dictionary Views

Data Dictionary View	Description of Information Available
DBA_JOBS	This view lists all the jobs in the database.
USER_JOBS	This view lists all the jobs owned by the user who is logged in.
DBA_JOBS_RUNNING	Lists all jobs in the database that are currently running. This view can be joined with V$LOCK to identify jobs that have locks.

Dispatcher (Dnnn)

Dispatcher is an optional background process present only when a shared server configuration is used. At least one Dispatcher process is created for every communication protocol in use. Each dispatcher process is responsible for routing requests from a connected user process to an available shared server process and returning the responses back to the appropriate user process.

Lock Manager Server (LMS)

The Lock Manager Server process (an optional process) is used for inter-instance locking in Real Application Clusters.

Queue Monitor (QMNn)

Queue Monitor processes are also optional background processes responsible for monitoring the message queues for Oracle Advanced Queuing. You can configure up to 10 queue monitor processes.

Now that you have some idea about what constitutes the instance and the database, lets look at connecting to the instance.