These background processes are totally optional, based on your need for them. They provide facilities not necessary to run the database day to day, unless you are using them yourself, such as the job queues, or are making use of a feature that uses them, such as the diagnostic capabilities.
These processes will be visible in UNIX/Linux as any other background process would be. If you do a ps, you will see them. In my ps listing from the beginning of the “Focused Background Processes” section (reproduced in part here), you can see that I have
•\ Job queues configured. The CJQ0 process is the job queue coordinator.
•\ Oracle AQ configured, as evidenced by the Qnnn (AQ queue process) and QMNC (AQ monitor process).
•\ Automatic memory management enabled, as evidenced by the Memory Manager (MMAN) process.
•\ Oracle manageability/diagnostic features enabled, as evidenced by the Manageability Monitor (MMON) and Manageability Monitor Light (MMNL) processes.
Let’s take a look at the various processes you might see depending on the features you are using.
CJQ0 and Jnnn Processes: Job Queues
In the first 7.0 release, Oracle provided replication in the form of a database object known as a snapshot. Job queues were the internal mechanism by which these snapshots were refreshed, or made current.
A job queue process monitored a job table that told it when it needed to refresh various snapshots in the system. In Oracle 7.1, Oracle Corporation exposed this facility for all to use via a database package called DBMS_JOB. So a process that was solely the domain of the snapshot in 7.0 became the “job queue” in 7.1 and later versions. Over time, the parameters for controlling the behavior of the job queue (how frequently it should be checked and how many queue processes there should be) changed in name from SNAPSHOT_REFRESH_INTERVAL and SNAPSHOT_REFRESH_PROCESSES to JOB_QUEUE_ INTERVAL and JOB_QUEUE_PROCESSES. In current releases, only the JOB_QUEUE_PROCESSES parameter is exposed as a user-tunable setting.
You may have up to 1000 job queue processes. Their names will be J000 … J999. These processes are used heavily in replication as part of the materialized view refresh process. Streams-based replication uses AQ for replication and therefore does not use the job queue processes. Developers also frequently use the job queues in order to schedule one-off (background) jobs or recurring jobs such as sending an email in the background or processing a long-running batch process in the background. By doing some work in the background, you can make a long task seem to take much less time to an impatient end user (they feel like it went faster, even though it might not be done yet). This is similar to what Oracle does with LGWR and DBWn processes; they do much of their work in the background, so you don’t have to wait for them to complete all tasks in real time.
The Jnnn, where nnn represents a number, processes are very much like a shared server, but with aspects of a dedicated server. They are shared in the sense that they process one job after the other, but they manage memory more like a dedicated server would (their UGA memory is in the PGA, not the SGA). Each job queue process will run exactly one job at a time, one after the other, to completion. That is why we may need multiple processes if we wish to run jobs at the same time. There is no threading or preempting of a job. Once a job is running, it will run to completion (or failure).
You will notice that the Jnnn processes come and go over time. That is, if you configure up to 1000 of them, you will not see 1000 of them start up with the database. Rather, a sole process, the job queue coordinator (CJQ0), will start up, and as it sees jobs that need to be run in the job queue table, it will start the Jnnn processes. As the Jnnn processes complete their work and discover no new jobs to process, they will start to exit, to go away. So, if you schedule most of your jobs to run at 2:00 a.m. when no one is around, you might well never actually see these Jnnn processes.