To understand
Oracle background processes is to understand how Oracle works–offering
opportunity to tune effectively.
With every version comes the potential for additional
background processes when an Oracle instance is started. If memory serves me
right, back in Oracle 7 there were only 6-10 background processes. Taking a
look at a current Oracle 11g instance there are easily 23 background processes
for JUST a typical installation.
Granted this is for a UNIX environment and not Windows where
a simpler math could be employed. So what are background processes anyway?
Simply, what I think a lot of us forget, they are those system processes that
make up an Oracle instance, are configured through various parameters, and
handle the manipulation and presentation of information from our Oracle
database. Please, let’s just remember they are not the database as they are not
physical components like data files.
As noted previously, not all background processes that COULD
run need to be or will be running for your particular instance. For instance,
you may or may not have archiving turned on and thus you may or may not have
the archiver process active on your system. Not all background processes are
mandatory for an instance. Also note, and the reason for an increasing number
of background processes, each background process has its own unique set of
purposes and tasks. These may change from one version to the next, which is the
reason for this paper. I too have grown lazy in knowing what all the processes
are for. As such, I created this article to refresh my memory–eager to learn
what new processes Oracle has conjured up. So please read along, get a feel for
what the process name is, and see if you find any you are unfamiliar with. Also,
note that these processes are those that are typically running after a fresh,
common, and basic installation.
Now some of us might be saying, how do I know what processes
are running? It is very easy; just issue the following `ps` command from the
Unix prompt and you will quickly be presented a simple listing. Since all
Oracle processes start with the ‘ora_’ prefix, issue the following command:
ps -afe | grep ora_
oracle 2565 1 0 12:54 ? 00:00:01 ora_pmon_db11
oracle 2567 1 0 12:54 ? 00:00:00 ora_vktm_db11
oracle 2571 1 0 12:54 ? 00:00:00 ora_diag_db11
oracle 2573 1 0 12:54 ? 00:00:00 ora_dbrm_db11
oracle 2575 1 0 12:54 ? 00:00:00 ora_psp0_db11
oracle 2579 1 0 12:54 ? 00:00:18 ora_dia0_db11
oracle 2581 1 0 12:54 ? 00:00:00 ora_mman_db11
oracle 2583 1 0 12:54 ? 00:00:01 ora_dbw0_db11
oracle 2585 1 0 12:54 ? 00:00:01 ora_lgwr_db11
oracle 2587 1 0 12:54 ? 00:00:05 ora_ckpt_db11
oracle 2589 1 0 12:54 ? 00:00:04 ora_smon_db11
oracle 2591 1 0 12:54 ? 00:00:00 ora_reco_db11
oracle 2593 1 0 12:54 ? 00:00:10 ora_mmon_db11
oracle 2595 1 0 12:54 ? 00:00:02 ora_mmnl_db11
oracle 2597 1 0 12:54 ? 00:00:00 ora_d000_db11
oracle 2599 1 0 12:54 ? 00:00:00 ora_s000_db11
oracle 2611 1 0 12:54 ? 00:00:00 ora_smco_db11
oracle 2613 1 0 12:54 ? 00:00:00 ora_fbda_db11
oracle 2615 1 0 12:54 ? 00:00:00 ora_qmnc_db11
oracle 2619 1 0 12:55 ? 00:00:00 ora_q000_db11
oracle 2621 1 0 12:55 ? 00:00:00 ora_q001_db11
oracle 2806 1 0 12:59 ? 00:00:05 ora_cjq0_db11
oracle 4469 1 0 16:45 ? 00:00:00 ora_w000_db11
To note from this listing is the process ID for the UNIX process
which is the second value in each row.
If you wanted to look at these processes from within the
Oracle database, you need only issue the following SQL command:
SQL> SELECT spid,program,background FROM v$process
SPID PROGRAM B
—— ———————————————— –
PSEUDO
2565 [email protected] (PMON) 1
2567 [email protected] (VKTM) 1
2571 [email protected] (DIAG) 1
2573 [email protected] (DBRM) 1
2575 [email protected] (PSP0) 1
2581 [email protected] (MMAN) 1
2579 [email protected] (DIA0) 1
2583 [email protected] (DBW0) 1
2585 [email protected] (LGWR) 1
2587 [email protected] (CKPT) 1
2589 [email protected] (SMON) 1
2591 [email protected] (RECO) 1
2593 [email protected] (MMON) 1
2595 [email protected] (MMNL) 1
2597 [email protected] (D000)
2599 [email protected] (S000)
2806 [email protected] (CJQ0) 1
4469 [email protected] (W000) 1
4451 [email protected] (TNS V1-V3)
2611 [email protected] (SMCO) 1
2613 [email protected] (FBDA) 1
2615 [email protected] (QMNC) 1
2619 [email protected] (q000) 1
2621 [email protected] (q001) 1
From the above two listings, please note the equality of the UNIX
process ID and the Oracle SPID. Now for a brief description of some of those
more common processes you should see in your listing:
| ora_pmon_<SID> | – | The Process Monitor is responsible for monitoring processes. In this case pmon will perform recovery for user processes that fail, will rollback uncommitted transactions, and clean up the buffer cache and free the resources being consumed. |
|
| ora_vktm_<SID> | – | The Virtual Keeper of Time process is responsible for keeping track of the wall-clock time and used as a reference-time counter. |
|
| ora_diag_<SID> | – | The Diagnosability Process handles hang detection and deadlock resolution. | |
| ora_dbrm_<SID> | – | The Database Resource Manager process takes care of setting up resource manager related tasks and resource plans. |
|
| ora_psp0_<SID> | – | The Process Spawner will spawn Oracle processes as needed. |
|
| ora_mman_<SID> | – | The mman process is used for internal database tasks. | |
| ora_dbw0_<SID> | – | The Database Writer process(s) handle the writing of dirty/modified buffers in the database buffer cache to datafiles. Depending on the activity of the database, there may be multiple database writers to keep up with the changes occurring. |
|
| ora_lgwr_<SID> | – | The Log Writer process is responsible for writing data from the redo log buffers to the redo log files on disk. |
|
| ora_ckpt_<SID> | – | The Checkpoint Process is responsible for signaling the synchronization of all database files with checkpoint information – ensuring data consistency and faster database recovery in case of a crash. |
|
| ora_smon_<SID> | – | The System Monitor process is responsible for instance recovery – cleaning up temporary segments that are not required and coalescing contiguous free extents in dictionary managed tablespaces. |
|
| ora_reco_<SID> | – | The Recoverer process is responsible for recovering all in-doubt transactions in a distributed database setup – connecting to remote databases and resolving pending transactions. |
|
| ora_mmon_<SID> | – | The mmon process will perform manageability-related background tasks such as issuing alerts, taking snapshots, and capturing statistics values for SQL objects. |
|
| ora_mmnl_<SID> | – | The mmnl process will perform other but light-weight manageability-related tasks such as capturing session history and metrics computation. |
|
| ora_d000_<SID> | – | The Dispatcher processes will listen to and receive requests from connected sessions – placing them in the request queue on the next available server for further processing. Dispatcher processes will also pick up outgoing responses from a results queue and transmit those results back to the clients. |
|
| ora_s000_<SID> | – | The Shared Server process will pick up requests from a call request queue, make the calls to the database to resolve the request, and then return the results to a result queue. |
|
| ora_smco_<SID> | – | The Space Management Coordinator process handles the coordination and execution of space management tasks – spawning wnnn processes to carry out the task. |
|
| ora_fbda_<SID> | – | The Flashback Data Archiver process archives historical data for tracked tables into the flashback data archives – storing a pre-image of the rows into the flashback archive and keeping the metadata for those rows. |
|
| ora_cjq0_<SID> | – | The Job Queue process is used for batch processing – running user jobs within a scheduler service. Able to run a large number of concurrent jobs, the coordinator process (cjq0) will spawn job queue slaves (jnnn) to actually run the jobs. |
So, the question might be running through your head as to why we should care
about the processes. Processes are at the very core of an Oracle instance. They
are the link between your user applications and the database. If the system
processes hang or consume large amounts of resources you need to find out why.
The best place to start is to understand what each process does and how it
interacts with the Oracle database. For instance, if lgwr was consuming large
amounts of system resources you might conclude that the configuration you are
using for log maintenance is in need of tuning.
