The process of Oracle architecture

The process of Oracle architecture

I. Overview

　　Each process in Oracle performs a specific task (or a set of tasks), and each process allocates its own memory (PGA) to complete its task. An Oracle instance consists of the following 3 types of processes:

(1) server process : Server processes include dedicated servers and shared servers to handle all SQL you submit. When you submit a SELECT * from EMP query to the database, there is an Oracle private/shared server process to parse the query and put it in the shared pool (or it might be better to find that the query is already in the shared pool). The process should make its own query plan (if necessary), then execute it and, if possible, find the necessary data in the buffer cache, or read the data into the buffer cache from disk.

(2) background processes (background process): These processes start with the database and are used to perform various maintenance tasks.

(3) dependent processes (slave process): similar to a background process that does some extra work on behalf of a background process or server process.

Second, the server process

　　(1) Dedicated server connection

With a proprietary server connection, a dedicated process for this connection is obtained on the server. client connections and server processes (or possibly threads) have a one-to-one mapping relationship. Shows the query private server process and the local client process.

　　

(2) Shared Server connection

The shared server connection requirement must use Oracle Net, even if both the client and server are on the same machine. If you do not use an Oracle TNS listener, you cannot use a shared server.

The client app, which links the Oracle library files, is physically connected to a scheduler program. The Scheduler program is only responsible for receiving revenue station requests from the client and placing them in a request queue in the SGA. The first available process in the shared server process pool (which includes some pre-created shared server processes) Gets the request from the queue in turn, with the UGA of the associated session. The shared server process will process the request and put the resulting output in the response queue. The Scheduler program continuously monitors the results in the response queue and passes the results back to the client application.

(3) database resident connection Pool

A Database Resident connection pool (DRCP) is an optional way to connect to a database and establish a session. Some application interfaces themselves do not support efficient connection pooling (such as PHP), and DRCP is a more efficient connection pooling approach designed for this application interface.

Third, the background process

The Oracle instance consists of two parts: the SGA and a set of background processes. As shown in the background process of the database.

(1) Pmon: Process Monitor

The Process monitor is responsible for cleaning up after an abnormally terminated connection, as well as monitoring other Oracle background processes and restarting them if necessary (and possibly).

NOTE: Prior to Oracle DATABASE12C, Pmon is also responsible for handling registered monitoring tasks. Starting with Database 12C, the dedicated Listener Registration Daemon (LREG) is registered to register the instance and service to the listener.

(2) Lreg: Monitoring the registration process

Starting with database 12C, you are responsible for registering your DB instance and service with the listener. When a DB instance is started, the Lreg process will look at the listening port (typically 1521) if a listener is already running on it. We can also explicitly specify the current listening port through the Local_listener parameter, or you can use the Remote_listener parameter to let Lreg register the service to a remote listener.

(3) Smon: System Listener

The work done by Smon includes the following:

1) Clean up the temporary table space;

2) Merge the free table space;

3) for the original non-usable file recovery activities of the transaction;

4) Perform instance recovery of failed nodes in RAC;

5) Clean obj$

6) Manage Withdrawal section

7) Rollback segment offline

(4) RECO: Distributed Database Recovery

Reco's core task: Some transactions may remain in a ready state due to a crash or loss of connection during two-phase commit (2PC). This process is to restore these transactions.

(5) CKPT: Checkpoint Process

Implementing checkpoints is the work of the DBWN process. Ckpt only assists in the process of actually running checkpoints to update the file header of the data file.

(6) Dbwn: Database block writer

The database block writer is the background process responsible for writing dirty blocks to disk. The performance of the DBWN is critical, and if it writes out blocks that are not fast enough to release buffers quickly, you will see both the number of wait times for free buffer waits and the write complete waits and the wait time to start increasing.

In Oracle Database 11g, we can configure up to 36 dbwn processes, and to Database 12C we can configure up to 100 dbwn processes.

In the best case, DBWN uses asynchronous I/O to write blocks to disk. The block writer process writes the blocks to various locations on the disk in a decentralized way, meaning that DBWN performs a large amount of discrete writes. Compared to the sequential write of LGWR, the speed of discrete write is much slower, which is also the necessity of online redo log existence.

(7) LGWR: Log writer

The LGWR process is responsible for flushing the contents of the Redo log buffers in the SGA to disk. LGWR is written sequentially, writing only the changed bytes to disk. There are three conditions for triggering a write operation on LGWR:

1) every three seconds;

2) when a commit or rollback is initiated;

3) LGWR is notified when the log file is switched;

4) Redo Log buffer is 1/3 full, or already contains 1MB of buffered data.

(8) ARCn: Archive process

