Background process of the ORACLE instance

The following describes the hard-working processes in the background. System Monitor (SMON), Process Monitor (PMON), Database Writer (DBWn), Log Writer (LGWR) checkpoint Process (CKPT)

1. SMON: Install and open the database. Install the database by searching and verifying the Database Control File. Then, open the database by searching and verifying all data files and On-line log files. Once the database is opened and the database is in use, SMON is responsible for executing various internal management tasks.

2. PMON: user sessions are user processes that connect to server processes. The server process is started when the session is created and destroyed when the painting ends. If the session ends normally, all work performed by the user will be completed in an orderly manner, and the server process will be terminated. If the session is terminated abnormally, PMON will destroy the server process, return its PGA memory to the operating system, and roll back any ongoing unfinished transactions.

3. DBWn: The session does not directly write data to the disk, but to the database cache. Then the database writer writes the buffer to the disk. Generally, an instance may have multiple writers. DBW0 and DBW1. By default, eight CPUs correspond to one database writer.

Generally, Oracle will minimize the number of buffer writes. Because IO operations will reduce performance. In reality, if a session writes to some buffers, it will usually be operated by the session. In this way, there is no need to write it to the disk.

DBWn uses a very lazy algorithm to execute writing: as few as possible, as few as possible. In four cases, you need to perform the following operations: no available buffer, too many dirty buffers, three seconds of timeout, and checkpoints.
No available buffer zone: Before a server process copies a block to a high-speed buffer zone, it needs to find the available buffer zone. The available buffer zone is a buffer zone that is neither dirty nor occupied. If it takes too long to find the available buffer (set internally by Oracle), the dirty buffer is written to the disk to clear the buffer.

The number of dirty buffers is too large: Under what circumstances is the number of dirty buffers determined by the internal Oracle threshold. If the number of dirty buffers exceeds, some buffers will be written to the disk.

Three-second Timeout: DBWn clears some buffers every three seconds. The buffer is cleared even if the system is idle.
Request checkpoint: When a Check Point is encountered, all the buffer data will be written. At this time, the system performance is reduced. Check Points are set only when they are not required. When the database is shut down or the instance is shut down, a checkpoint is set. You can also set the checkpoint by using commands.
Note that DBWn does not do anything when a session commits a transaction, and DBWn executes it in its own way. In this case, the operation is to write the data in the log buffer.

4. LGWR: the log writer writes the content in the log buffer to the online log file on the disk. When the session sends a COMMIT, LGWR writes data in real time: When LGWR writes the buffer to the disk, the session will be suspended. In the Oracle architecture, LGWR is one of the biggest bottlenecks. The speed of DML cannot exceed the speed at which LGWR writes the modified vector to the disk. In the following three cases, LGWR dumps the log Buffer:

When writing: Each Change vector of the committed transaction can be obtained in the redo log on the disk, and can then be applied to data file backup.

The log buffer usage reaches 1/3: in applications, 1/3 of the log buffer can be filled in very short time. In this case, LGWR is forced to write the Change vector to the disk in quasi-real time. After that, when a COMMIT occurs in a session, there is almost no content to write: COMMIT can be completed immediately.

When DBWn needs to write the dirty buffer from the database cache area to the data file: Before DBWn performs the write operation, it will always perform the LGWR write operation. Objective: To always reverse uncommitted transactions. DBWn may write uncommitted transactions into the data file. If you can obtain the data required by the transaction and change the vector, this will not cause problems. Therefore, before DBWn writes data, LGWR writes must be executed to ensure that the data enters the redo log file.

5. CKPT: After the system crashes, all change vectors corresponding to the dirty buffer must be extracted from the redo log and applied to the data block. This is the recovery process. Frequent Checkpoints ensure that the dirty buffer can be quickly written to the disk to minimize the number of retries that must be applied after a crash. After Oracle8i, the incremental checkpoint mechanism is adopted. DBWn writes dirty buffers at a fixed rate. Therefore, there is always a foreseeable gap between DBWn and LGWR. When incremental check points are used, the system performance is more stable and the recovery time is predictable.

Of course, after 10 Gbit/s, Oracle has added several new processes. Here is a brief introduction:
MMON: Maniageability Monitor, a data block self-monitoring and self-adjusting support process.
MMNL: the auxiliary process of MMON.
MMAN: Supports automatic adjustment of memory distribution.