Oracle background processes

Published 10 Feb 2005 Read time 6 min(s) 43 sec(s) (2931 views). Database

There is no doubt that the Oracle system is huge and composed of a variety of different components. All Oracle databases are run as instances. An Oracle database server can run multiple database instances at a time.

Oracle background processes are visible as separate operating system processes in Unix/Linux. In Windows, these run as separate threads within the same service. Any issues related to background processes should be monitored and analysed from the trace files generated and the alert log.

A background process is defined as any process that is listed in V$PROCESS and has a non-null value in the pname column.

Not all background processes are mandatory for an instance. Some are mandatory and some are optional. Mandatory background processes are DBWn, LGWR, CKPT, SMON, PMON, and RECO. All other processes are optional, will be invoked if that particular feature is activated.

Background processes are started automatically when the instance is started. To find out background processes from database:

select SID,PROGRAM from v$session where TYPE='BACKGROUND';

For example:

SQL> select SID,PROGRAM from v$session where TYPE='BACKGROUND';
PROGRAM
----------------------------------------------------------------
ORACLE.EXE (PMON)
ORACLE.EXE (PSP0)
ORACLE.EXE (VKTM)
ORACLE.EXE (GEN0)

Elapsed: 00:00:00.05

Or using:

select PROGRAM from v$process where BACKGROUND=1;

For example:

SQL> select PROGRAM from v$process where BACKGROUND=1;
PROGRAM
------------------------------------------------
oracle@node1 (PMON)
oracle@node1 (PSP0)
oracle@node1 (VKTM)
oracle@node1 (GEN0)
oracle@node1 (DIAG)
oracle@node1 (DBRM)
oracle@node1 (DIA0)
oracle@node1 (MMAN)
oracle@node1 (DBW0)
oracle@node1 (LGWR)
oracle@node1 (CKPT)

PROGRAM
------------------------------------------------
oracle@node1 (SMON)
oracle@node1 (RECO)
oracle@node1 (MMON)
oracle@node1 (MMNL)
oracle@node1 (W000)
oracle@node1 (QMNC)
oracle@node1 (Q000)
oracle@node1 (SMCO)
oracle@node1 (CJQ0)
oracle@node1 (Q001)

21 rows selected.

To find out background processes from within UNIX/Linux:

ps -ef | grep ora_| grep SID

Replacing SID with your actual ORACLE_SID; For example to find the process for ORACLE_SID ORATST1:

$ ps -ef | grep ora_ | grep -i oratst1
  oracle   542     1  0 15:15:59 ?        0:00 ora_pmon_ORATST1
  oracle   544     1  0 15:15:59 ?        0:00 ora_mman_ORATST1
  oracle   546     1  0 15:15:59 ?        0:01 ora_dbw0_ORATST1
  oracle   548     1  0 15:16:00 ?        0:01 ora_lgwr_ORATST1
  oracle   550     1  0 15:16:00 ?        0:00 ora_ckpt_ORATST1
  oracle   552     1  0 15:16:00 ?        0:04 ora_smon_ORATST1
  oracle   554     1  0 15:16:00 ?        0:00 ora_reco_ORATST1
  oracle   556     1  0 15:16:00 ?        0:02 ora_cjq0_ORATST1
  oracle   558     1  0 15:16:00 ?        0:00 ora_d000_ORATST1
  oracle   560     1  0 15:16:01 ?        0:00 ora_s000_ORATST1
  oracle   714  1293  0 17:22:24 pts/2    0:00 grep -i oratst1
  oracle   566     1  0 15:16:22 ?        0:00 ora_qmnc_ORATST1
  oracle   568     1  0 15:16:28 ?        0:04 ora_mmon_ORATST1
  oracle   570     1  0 15:16:28 ?        0:01 ora_mmnl_ORATST1
  oracle   572     1  1 15:16:31 ?        0:15 ora_j000_ORATST1
  oracle   712     1  0 17:19:33 ?        0:00 ora_q000_ORATST1

The output above lists all the processes of an Oracle 10.2.0.4 database server making up the instance of the database ORATST1. The following table provides a brief description of each process.

