Detailed description of processes after the Oracle database Process

Last time we introduced:Oracle Database ProcessServer process details. This article mainly introducesBackground ProcessWe know that Oracle instances include two parts: SGA and a group of background processes. The actual maintenance tasks required for background process execution to ensure database operation.

For example, a process maintains the block buffer cache for us and writes the block to the data file as needed. Another process is responsible for copying online redo log files to an archive object when they are full. Another process is responsible for cleaning the process after it is aborted. Each process focuses on its own tasks, but it works with all other processes. For example, when the process responsible for writing a log file fills up a log and turns to the next log, it will notify the process responsible for archiving the filled log file and tell it that it has been active.

You can use a V $ view to view all possible Oracle background processes and determine which background processes are being used in your system:

 
 

  
  
SQL> select paddr, name, descriptionfrom v$bgprocess order by paddr desc;  
  
  
PADDR   NAME  DESCRIPTION  
  
  
-------- ---------------------------------------------------------------------  
  
  
3621D49C QMNC  AQ Coordinator  
  
  
3621CEE8 ARC2  Archival Process 2  
  
  
3621C934 ARC1  Archival Process 1  
  
  
3621C380 ARC0  Archival Process 0  
  
  
3621A148 MMNL  Manageability Monitor Process 2  
  
  
36219B94 MMON  Manageability Monitor Process  
  
  
362195E0 CJQ0  Job Queue Coordinator  
  
  
3621902C RECO  distributed recovery  
  
  
36218A78 SMON  System Monitor Process  
  
  
362184C4 CKPT  checkpoint  
  
  
36217F10 LGWR  Redo etc.  
  
  
PADDR   NAME  DESCRIPTION  
  
  
-------- ---------------------------------------------------------------------  
  
  
3621795C DBW0  db writer process 0  
  
  
362173A8 MMAN  Memory Manager  
  
  
36216DF4 PSP0  process spawner 0  
  
  
36216840 PMON  process cleanup  
  
  
00      DIAG  diagnosibility process  
  
  
00      FMON  File Mapping Monitor Process  
  
  
00      LMON  global enqueue servicemonitor  
  
  
00      LMD0  global enqueue servicedaemon 0  
  
  
.....  
  
  
00      ASMB  ASM Background  
  
  
00      GMON  diskgroup monitor  
  
  
157 rows selected. 
 
 

Note: In this view, the rows where PADDR is not 00 are system-configured and running process threads ). There are two types of background processes: one center focused) the process of the task as described above) and the process that completes various other tasks is a tool process ).

For example, an internal job queue jobqueue has a tool background process that can be used through the DBMS_JOB package. This process monitors job queues and runs jobs in them. In many ways, this is like a dedicated server process, but there is no customer connection.

Next we will analyze various background processes, first look at the processes with central tasks, and then introduce the tool processes.

Central background process

Figure 5-4 shows an Oracle background process with a central focused function.

You may not see all these processes when starting an instance, but some of them must exist. In ARCHIVELOG mode, you may only see the ARCn archiving process) and enable automatic archiving. If Oracle RAC is run, this Oracle configuration allows multiple instances on different machines in a cluster to load and open the same physical database, only the LMD0, LCKn, LMON, and LMSn are displayed.

For the sake of conciseness, the sharing server scheduler Dnnn and the sharing server Snnn are not shown in Figure 5-4. Therefore, Figure 5-4 roughly shows the processes that may be seen when you start an Oracle instance and load and open a database. For example, in my Linux system, after the instance is started, there are the following processes:

 
 

  
  
[oracle@db1 ~]$ ps -ef|grep 'ora_.*_dave*'  
  
  
oracle   4123     1  0 20:13 ?        00:00:05 ora_pmon_dave1  
  
  
oracle   4125     1  0 20:13 ?        00:00:05 ora_psp0_dave1  
  
  
oracle   4127     1  0 20:13 ?        00:00:02 ora_mman_dave1  
  
  
oracle   4129     1  0 20:13 ?        00:00:05 ora_dbw0_dave1  
  
  
oracle   4131     1  0 20:13 ?        00:00:21 ora_lgwr_dave1  
  
  
oracle   4133     1  0 20:13 ?        00:00:13 ora_ckpt_dave1  
  
  
oracle   4135     1  1 20:13 ?        00:01:12 ora_smon_dave1  
  
  
oracle   4137     1  0 20:13 ?        00:00:04 ora_reco_dave1  
  
  
oracle   4139     1  0 20:13 ?        00:00:16 ora_cjq0_dave1  
  
  
oracle   4141     1  1 20:13 ?        00:01:33 ora_mmon_dave1  
  
  
oracle   4143     1  0 20:13 ?        00:00:08 ora_mmnl_dave1  
  
  
oracle   4145     1  0 20:13 ?        00:00:00 ora_d000_dave1  
  
  
oracle   4147     1  0 20:13 ?        00:00:00 ora_s000_dave1  
  
  
oracle   4156     1  0 20:13 ?        00:00:01 ora_arc0_dave1  
  
  
oracle   4158     1  0 20:13 ?        00:00:05 ora_arc1_dave1  
  
  
oracle   4163     1  0 20:14 ?        00:00:03 ora_qmnc_dave1  
  
  
oracle   4167     1  0 20:15 ?        00:00:24 ora_q000_dave1  
  
  
oracle   4169     1  020:15 ?        00:00:00 ora_q001_dave1  
  
  
oracle   5109     1  1 21:48 ?        00:00:00 ora_j000_dave1  
  
  
oracle   5141  5111  0 21:49 pts/4    00:00:00 grep ora_.*_dave2* 
 
 

