Oracle background processes
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';
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
select PROGRAM from v$process where BACKGROUND=1;
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.
|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.|