Process	Description
acr0	Archiver (maximum 10) ARC0-ARC9 The ARCn process is responsible for writing the online redolog files to the mentioned archive log destination after a log switch has occurred. ARCn is present only if the database is running in archivelog mode and automatic archiving is enabled. The log writer process is responsible for starting multiple ARCn processes when the workload increases. Unless ARCn completes the copying of a redolog file, it is not released to log writer for overwriting.
bsp0	Block Server Process (max 10) BSP0-BSP9 Block server Processes have to do with providing a consistent read image of a buffer that is requested by a process of another instance, in certain circumstances.
cjq0	Coordinated Job Queue Processes (max 1000) CJQ0/J#### Job queue processes are used for batch processing. The CJQ0 process dynamically spawns job queue slave processes (J000...J999) to run the jobs.
ckpt	Checkpoint (max 1) At specific times, all modified database buffers in the system global area are written to the datafiles by DBWn. This event is called a checkpoint. The checkpoint process is responsible for signalling DBWn at checkpoints and updating all the datafiles and control files of the database to indicate the most recent checkpoint.
d000	Dispatcher (max 1000) D### Intended for multi threaded server (MTS) setups. Dispatcher processes listen to and receive requests from connected sessions and places them in the request queue for further processing. Dispatcher processes also pickup outgoing responses from the result queue and transmit them back to the clients. Dnnn are mediators between the client processes and the shared server processes. The maximum number of dispatcher process can be specified using the initialization parameter MAX_DISPATCHERS.
dbw0	Database Writer The database writer writes modified blocks from the database buffer cache to the datafiles. Oracle Database allows a maximum of 20 database writer processes (DBW0-DBW9 and DBWa-DBWj). The initialization parameter DB_WRITER_PROCESSES specifies the number of DBWn processes. The database selects an appropriate default setting for this initialization parameter (or might adjust a user specified setting) based upon the number of CPUs and the number of processor groups.
emn0	Event Monitor (max 1) EMN0/EMON This process is also related to advanced queuing, and is meant for allowing a publish/subscribe style of messaging between applications.
j000	A job queue slave. (See cjq0)
lmon	Lock Manager Lock monitor manages global locks and resources. It handles the redistribution of instance locks whenever instances are started or shutdown. Lock monitor also recovers instance lock information prior to the instance recovery process. Lock monitor co-ordinates with the Process Monitor (PMON) to recover dead processes that hold instance locks.
lmd0	Lock Manager Daemon (max 10) LMD0-LMD9 LMDn processes manage instance locks that are used to share resources between instances. LMDn processes also handle deadlock detection and remote lock requests.
lgwr	Log Writer The log writer process writes redo log entries to disk. Redo log entries are generated in the redo log buffer of the system global area (SGA), and LGWR writes the redo log entries sequentially into a redo log file. If the database has a multiplexed redo log, LGWR writes the redo log entries to a group of redo log files.
mman	Used for internal database tasks.
mmnl	Performs frequent and light-weight manageability-related tasks, such as session history capture and metrics computation.
mmon	Performs various manageability-related background tasks.
pmon	Process Monitor The process monitor performs process recovery when a user process fails. PMON is responsible for cleaning up the cache and freeing resources that the process was using. PMON also checks on the dispatcher processes (described later in this table) and server processes and restarts them if they have failed.
p000	Parallel Execution/Query Slaves (max 1000) P### These processes are used for parallel processing. It can be used for parallel execution of SQL statements or recovery. The Maximum number of parallel processes that can be invoked is specified by the initialization parameter PARALLEL_MAX_SERVERS.
q000	AQ (advanced queueing) process. If you are not using AQ directly, Oracle internally uses t for dbms_schedule, data pump, workflow, advanced streams, rule manager and probably a few other areas.
qmnc	Queue Monitor (max 10) QMN0-QMN9 This is the advanced queuing time manager process. QMNn monitors the message queues. QMN used to manage Oracle Streams Advanced Queuing.
reco	Recoverer The recoverer process is used to resolve distributed transactions that are pending due to a network or system failure in a distributed database. At timed intervals, the local RECO attempts to connect to remote databases and automatically complete the commit or rollback of the local portion of any pending distributed transactions.
s000	Shared Server Processes (max 1000) S### Intended for multi threaded server (MTS) setups. These processes pickup requests from the call request queue, process them and then return the results to a result queue. These user processes also handle disk reads from database datafiles into the database block buffers. The number of shared server processes to be created at instance startup can be specified using the initialization parameter SHARED_SERVERS. Maximum shared server processes can be specified by MAX_SHARED_SERVERS.
smon	System Monitor The system monitor performs recovery when a failed instance starts up again. In a Real Application Clusters database, the SMON process of one instance can perform instance recovery for other instances that have failed. SMON also cleans up temporary segments that are no longer in use and recovers dead transactions skipped during system failure and instance recovery because of file-read or offline errors. These transactions are eventually recovered by SMON when the tablespace or file is brought back online.