Background process for Oracle instances _oracle

Here are some of the hard working processes in the background. System Monitor,smon, Progress Monitor (process Monitor,pmon), database writer (db writer,dbwn), log recorder (logs WRITER,LGWR), Checkpoint process (Checkpoint process,ckpt)

1, Smon: Install and open the database. Install the database by locating and validating the database control files. After that, you open the database by locating and validating all data files and online log files. Once the database is open and the database is in use, Smon is responsible for performing various internal management tasks.

2. Pmon: User session is the user process that connects to the server process. The server process starts when the session is created and is destroyed at the end of the drawing. If the session ends normally, any work performed by the user will be completed in an orderly manner, and the server process will terminate. If the session is not terminated properly, Pmon destroys the server process, returns its PGA memory to the operating system, and rolls back any uncommitted transactions that are still in progress.

3, DBWN: The session does not write data directly to the disk, but writes to the database cache area. The database writer is then responsible for writing the buffer to disk. In general, an instance may have more than one writer. In order, DBW0,DBW1 and so on. By default, 8 CPUs correspond to a database writer.

In general, Oracle reduces the number of write buffers as much as possible. Because IO operations can degrade performance. In the real world, if a session does write to some buffers, then there is usually a session that operates on it. In this way, there is no need to write it to disk.

DBWN uses an extremely lazy algorithm to execute writes: as little as possible, in as little as possible. There are four things you need to do: There are no buffers available, too many dirty buffers, three seconds to timeout, and checkpoints to run into.
No buffer available: The server process needs to find an available buffer before copying the block to the buffer zone. The available buffers are neither dirty nor occupied buffers. If you look for an available buffer that is too long (which is set internally by Oracle), the dirty buffer is written to disk to clean up the buffer.

Excessive number of dirty buffers: In what case is more, Oracle's internal threshold is determined, if it is exceeded, some buffers will be written to disk

Three-second timeout: Dbwn clears some buffers once every three seconds. The buffer is cleaned even when the system is idle.
Request checkpoint: All buffer data is written when the checkpoint is encountered. The system performance is degraded at this time. Checkpoints are set only if they are forced to do so. You set up checkpoints when you close the database and close the instance, or you can use commands to set it.
It is important to note here that when a session commits a transaction, DBWN does nothing and DBWN executes it in its own way. The action to be performed at this point is to write data to the log buffer.

4. LGWR: Log Recorder writes the contents of the log buffer to the online log file on disk. When a commit is made by a session, LGWR writes in real time: The session will be suspended when LGWR writes the buffer to disk. In Oracle architecture, LGWR is one of the biggest bottlenecks. DML cannot be faster than the speed at which LGWR changes the vector to disk. LGWR dumps the log buffers when three of the following conditions occur:

Commit write: Each change vector for a committed transaction can be obtained from the redo log on the disk and can then be applied to the data file backup.

The log buffer occupancy rate is 1/3: In an application, it is usually possible to fill 1/3 of the log buffer in a very short time, forcing LGWR to change the vector to write to disk in real time. Since then, when a commit occurs in a session, there is little to write about: A commit can be completed immediately.

Dbwn need to write a dirty buffer from the database cache to the data file: The LGWR write operation will always be performed before DBWN performs a write operation. The purpose is to always reverse uncommitted transactions. DBWN may write uncommitted transactions to the data file, and if you can get the data needed to reverse the transaction and change the vector, this does not cause problems. Therefore, before Dbwn executes the write, a LGWR write is required to ensure that the data is entered in the Redo log file.

5. CKPT: After the system crashes, all the 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 dirty buffers can be quickly written to disk, minimizing the amount of redo that must be applied after a crash occurs. After Oracle8i, an incremental checkpoint mechanism is used to write out the dirty buffer dbwn at a fixed rate, so there is always a predictable gap between Dbwn and LGWR. With incremental checkpoints, system performance is more stable and recovery time is predictable.

Of course, after 10g, Oracle has added several more processes, here is a brief introduction:
Mmon: Management monitor (Maniageability Monitor), data block self-monitoring and self tuning support process.
The Mmnl:mmon worker process.
Mman: Supports automatic adjustment of memory distribution.