1. Process ArchitectureThe processes in the Oracle DB system are divided into two main groups:? Running the application or Oracle tool code
User Process? Running the Oracle DB server code
Oracle DB Process(including
server processes and background processesWhen a user runs an application or an Oracle tool (for example, Sql*plus), Oracle DB creates a user process to run the user's application. Oracle DB also creates a "server process" to execute commands issued by the user process.
can connect to an Oracle instance, which starts when a user establishes a session。 In addition, the Oracle server creates a set of "background processes" for the instance.
started when an Oracle instance is started, these processes not only interact with each other, but also interact with the operating system to manage memory structures, write data to disk asynchronously by performing I/O operations, and perform other required tasks. The process structure differs for different Oracle DB configurations, depending on the operating system and the selected Oracle DB option. The code for the connected user can be configured to
dedicated server or shared server。?
Dedicated Server: For each user, the user process running the database application is serviced by a dedicated server process that executes the Oracle DB server code.
Shared Server: You do not have to provide a dedicated server process for each connection. The dispatcher leads multiple incoming network session requests to the shared server process pool. The shared server process serves all client requests.
Server ProcessOracle DB creates a server process to
processing requests for user processes connected to an instance。 In some cases, when the application and Oracle DB are operating on the same computer, the user process and the corresponding server process can be combined into a single process to reduce the overhead of the system. However, when the application and Oracle DB are running on different computers, the user process always communicates with Oracle DB through a separate server process. Server processes created on behalf of each user's application can perform one or more of the following actions:? Parsing and running SQL statements that are emitted by an application? Reads the necessary chunks of data from the data file on disk into the shared database buffer of the SGA (if the corresponding data block is not currently in the SGA)? Returns the result so that the application can process the information
Background ProcessTo maximize performance and meet the needs of multiple users, the multi-process Oracle DB system uses additional Oracle DB processes called "background processes." An Oracle DB instance can have multiple background processes.Common background processes in non-RAC, non-ASM environments include:
? database write Process (DBWN)
? Log write Process (LGWR)
Check Point process (CKPT)
? System Monitor Process (Smon)
? Process Monitor Process (Pmon)? The recovery process (RECO)? Job Queue Process? Archive process (ARCn)? queue monitor Process (QMNN)There may be other background processes in more advanced configurations, such as RAC. For more information about background processes, see the v$bgprocess view. Some background processes are created automatically when the instance is launched, and other background processes are started as needed. Other process structures are not specific to a single database, but can be shared among multiple databases on the same server. The Grid Infrastructure process and network processes belong to this class. The Oracle Grid Infrastructure process on Linux and UNIX systems includes:? Ohasd:oracle High Availability Service Daemon, responsible for starting the Oracle clusterware process? OCSSD: The cluster synchronization service daemon? DiskMon: Disk Monitor daemon, responsible for input and output protection for HP Oracle Exadata Storage Server? Cssdagent: Start, stop, and check the status of the CSS daemon OCSSD? Oraagent: Extend cluster components to support Oracle-specific requirements and complex resources? Orarootagent: A dedicated Oracle agent process to help manage resources owned by the root user (such as networks)
2. Database write Process (DBWN)The database write process (DBWN) can
writes the contents of a buffer to a data file。 The DBWN process is responsible for writing the modified buffer (the gray data buffer) in the database buffer cache to disk. Although a database write process (DBW0) is sufficient for most systems, you can configure additional processes (DBW1 to DBW9 and Dbwa to DBWJ) to improve write performance if the system needs to modify the data frequently. These additional DBWN processes are not available in a single-processor system. When a buffer in the database buffer cache is modified, the system marks it as a gray data buffer and adds it to the gray data buffer that is stored in the SCN order.Lruw (LRU write) List。 Therefore, the order matches the order of the redo operations that write redo logs for these changed buffers. When the number of available buffers in the buffer cache falls below an internal threshold (to the extent that the server process finds it difficult to obtain the available buffers), Dbwn writes the gray data buffers to the data file in the same order as the gray data buffers are modified in the order of the Lruw list. The SGA contains a memory structure that has a redo byte address (RBA) at a location in the redo stream and resumes from that location when the instance fails. This structure acts as a pointer to a redo and is written to the control file by the CKPT process at a frequency of every three seconds. Because Dbwn writes the gray data buffer in the SCN order, and the redo is performed in the SCN order, each time Dbwn writes a gray data buffer from the Lruw list, the pointers held in the SGA memory structure are moved forward so that the instance recovers (if needed) from the approximate correct position, starting with the read redo, and avoid unwanted I/O. This is called an "incremental checkpoint." Note: There are other scenarios where dbwn may perform write operations, such as when a tablespace is set to read-only or is placed offline. In these cases, the delta checkpoint does not occur because the order of the gray data buffers that belong to the corresponding data files is not related to the SCN order when they are written to the database. The LRU algorithm saves the more frequently accessed blocks in the buffer cache, so that when the buffers are written to disk, the buffers are unlikely to contain data that will soon be useful. The db_writer_processes initialization parameter specifies the number of dbwn processes. The maximum number of dbwn processes is 20. If the user does not specify the number of processes during startup, Oracle DB will determine how to set the db_writer_processes based on the number of CPUs and processor groups. The DBWN process writes the gray data buffer to disk in the following cases:? Notifies DBWN to perform a write operation when the server process cannot find a clean, reusable buffer after a buffer that scans the number of thresholds. Dbwn writes the gray data buffer asynchronously to the disk while performing other processing. Dbwn periodically writes buffers to advance checkpoints. The checkpoint is the location in the redo thread (log) where the instance recovery begins. The log location is determined by the oldest gray data buffer in the buffer cache. In all cases, the DBWN performs a batch (multi-block) write operation to improve efficiency. The number of blocks written in a multi-block write operation varies depending on the operating system.
3. The process of writing the records (LGWR)The log write process (LGWR) is responsible for managing the redo log buffers by
Write redo log buffer entries to disk
Redo log file on the。 Lgwr writes all the redo entries that have been copied to the buffer since the last write.
redo log buffers are circular buffers。 When LGWR writes redo entries in the Redo log buffer to the redo log file, the server process can copy the new entries to the Redo log buffers on top of those that have been written to disk. The write speed of the LGWR is usually fast enough to ensure that there is always room in the buffer for new entries, even when there is a large amount of access to the redo log. Lgwr writes a contiguous portion of the buffer to disk.The
LGWR performs a write operation in the following cases:
? When a user process commits a transaction
when the redo log buffer is One-third full
Redo entries for redo log buffers up to 1M
before the DBWN process writes the modified buffer to disk (if needed)
? Every 3 seconds
Dbwn can write a modified buffer (an antecedent write protocol) to a disk after all redo records associated with the buffer change must be written to disk. If Dbwn discovers that some redo records have not been written, it notifies LGWR to write the redo records to disk and waits for LGWR to finish writing the redo log buffers before writing the data buffers. LGWR will write to the current log group. If a file in the group is corrupted or unavailable, LGWR continues to write to the other files in the group and logs an error in the LGWR trace file and the system alert log. LGWR cannot continue to work if all the files in a group are corrupted, or if the group is not available because it has not been archived. When the user issues
COMMITStatement, LGWR places a commit record in the redo log buffer and immediately writes the record to disk along with the transacted redo log. The corresponding changes to the data block are deferred until the changes are written more efficiently. This is called a "quick commit mechanism." The atomic write of the redo entry that contains the transacted commit record is a single event that determines whether the transaction has been committed. OracleDB returns a success code for the committed transaction, although the data buffer has not yet been written to disk. If more buffer space is required, LGWR sometimes writes redo log entries before committing the transaction. These entries become permanent entries only after the transaction is submitted later. When a user submits a transaction, the transaction is assigned a system change number (SCN), and Oracle DB records the number in the redo log along with the transacted redo entry. The SCN is logged in the redo log so that recovery operations can be synchronized between the real application Clusters and the distributed database. When activities are more frequent, LGWR can write redo log files by using group commits. For example, suppose a user submits a transaction. LGWR must write the redo entry for the transaction to disk. When this happens, other users issue a commit statement. However, LGWR cannot write to the redo log file to commit these transactions until it finishes its previous write operation. After the first transacted entry is written to the redo log file, you can write the entire list of redo entries for the transaction that is waiting (not yet committed) in one operation to disk, which is less than the I/O required to process individual transaction entries separately. As a result, Oracle DB can minimize disk I/O and maximize the performance of LGWR. If the rate at which the request is submitted is consistently high, then each write (performed by LGWR) from the redo log buffer may contain more than one commit record.
4. Checkpoint process (CKPT)A checkpoint is a data structure that defines the system change number (SCN) in the redo thread of a database.
checkpoints are recorded in the control file and in each data file header. These are key elements of the recovery operation. When a checkpoint occurs, Oracle DB must update the header of all data files to record the details of the checkpoint. This is done by the CKPT process. The CKPT process does not write blocks to disk, and the work is performed by DBWN. The SCN recorded in the file header guarantees that all changes made to the database block prior to the SCN are written to disk. The System_statistics Monitor in Oracle Enterprise Manager displays the statistics DBWR checkpoint, which indicates the number of checkpoint requests that have been completed.
5. System Monitor Process (Smon)The System Monitor process (Smon) is
perform recovery When the instance is started (if required）。 Smon is also responsible for
clear no longer
temporary segment to use。 If any of the terminated transactions are skipped during instance recovery due to file read or offline errors, Smon will revert these transactions when the tablespace or file is brought back online. Smon check periodically to see if the process is needed. Other processes can also call it when it detects that a smon is needed.
6, Path monitor process (Pmon)The Process Monitor process (Pmon)
process recovery is performed when a user process fails。 Pmon is responsible for
Clear Database Buffering
Zone cache and freeing resources used by the user process。 For example, it resets the state of the active transaction table, releases the lock, and removes the process ID from the active process list. Pmon periodically checks the status of the dispatcher and server processes and restarts any dispatcher and server processes that have stopped running (but are not intentionally terminated by Oracle DB). Pmon also information about the instance and dispatcher processes
registering to a network listener。 Like Smon, Pmon periodically checks to see if it needs to be executed, or it can be called if another process detects the need for the process.
7. Recovery process (RECO)The recovery process (RECO) is
for distributed database configurationA background process that automatically resolves a failure involving distributed transaction processing. The reco process of the instance will
automatically connect to other databases that are related to distributed transactions with problems。 When the RECO process re-establishes a connection between the database servers involved, it
automatic resolution of all problematic transactions, from the pending transaction table for each database
Delete all rows that correspond to the resolved problematic transaction。 If the RECO process cannot connect to the remote server, RECO automatically attempts to reconnect after a timed interval. However, RECO waits for a period of time before it tries to reconnect, increasing (exponential growth).
8. Archive process (ARCn)
after a log switchover occurs, the archive process (ARCn) copies the redo log file to the specified storage device, collects the transaction redo data, and transfers that data to the alternate destination location。 The ARCN process exists only if the database is in Archivelog mode and automatic archiving is enabled. You can increase the maximum number of archive processes by using the Log_archive_max_processes initialization parameter if you expect the archived workloads to be heavy (for example, during bulk load of data). The ALTER system statement can dynamically change the value of this parameter to increase or decrease the number of ARCN processes.
9. Other Processes? Mmon: Performing background tasks related to manageability? MMNL: Perform frequent, lightweight tasks related to manageability? Mman: Perform automatic memory management tasks? CJQ0: Run user jobs that are used in batch processing? QMNC: Monitoring flow Advanced Queued Message Queuing There are several other background processes that may run, including:Manageability
Monitor Process (Mmon),Perform various background tasks related to manageability, such as:? Alert when a given metric exceeds its threshold? Get snapshots by deriving additional processes (Mmon dependent processes)? Capture statistical values of recently modified SQL objects
Lightweight Manageability Monitor process (MMNL),You can perform frequent tasks related to lightweight manageability, such as session history capture and metric calculations.
Memory Manager process (Mman),Used for internal database tasks. It manages automatic memory management processing to help dynamically allocate memory when memory is required to avoid low memory or degraded buffer cache performance.Rebalance
process (Rbal)Coordinates the rebalance activity of disk groups in an automated storage management instance. It is responsible for performing a global open operation on the automatic storage management disk.
ARBNPerforms an actual rebalancing of the data area movement in an automated storage management instance. There may be several such processes, named ARB0, ARB1, and so on.
Automatic storage Management process (ASMB)exists in a DB instance that uses the automatic storage Management Disk group. It communicates with the automatic storage Management instance. The job queue process is used for batch processing. They run user jobs and can be treated as scheduler services to dispatch jobs as PL/SQL statements or procedures on an Oracle DB instance.
CJQ0 The coordinator process periodically selects the jobs that need to be run from the System job$ table. The CJQ0 process dynamically derives the job queue dependent process (J000 through J999) to run the job. The job queue process runs one of the jobs that are selected for execution by the CJQ0 process. These processes run one job at a time. The queue monitor process (QMNC) is an optional background process that monitors Message Queuing for Oracle Streams Advanced Queuing. A maximum of 10 queue monitor processes can be configured. Source: http://blog.csdn.net/rlhua/article/details/12232625