ARCN the task of the process: When LGWR fills an online redo log file, it copies it to another location. These archived redo log files can then be used to complete the media recovery. The online redo log is used to "remediate" data files when power-down (instance termination) occurs, while archived redo log files are used for "remediation" data files in the event of a disk failure.

(9) DIAG: Diagnostic process

With ADR (Advanced Diagnostics Library, Advance Diagnostic Repository), it is responsible for monitoring the overall condition of the instance and capturing the information needed to process the instance failure. This applies both to a single instance configuration and to a multi-instance RAC configuration.

FBDA: Flash back Data archive process

The Flashback data archive function refers to data that can be flashed back to a query (as of query) long ago. This long-term historical query function is achieved by maintaining a record of the history of a row, that is, recording data changes for each row in a table. FBDA is responsible for maintaining this history.

(one) DBRM: Database Explorer Process

The DBRM process implements the resource plan that is configured for a DB instance. It sets the specified resource plan and performs the various actions involved to implement/implement these resource plans. The resource Manager allows the database administrator to fine-grained control over the resources used by the DB instance, the resources used to access the database, or the resources used by individual users to access the database.

(GEN0): Common task Execution process

The generic task execution process provides a process for the database to perform common tasks. The evil of this process is as long as the goal is to share some of the processes that may cause process blocking (these processes cause a process to stop) and put them in the background.

(13) Some other processes

Iv. Tools Background Process

These background processes are optional. The following are some common possible processes to encounter:

(1) CJQ0 and jnnn processes: Job queue

The job queue process monitors a job table, which tells it when to refresh individual snapshots in the system.

(2) QMNC and qnnn: Advanced Queue

The QMNC process monitors the advanced queues and reminds them to be out of the queue when a waiting message becomes available.

(3) EMNC: Event Monitor process

The EMMC process is part of the advanced queue architecture that notifies the queue to subscribe to messages that are of interest to them.

(4) Mman: Memory Manager

This process exists in Oracle Database 10g and above and is used to automatically set the SGA size. The Mman process is responsible for the size and sizing of each shared memory component, including the default buffer pool, shared pool, Java pool, and large pool.

(5) Mmon, MMNL and mnnn: Manageability Monitor

These processes are used to populate the automatic Workload repository (AWR) with information. The MMNL process will dispatch various statistics to the SGA flush output to the database table. The Mmon process is used to automatically monitor database performance issues and implement self-tuning capabilities. The mnnn process is similar to the jnnn or qnnn process of the job queue.

(6) CTWR: Modify the tracking process

The CTWR process is responsible for maintaining the modified trace file.

(7) RVWR: Resume writer

When you use the Flashback Database command, it is responsible for maintaining the "front" image of the block in the fast recovery area.

(8) DMNN/DWNN: Data pump main process/work process

The data pump master process (DMNN) collects all input from the client process and then coordinates the work process (DWNN) to perform the specific work, dmnn the process to complete the metadata and data processing.

(9) tmon/tt00: Transport monitor and redo transfer slave process

The two data guard related processes in Oracle database 12c start with the start of a DB instance. Tmon will start and monitor a certain number of TT00 processes. The TT00 process is used to notify the LGWR process to generate a heartbeat redo.

(10) Other work background process

V. Subordinate processes

(1) I/O dependent process

The I/O dependent processes are used to emulate asynchronous I/O on systems and devices that do not support asynchronous I/O, such as tape devices. The I/O dependent processes wait for slow devices, and the process that calls them is freed up to do other important work: collect the next data to be written.

There are two parameters that control the use of the I/O dependent processes:

1) Backup_tape_io_slaves: Specifies whether Rman uses an I/O dependent process to back up, copy, or restore data to tape, which is set for tape devices. When this value is true, a tape device is read and written using an I/O subordinate process, and when this value is False, the dedicated server process used to perform this part directly accesses the tape device.

2) Dbwr_io_slaves: Specifies the number of I/O dependent processes used by the DBW0 process. If the value is a non-0 value, LGWR and ARCN also use their own I/O dependent processes.

The name of the dbwn I/O dependent process is the name of the I1NN,LGWR I/O subordinate process I2NN.

(2) PNNN: Executing query server in parallel

For SQL statements such as SELECT, create TABLE, create INDEX, update, and so on, create an execution plan that contains multiple (sub) execution plans that can be executed concurrently. Merging the output of each execution plan together constitutes a larger result, with the goal of doing the same work in a fraction of the time required to perform this operation serially.

Before Oracle database 12C, the default number of parallel execution servers was 0, we could modify it by modifying the parallel_min_servers parameter value, which defaults to 0, and at Oracle database 12C, PARALLEL_ The Min_servers default value has been set to a value other than 0 (according to Cpu_count * PARALLEL_THREADS_PER_CPU * 2).

The process of Oracle architecture