Oracle architecture (3)
Server Processes and backend processes server processes and backend processes are also two different concepts. server processes are also called front-end processes and are responsible for connecting to the Client on the oracle server. Every time a user process is generated on the clinet end to connect to the database, the database will generate the corresponding server process and port number to connect to it. In the dedicated server, this is a one-to-one relationship, in the Shared Server, the scheduler is used. Background processes are part of an instance. When the instance is started, SGA is allocated, background processes are also allocated, and memory (PGA) is allocated ), the background process implements operations on the oracle server. For example, similar to the workers working on the construction site, the division of labor is clear. Background processes only occupy a small portion of the PGA. Strictly speaking, the PGA has been allocated a portion when the instance is started (only a small proportion ), most of the rest are allocated when the user connects, because most of the PGA is allocated to the server process that connects the customer. The background process has been briefly described before. Next, we will give a brief introduction to common background processes: SMON: resume when the instance is started (if needed ), it is also responsible for identifying the temporary segments temporarily unavailable. SMON regularly checks whether the process is required. Other processes can also call SMON as needed. PMON: Process recovery when the user process fails (in my understanding, it is to clear all information about the user process): 1. clear buffer cache; 2. releases all resources occupied by the user process. PMON is also responsible for monitoring whether idle sessions have timed out and dynamically listening database services to the listener. PMON automatically re-enables any scheduling program and server processes that have stopped running. (Mainly manages server processes) DBWn: writes the modified data in the buffer cache to the data file. There are two ways to write data to a disk: 1. asynchronous write (write a part first) when other processing is executed; 2. Regular execution to promote the checkpoint. Dirty blocks can be written back in the following situations: 1. Global checkpoints; 2. Database shutdown; 3. drop tables; and offline tablespace. LGWR: the role of this process is relatively simple and easy to understand. LGWR writes the cache information in the redo log buffer to the redo log file, LGWR will be triggered in the following conditions: 1. redolog buffer is occupied by 1/3; 2. switch log files. 3. every 3 s; 4. before DBWn writes dirty block to the data file; 5 user commit transaction processing; 6. redo log buffer occupies 1 MB. CKPT: writes the checkpoint information to the control file and each data file header. When the system initiates a global checkpoint, it will notify DBWn to write all the dirty blocks back to the data file. If a large number of dirty blocks are accumulated, this will be a huge workload for DBWn. To reduce this workload and reduce the number of dirty blocks to be restored through redolog during instance recovery, to reduce the instance recovery time, incremental checkpoints are introduced. When an incremental checkpoint is initiated, only operations on the control file are performed. CKPT regularly triggers DBWn. CKPT notifies DBWn to write the dirty block in the check point queue back to the data file, which reduces the workload of DBWn and improves io efficiency. Oracle architecture understanding (3) Full checkpoints can be manually triggered (execute Alter system checkponit;), and will also be triggered under switching logs, shutdown immediate, and other conditions. RECO: used for Distributed Database Configuration. There are still many background processes. Here we will briefly introduce several common ones. Many processes have relatively complex functions and require more in-depth understanding and exploration of the architecture.