Process naming rules: Process names start with ora. It is followed by four characters, indicating the specific name of the process, followed by ORACLE_SID, site identifier ).

On UNIX, it is easy to identify the Oracle background process and associate it with a specific instance on Windows, because on Windows, these background processes are actually only threads in a larger process ).

These processes are actually the same binary executable program. For each "program", there is no separate executable file. You can try to find out, but no arc0 binary executable program can be found at any location on the disk, or LGWR or DBW0. These processes are actually the names of oracle, that is, the binary executable program running ). They only create aliases for themselves at startup to easily identify processes. In this way, a large amount of object code can be efficiently shared on the UNIX platform. There is nothing special on Windows, because they are only threads in the process, so of course, they are just a large binary file.

Automatic Storage Management (ASMB) process: the ASMB process runs in the database instance that uses ASM. It is responsible for communicating with the management and storage ASM instance, providing updated statistics to the ASM instance, and providing a "Heartbeat" to the ASM instance to let the ASM instance know that it is still alive, and it is still running.

Rebalance (RBAL) process: the RBAL process is also running in the database instance that uses ASM. When a disk is added or removed from the ASM disk group, the RBAL process is responsible for processing the load redistribution request ).

The following process appears in the Oracle RAC instance. RAC is an Oracle configuration, that is, multiple instances in the cluster can load and open a database, where each instance runs on a separate node, usually a separate physical computer ). In this way, you can have multiple instances to access the same database file in a full read/write mode.

RAC has two main objectives:

High Availability: with Oracle RAC, if one node/computer in the cluster fails due to software, hardware, or human errors, other nodes can continue to work and access the database through other nodes. You may lose some computing power, but won't be able to access the database.

Scalability: you do not need to purchase a larger machine to handle the increasing workload. This is called vertical scaling.) RAC allows you to add resources in another way, that is, adding more machines to the cluster is called horizontal scaling ). For example, you do not need to scale down your 4-CPU to 8 or 16 CPUs by using RAC, you can choose to add another relatively low-cost 4-CPU machine or multiple such machines ).

The following processes are unique to the RAC environment:

Lock monitor Lockmonitor, LMON) process: LMON monitors all instances in the cluster and checks whether an instance has failed. This helps to recover the global lock held by the failed instance. It is also responsible for re-configuring the lock when the instance leaves or joins the cluster, and leaving the cluster when other resource instances fail, and joining the cluster when the instance recovers to online, or new instances may be added to the cluster in real time ).

Lock manager daemon, LMD) process: the LMD process processes the lock manager service requests for global cache services to keep block buffers consistent among instances. It is mainly used as a proxy broker to send resource requests to a queue, which is processed by the LMSn process. LMD detects and resolves global deadlocks and monitors lock timeouts in the global environment.

Lock Manager server Lockmanager server, LMSn) process: As mentioned above, in a RAC environment, each Oracle instance runs on different machines in the cluster, they all access the same set of database files in one read/write mode. For this purpose, the cache of the SGA block must be consistent with each other. This is also one of the main goals of the LMSn process. In earlier versions of Oracle Parallel Server, OPS), this is achieved through ping. That is to say, if a node in the cluster needs a read consistency view of the block, and the block is locked by another node in an exclusive mode, data Switching requires the disk to refresh the output to ping the block ). If you only want to read data, ping is too expensive. Now it is different. With LMSn, you can quickly cache and exchange data to the cache on the high-speed connection of the cluster. Each instance can have up to 10 LMSn processes.

Lock, LCK0) process: This process features very similar to the LMD process described earlier, but it processes all global resource requests, not just database block buffer requests.

Diagnostic daemon Diagnosabilitydaemon, DIAG) process: DIAG can only be used in the RAC environment. It monitors the overall "Health Status" of the instance and captures the information required to handle instance failures.

Tool background process

All the background processes are optional and can be selected based on your needs. They provide some tools, but these tools are not necessary to run the database every day, unless you want to use 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.

 
 

  
  
