Oracle tool background process

Job Queue configured: The CJQ0 process is the Job Queue Coordinator (jobqueuecoordinator). OracleAQ is configured, from Q000 (AQ queue process, AQqueueprocess) and QMN

Job queue configured: The CJQ0 process is the job queue coordinator. Oracle AQ is configured, from Q000 (AQ queue process, AQ queue process) and QMN

These background processes are optional and can be selected based on your needs. They provide some tools, but these tools are not required to run the database every day, unless you want to use them yourself (such as Job Queue ),

Or you need to use the features of these tools (such as the new Oracle 10g diagnostic function ).

In UNIX, these processes are as visible as other background processes. If you execute ps commands, you can see these processes. At the beginning of the process section, I listed the execution results of the ps command.

(Some of them are listed here). As you can see, I have the following processes:

Job queue configured: The CJQ0 process is the job queue coordinator ).

Oracle AQ is configured, which can be seen from Q000 (AQ queue process, AQ queue process) and QMNC (AQ monitor process, AQ monistor process.

The self-configured SGA size is enabled, as shown in the memory manager (MMAN) process.

Oracle 10g manageability/diagnostics is enabled, as can be seen from the management monitor (MMON) and management monitor light (MMNL) processes:

1. CJQ0 and Jnnn processes: Job Queue

In version 7.0, Oracle provides the replication feature through a database object called snapshot. Job Queue is an internal mechanism used to refresh a snapshot (or set the snapshot to the current snapshot.

The Job Queue process monitors a job table, which tells it when to refresh Each snapshot in the system.

The Job Queue process monitors a job table, which tells it when to refresh Each snapshot in the system. In Oracle 7.1, Oracle provides this function through a database package named DBMS_JOB.

Therefore, the snapshot-related process in plaintiff 7.0 has changed to "Job Queue" in Versions later than 7.1 ". later, the name of the parameter controlling Job Queue behaviors (check frequency and how many queue processes should be included) also changed.

From SNAPSHOT_REFRESH_INTERVAL and SNAPSHOT_REFRESH_PROCESSES to JOB_QUEUE_INTERVAL and JOB_QUEUE_PROCESS. In the current version, you can only set the JOB_QUEUE_PROCESS parameter.

You can have up to 1000 Job Queue processes. The names are J000, J001,..., and J999 respectively. These processes are widely used in replication and are part of the materialized view refresh process. Stream-based replication uses AQ to complete replication. Therefore

Do not use Job Queue processes. Developers often use job queues to perform or repeatedly run jobs at a high level of one time (in the background). For example, they send an email in the background, alternatively, you can complete a batch process that runs for a long time in the background.

By doing this in the background, we can achieve this effect: although a task takes a long time, however, in the eyes of an impatient end user, the time spent is not much (he may think that the task is running much faster, but in fact it may not ).

This is similar to what Oracle uses LGWR and DBWn processes to do. They do a lot of work in the background, so you don't have to wait for them to complete all the tasks in real time.

The Jnnn process is similar to the shared server, but there are some aspects of the dedicated server. They process a job and then process the next job. In this sense, they are shared, but they manage the memory more like a dedicated server (its UGA is in the PGA, instead of in SGA ). each job queue process runs only one job at a time, one by one until it is complete. Because of this, if we want to run multiple jobs at the same time, we need multiple processes. Here, there is no multi-breed or just-for-origin preemption. Once a job is run, it will continue to run until it is completed (or failed ).

You will notice that after a period of time, the Jnnn process will continue to come and go. That is to say, if you have configured a maximum of 1000 Jnnn processes, you will not see that there are actually 1000 processes starting the database at will. On the contrary

A process, namely the Job Queue Coordinator (CJQ0), starts the Jnnn process when it sees the job to be run in the job queue. If the Jnnn Process completes its work and finds no new job to be processed, the Jnnn process will exit, that is, it will disappear. Therefore, if you schedule most jobs to run at a.m. (no one is present), you may never see these Jnnn processes.

2. QMNC and Qnnn: Advanced queue

The QMNC process is equivalent to the CJQ0 process in the job table for the AQ table. The QMNC process monitors the advanced queue and warns that the "dequeuer process" (dequeuer) waiting for messages is deleted from the queue: a message has become available. QMNC and Qnnn are also responsible for the propagation. That is to say, they can move messages in one database to the queue of another database to achieve dequeueing ).

The Qnnn process is equivalent to the relationship between the Jnnn process and the CJQ0 process. The QMNC process notifies the Qnnn process of what work should be done, and the Qnnn process will process the work.

The QMNC and Qnnn processes are optional background processes. The AQ_TM_PROCESSES parameter can specify a maximum of 10 such processes (Q000,..., Q008) and a QMNC process. If the AQ--TM_PROCESSES is set to 0, there is no QMNC or Qnnn process. Unlike Jnnn processes used by job queues, Qnnn processes are persistent. If you set AQ_TM_PROCESSES to 10

We can see 10 Qnnn processes and a QMNC process, and these processes exist throughout the generation of the instance.

3. EMNn: Event Monitor Process)

The EMNn process is part of the AQ architecture and is used to notify queue subscribers interested in certain messages. The notification is completed asynchronously. You can use Oracle Call Interface (OCI) functions to register message notifications.

. Callback is a function in the OCI program. This function is automatically called as long as there is a message in the queue that the consumer is grateful. The EMNn background process is used to notify the consumer. The EMNn process is automatically started when the first notification is sent to the instance. Then the application can issue an explicit message_receive (dequeue) to get the message.

4. MMAN: Memory Manager)

This process is added in Oracle 10 GB and will be used when the SGA size feature is set automatically. The MMAN process is used to coordinate the size settings and small adjustments of each component (default buffer pool, sharing pool, Java pool, and large pool) in the shared memory.

5. MMON, MMNL, and Mnnn: Manageability Monitor)

This process is used to fill in the Automatic Workload Repository (AWR), which is a new feature in Oracle 10 Gb. The MMNL process refreshes the statistical results from SGA to the database table according to the scheduling. The MMON process is used to "automatically detect" database performance problems and implement new self-tuning features. the Mnnn process is similar to the Jnnn and Qnnnn processes in the Job Queue: The MMON process requests these subordinate processes to complete the work on behalf of them. mnnn processes are essentially temporary and will come and go as needed.