Basics of the Oracle 12c Background Process
In Oracle 12c, you can have over 200 background processes. It says “over 200” because it varies by operating system. If this sounds like a lot, don’t be scared. Many are multiples of the same process (for parallelism and taking advantage of systems with multiple CPUs). Here are the most common background processes.
By default, no processes have more than one instance of their type started. More advanced tuning features involve parallelism. To see a complete list of all the background processes on your OS, query V$BGPROCESS.
|Background Process Name||Description|
|PMON||The process monitor manages the system’s server
processes. It cleans up failed processes by releasing resources and
rolling back uncommitted data.
|SMON||The system monitor is primarily responsible for instance
recovery. If the database crashes and redo information must be read
and applied, the SMON takes care of it. It also cleans and releases
|DBWn||The database writer’s sole job is taking dirty
blocks from the dirty list and writing them to disk. There can be
up to 20 of them, hence the n. It starts as DBW0 and
continues with DBW1, DBW2, and so on. After DBW9, it continues with
DBWa through DBWj. An average system won’t see more than a
few of these.
|LGWR||The log writer process flushes the redo log buffer. It
writes the redo entries to disk and signals a completion.
|CKPT||The checkpoint process is responsible for initiating
check points. A check point is when the system periodically dumps
all the dirty buffers to disk. Most commonly, this occurs when the
database receives a shutdown command. It also updates the data file
headers and the control files with the check point information so
the SMON know where to start recovery in the event of a system
|ARCn||Up to 30 archiver processes (0–9, a–t) are
responsible for copying filled redo logs to the archived redo
storage area. If your database isn’t running in archive mode,
this process shuts down.
|CJQ0||The job queue coordinator checks for scheduled tasks
within the database. These jobs can be set up by the user or can be
internal jobs for maintenance. When it finds a job that must be run
it spawns the following goodie.
|J000||A job queue process slave actually runs the job. There
can be up to 1,000 of them (000–999).
|DIA0||The diagnosability process resolves deadlock situations
and investigates hanging issues.
|VKTM||The virtual keeper of time sounds like a fantasy game
character but simply provides a time reference within the
|LREG||The listener registration process, which registers
database instance and dispatcher information with the Oracle
listener process. This allows incoming user connections to get from
the listener to the database.
|MMON||The manageablity monitor process supports the Automatic
Workload Repository (AWR) by capturing statistics, monitoring
threasholds, and taking snapshots. This is related to performance
tuning and troubleshooting.
|MMNL||The manageability monitor lite’s job is to write
Active Session History (ASH) statistics from ASH buffer in the SGA
to disk. This is related to performance tuning and
Other background processes exist, as you can tell by the “over 200” number at the beginning. However, those described below are the most common, and you will find them on almost all Oracle installations. When you engage some of Oracle’s more advanced functionality, you’ll see other processes.
It’s very easy to see these background processes if you have an Oracle installation available on Linux or UNIX. The ps –ef |grep ora_ portion lists the background processes. This situation works very well because all background processes begin with ora_.