[oracle@db1 ~]$ ps -ef|grep 'ora_.*_dave*'  
  
  
oracle   4123     1  0 20:13 ?        00:00:05 ora_pmon_dave1  
  
  
oracle   4125     1  0 20:13 ?        00:00:05 ora_psp0_dave1  
  
  
oracle   4127     1  0 20:13 ?        00:00:02 ora_mman_dave1  
  
  
oracle   4129     1  0 20:13 ?        00:00:05 ora_dbw0_dave1  
  
  
oracle   4131     1  0 20:13 ?        00:00:21 ora_lgwr_dave1  
  
  
oracle   4133     1  0 20:13 ?        00:00:13 ora_ckpt_dave1  
  
  
oracle   4135     1  1 20:13 ?        00:01:12 ora_smon_dave1  
  
  
oracle   4137     1  0 20:13 ?        00:00:04 ora_reco_dave1  
  
  
oracle   4139     1  0 20:13 ?        00:00:16 ora_cjq0_dave1  
  
  
oracle   4141     1  1 20:13 ?        00:01:33 ora_mmon_dave1  
  
  
oracle   4143     1  0 20:13 ?        00:00:08 ora_mmnl_dave1  
  
  
oracle   4145     1  0 20:13 ?        00:00:00 ora_d000_dave1  
  
  
oracle   4147     1  0 20:13 ?        00:00:00 ora_s000_dave1  
  
  
oracle   4156     1  0 20:13 ?        00:00:01 ora_arc0_dave1  
  
  
oracle   4158     1  0 20:13 ?        00:00:05 ora_arc1_dave1  
  
  
oracle   4163     1  0 20:14 ?        00:00:03 ora_qmnc_dave1  
  
  
oracle   4167     1  0 20:15 ?        00:00:24 ora_q000_dave1  
  
  
oracle   4169     1  020:15 ?        00:00:00 ora_q001_dave1  
  
  
oracle   5109     1  1 21:48 ?        00:00:00 ora_j000_dave1  
  
  
oracle   5141  5111  0 21:49 pts/4    00:00:00 grep ora_.*_dave* 
 
 

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. In Oracle 7.1, Oracle provides this function through a database package named DBMS_JOB. Therefore, the snapshot-related process in the original version 7.0 has changed to "Job Queue" in the version 7.1 and later ". Later, the frequency of parameter checks to control Job Queue behaviors and

The name of the queue process is also changed, from SNAPSHOT_REFRESH_INTERVAL and SNAPSHOT_REFRESH_PROCESSES to JOB_QUEUE_INTERVAL and JOB_QUEUE_PROCESSES. In the current version, you can only set the JOB_QUEUE_PROCESSES parameter.

You can have up to 1000 Job Queue processes. The names are J000, J001 ,..., J999. These processes are widely used in replication and are part of the materialized view refresh process. Stream-based replication is a new feature in Oracle9iRelease 2). AQ is used for replication, so the Job Queue process is not used.

Developers often use job queues to schedule one-time backend jobs or repeated jobs. For example, they can send an email in the backend or complete a long-running batch processing in the backend. By doing this in the background, you can achieve this effect: although a task takes a long time, however, in the opinion of an impatient end user, the time spent is not much. He thinks the task runs 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 with a PGA in its UGA, 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. There is no multi-thread or job 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 a maximum of Jnnn processes are configured, you will not see that processes are started with the database. On the contrary, only one process (CJQ0) is started at the beginning. When a job to be run is displayed in the job team list, the Jnnn process is started. 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 and no one is present), you may never see these Jnnn processes.

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 you to delete the "queue process" dequeuer waiting for messages from the queue.): a message has become available. QMNC and Qnnn are also responsible for queue propagation). That is to say, messages that can be added to the queue in one database can be moved to the queue in another database to 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. You can specify the AQ_TM_PROCESSES parameter to create a maximum of 10 such processes named Q000 ,..., Q009) and a QMNC process. If 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, you can see 10 Qnnn processes and a QMNC process at the database startup, and these processes exist throughout the entire life cycle of the instance.

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 (Oracle Call Interface, OCI) functions to register Message notification callbacks. Callback is a function in the OCI program. This function is automatically called as long as there is a message that the consumer is interested in the queue. The EMNn background process is used to notify the consumer. The EMNn process is automatically started when a notification is sent to the instance for the first time. Then the application can issue an explicit message_receive (dequeue) to get the message.

MMAN: Memory Manager (Memory Manager)

This process is added in Oracle 10g. This process will be used when the SGA size feature is set automatically. MMAN processes are used to coordinate the default buffer pool, Shared Pool, Java pool, and large pool of each component in the shared memory.

MMON, MMNL, and Mnnn: Manageability Monitor)

These processes are used to fill in the Automatic workload repository Automatic WorkloadRepository, 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 or Qnnn process in the Job Queue. The MMON process requests these subordinate processes to complete the work on their behalf. Mnnn processes are essentially temporary and will come and go as needed.

CTWR: Modify the Tracking Process Change Tracking Process)

This is an optional process added to the Oracle 10g Database. The CTWR process is responsible for maintaining new Modification Trace files.

RVWR: Restore Writer Recovery Writer)

This process is also an optional process added to the Oracle 10g database. It is responsible for maintaining the "front" image of the block in the Flash recovery zone and should be used together with the FLASHBACKDATABASE command.

Background processes of other tools

Other tool processes are not listed. For example, Oracle Data Guard has a group of related processes, which helps to migrate redo information from one database to another and apply the redo information. There are also some processes related to the new data pump tool of Oracle 10g, which will be seen in some data pump operations. There are also some stream application and capture processes. However, the above list basically covers most common background processes you may encounter.

Here is an introduction to the processes behind the Oracle database process. I hope this introduction will be helpful to you!