Background ProcessIn order to provide services to multiple users and ensure system performance, there are multiple Oracle processes called background processes (background process) in a multi-process Oracle System (multiprocess Oracle Systems). an Oracle instance can contain a variety of background processes that do not necessarily all appear in the instance. The number of background processes running in the system is numerous, and users can query information about the background process through the v$bgprocess view. The background processes that may be running in an Oracle instance are:• Data write process (DBWN)• Log Write process (LGWR)• Checkpoint process (CKPT)• System monitoring process (Smon)• Process monitoring process (Pmon)• Recovery process (RECO)• Job Queue process• Archive process (ARCn)• Queue monitoring process (QMNN)• Other background processesIn many operating systems, background processes can be created automatically when an instance is started. Diagramshows how the background process interacts with parts of the Oracle database, which are later described in the background process.
background processes in a
multi-process
Oracle instance
In the middle of this diagram is the SGA. The upper is Reco,pmon, and the Smon process, in which the two-way arrows indicate the communication between each process and the instance. The lower left side is the DBW0 and LGWR processes, each of which communicates with the redo log buffers, respectively, and the data buffers, while also accessing the data files and redo log files. other processes, such as ARC0, require access to offline storage devices and control files, and CKPT, which require access to data files and control files, are also shown in this diagram. Database Write Process (DBWN)database writer Process (DBWN) writes the contents of buffer to the data file. The DBWN process is responsible for writing the modified buffer in buffer cache, which is the dirty data to disk. for most systems, 1 processes (DBW0) are sufficient, but you can also increase the database write process by setting the initialization parameter db_writer_processes, numbering from Dbw0-dbw9 to DBWA-DBWJ and up to 20 processes. But the premise is that there must be enough CPU for these processes to use, in a single CPU system, the additional configuration of the process does not improve performance, so the number of CPUs and processors need to determine how to set this parameter. when a buffer is modified in the buffer cache of the database, it is marked as dirty (dirty). The cold junction (cold buffer) of buffer cache refers to the least recently used buffer that is selected based on the LRU (least recently used) algorithm. The DBWN process writes the cold-ended, dirty buffer to the disk so that the user process can look for cold junction, clean buffer to read the new block into the cache. When a buffer is modified (soiled) by the user process, this buffer is no longer free buffer and cannot be used for writing new data. If the number of free buffer is too small, the user process will not find enough space for the data to write. The DBWN process effectively manages the buffer cache, allowing the user process to always get free buffer. The dbwn process always writes cold junction, dirty buffer to disk, dbwn while improving the performance of the find free buffer, another recently used buffer remains in memory. For example, storing chunks of data that are accessed frequently and with smaller tables or indexes can be keep in the cache without the need to read from disk repeatedly. Because the LRU algorithm keeps the data block with high access frequency in the buffer cache, a buffer is written to the disk, and the buffer contains less data that is immediately accessible. The dbwn process writes the dirty data buffer (dirty buffers) to disk when the following conditions are met:• After a certain number of buffer has been scanned by the server process, no clean, usable buffer is found, which notifies dbwn to write. Dbwn the operation to write buffer to disk is asynchronous because there are other processes executing while DBWN is working. · Dbwn periodically writes buffer, which allows checkpoint to move forward, checkpoint is the starting position of the redo log when an instance needs an instance recovery. This location is determined by the oldest dirty data buffer (dirty buffers) in buffer. In either case, the DBWN process is written in batches (multiple chunks) to improve performance. The number of chunks written at one time varies with the operating system, and there is no fixed value. Log Write process (LGWR)Log Write process log writer process (LGWR) is responsible for managing the log buffers and writing the log buffers to log files on disk. LGWR writes a redo entry from the last copy to buffer to disk. The log buffers (redo log buffer) are a ring buffer (circular). When the LGWR process writes a redo entry for the log buffer to the log file, the server process also copies the new entries to the log buffer to overwrite the entries that have been written to the disk. LGWR often needs to be guaranteed to write fast enough, even when redo log is frequently accessed, ensuring that the buffer has enough space to write new entries. LGWR writes a portion of the contiguous buffer to the disk. The contents of LGWR writing are:• A user process submits a commit record for the transaction. · Redo log buffer, the following 3 conditions, which satisfy one of the write. • Write once every three seconds. • Log buffers are used One-third. • When the dbwn process writes a dirty buffer to the disk, the log that needs to be written is not written yet.
Note:before the DBWN process writes dirty data to the disk, all redo records related to the modified data must be written to the disk, which is the first-write log principle (
Write-ahead protocol). If Dbwn discovers that some redo records are not written to the disk, it notifies LGWR to write them and waits for the LGWR process to write the data buffer to disk after it writes the relevant data in the Redo log buffer. LGWR writes synchronously to multiple mirror members of a log group. If one of the member files is corrupted, LGWR continues to write to the other members and logs the error to the trace file and alert log of the LGWR process. If all member files of a log group are corrupted, or if the log group is temporarily unavailable because it is not archived, then LGWR cannot continue to work. When a user executes a commit, LGWR puts the commit record into the log buffer and writes it to the disk immediately along with the transaction's redo entry. The disk is written to the associated modified block of data when it waits for a more efficient time. This is a fast commit mechanism
. The commit record of a transaction and the associated redo entry are logged to disk via an atomic (atomic) write, a single event that determines whether the transaction was successfully committed. Although the modified data buffer has not been written to disk at this time, Oracle has been able to return to the user information about the successful transaction submission.
Note:Sometimes, if there is not enough space in the redo log buffer, the LGWR process writes redo log entries to disk before the transaction commits. Such redo log entries can only be stored permanently after the related transaction has been committed. when a user submits a transaction, the transaction is given a system change number
(SCN), and Oracle records this number in the redo entry for the transaction. The SCN is recorded in the Redo log, so the recovery (recovery) operation can be performed synchronously on RAC, distributed data. when data modification operations are more frequent, the LGWR process can take
bulk-commit (group commits) techniques to write data to the redo log file. For example, when a user submits a transaction, the LGWR process writes the Redo entry (redo entry) of the transaction to disk, while other users in the system may be executing a COMMIT statement. However, the LGWR process needs to write the redo information for subsequent commit transactions after the previous write operation has completed. When the redo entries for the first transaction are written to disk, the redo entries for things that are waiting to be committed during this time can be written to the disk together, which is less than the I/O operations required to write the redo entries for each transaction separately. In this way, Oracle reduces disk I/O and improves the performance of the LGWR process. If the commit frequency is consistently high in the system, the LGWR process contains more than one commit transaction per write data from the redo log buffer to the disk. checkpoint process (CKPT)when a
checkpoint occurs, Oracle must update the header of all data files and record the checkpoint details. This action is done by the CKPT process, but the CKPT process does not write the data block to the disk, and the write action is always done by the DBWN process. The
DBWR checkpoints statistics displayed by the System_statistics Monitor of Enterprise Manager show the checkpoint action that needs to be completed in the system. system Monitoring Process (Smon)The System Monitor process (Systems monitor Process,smon) will be responsible for recovery (recovery) work if required when the instance is started. In addition, Smon is responsible for clearing temporary segments (temporary segment) that are no longer used in the system, and for merging adjacent data Extensions (managed) for table spaces managed by the Data Dictionary (dictionary tablespace extent). During instance recovery, if some abnormally terminated transactions are not recovered due to file read errors or the required files are offline, Smon resumes these transactions again after the table space or file is brought back online. The Smon process periodically checks to see if it is needed, and other processes within the system can invoke the Smon process if needed. In a RAC environment, an instance of the Smon process can perform an instance recovery (instance recovery) for an error CPU or instance. process monitoring Process (Pmon)when a user process fails, the process monitoring process (Monitor,pmon) restores it. The Pmon process cleans up the data buffers (database buffer cache) and frees the resources used by the user process. For example, it can reset the state of the Active transaction table (active Transaction table), release the lock, and remove a process ID from the active process list. The Pmon process periodically checks the scheduler (dispatcher) and service processes (server process) to restart the process that has stopped running (excluding the process that Oracle intentionally stops). The Pmon process is also responsible for registering the information for the instance and scheduler processes with the network listener (NET listener). As with Smon, the Pmon process periodically checks to see if it is needed, and other processes within the system can invoke the Pmon process if needed. recovery Process (RECO)The recovery process recoverer processes (RECO) is used for distributed database structures to automatically resolve errors in distributed transactions. The reco process of a node is automatically connected to a related other database of the problematic distributed transaction. When Reco is reconnected to the associated database service, it automatically resolves the problematic transaction. and removes data related to this transaction from the active transaction table (pending transaction tables) of the related database. If the reco process cannot connect to the remote service, RECO attempts to connect again after a certain interval of time. However, the time interval for each attempt to connect will grow exponentially. The RECO process is started only if the instance allows distributed transactions. The number of concurrent distributed transactions is not limited in the instance. Job Queuing process (Job queue Processes)generally consists of two types of processes:The job Queue coordination Process coordinator Job queue process (CJQN), which acts as a monitor for the job queues. the queue process that executes the job, job queue processes (JNNN), is generated by the CJQN completion schedule. The job queue process is used for batching, performing user jobs, and can be seen as a dispatch service for dispatching jobs on Oracle instances such as PL/SQL statements or stored procedures. Provides the start time and schedule interval, which the job queue process can perform automatically and periodically based on this configuration. Job Queue processes can be managed dynamically. You can allow the job queue client to use multiple job queue processes as needed, and the resources it uses will be freed when a job queue process enters an idle state (idle). a dynamic job queue process can run a large number of jobs at a specified time interval. The user's job is performed by the CJQ process to the job queue process. The steps are as follows:1. The coordinated process called CJQ0 (Coordinator process) periodically selects the job to be run from the System job$ table. The selected jobs will be sorted by time. 2. The CJQ0 process dynamically generates the job queue's slave process to run these jobs, numbered from j000-j999. 3. The job queue process executes a job selected by the CJQ process. Each process can only perform one job at a time. 4. When a task queue process finishes executing a job, it is able to accept the next job. If there are no jobs in the system that need to be dispatched, the process goes into hibernation (sleep state), and the process also wakes up periodically (wake up) waiting for other jobs to be allocated. If there are no new jobs in the preset time, the process terminates. the initialization parameter job_queue_processes represents the maximum number of job queue processes that can be executed in parallel in the instance. However, the client should not assume that all job queue processes are used to execute the job.
Note:if the initialization parameter job_queue_processes is set to 0, the reconcile process (CJQ) will not be started. Archive Process (ARCn)The archive process (archiver PROCESS,ARCN) copies the redo log files to the specified storage device when a log switch is occurring. The ARCN process is started only when the database is running in Archivelog mode and the automatic archiving feature is turned on. up to 10 ARCn processes (ARC0 to ARC9) can be run in an Oracle instance. If the current ARCn process does not meet the needs of the workload, the LGWR process will start a new ARCn process. Alert log will record the LGWR start ARCN process. If you anticipate heavy archival tasks for your system, such as bulk data loading, you can specify multiple archive processes by setting the initialization parameter log_archive_max_processes, which can be dynamically modified by the ALTER SYSTEM statement. Increase or decrease the number of archive processes. However, it is not usually necessary to change this parameter, which defaults to 1 because the LGWR process automatically starts a new ARCN process when the system load increases. Queue monitoring Process (QMNN)The queue monitoring process is an optional process that provides an Oracle workflow advanced queue for monitoring information queues. A maximum of 10 monitoring processes can be configured. These processes are similar to the difference between the job queue process and other Oracle background processes in that these two types of process errors do not result in an entire instance error. scheduling Process (dnnn)The dispatch process dispatcher (DNNN) is an optional Oracle background process that exists only in a shared server environment. Memory Management process (Mman)Memory Management Process Memories Manager (Mman) is an SGA background process. 10g new feature, automatic shared memory management automatic shared Memories Management (ASMM) when enabled, this new background process will be available. The Mman service, like the SGA memory broker, coordinates the size of each component of the memory. The SGA memory broker is well aware of the size of the various components of the RAM and the operations that need to be adjusted. Resume Write process (RVWR)Flashback Database is a new feature of oracle10g, which periodically writes changed blocks to the log file of the flashback log after the Flashback database is started. These logs are not written by the traditional log Writer (LGWR) procedure, but rather by a new procedure called Recovery writer (RVWR). This is the new process for oracle10g. The flashback database refers to returning a database to an earlier database state, and the Flashback database feature provides a quick way to quickly return a database to an earlier point in time, unlike traditional time-based restores. The database flashback can only be recovered from the following error:• Caused by a logic error. • Caused by a user error. You cannot recover a database from a media error by using the Flashback feature. The time required to flash back the database is proportional to the changed data, not the size of the database. Note that once resetlogs, it is no longer possible to flashback to a point in time before Resetlogs. Memory Management process (Mmon)Memory Management process (Mmon) is a new process for 10g, and it unites the new features of the AWR to perform various and manageability-related (manageability-related) background tasks, such as:• Submit a warning when a measured value (metrics) exceeds the preset limit value (threshold value)• Create a new Mmon membership process (Mmon slave process) to take a snapshot (snapshot)• Capture statistics for recently modified SQL objectsits slave process is M000. Other background processesOther background processes may also be running in the Oracle database. Include:The Memory Monitor Light (MMNL) process is responsible for performing lightweight, high-frequency, and manageability-related background tasks, such as capturing session history information, measuring value calculations, and so on. It works with AWR and writes the required buffer statistics to disk. The Mman process is responsible for executing the internal tasks of the database system. In an instance that uses automatic storage management (Automatic Storage Management), the Rbal process is responsible for coordinating the load balancing effort between disk groups. She can enable multiple instances to access an ASM disk (global Open) at the same time. Finally, the ORBN process actually performs the load balancing of the data extension. You can run multiple ORBN processes in an instance, ORB0,ORB1, and so on. When a DB instance uses an ASM disk group, the OSMB process is also started. This process is responsible for communicating with the ASM instance (Automatic Storage Management instance). The LMS (Global Cache Service) process, which exists in a RAC environment, manages resources and provides interactive control of instance resources. The change Tracking Writer (CTWR) process, a new process in 10g, is used to track the most recent changed blocks, allowing Rman to make incremental backups faster.
Oracle Background process
