Shulou(Shulou.com)05/31 Report--

This article shows you what the functions of PMON, SMON, DBWR and LGWR are. The content is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

PMON process: this process performs process recovery when the user process fails and is responsible for cleaning up the memory area and releasing the resources used by the process. Example: it resets the state of the active transaction table, releases the blockade, and removes the ID of the failed process from the active process table. PMON also periodically checks the status of the scheduling process (DISPATCHER) and server processes and, if dead, restarts (excluding processes that are intentionally deleted).

PMON is regularly woken up to check if it is needed, or other processes can be called when they find it.

The PMON process is also responsible for cleaning up after abnormally broken connections. For example, if a dedicated service "fails" or is dropped by kill for some reason, PMON is responsible for handling (restoring or rolling back work) and releasing your resources. PMON will issue a rollback of uncommitted work, release locks, and release SGA resources allocated to the failed process.

In addition to cleaning up after an exception interrupt, PMON monitors other oracle background processes and restarts them if necessary (and possible). If the shared service or one allocator fails (crashes), PMON will step in and restart the other (after cleaning up the failed process). PMON will observe all Oracle processes, as long as appropriate or restart them or abort the process. For example, in the database log write process event, LGWR failure, instance failure. This is a serious error, and the safest way to deal with it is to terminate the instance immediately and let the normal recovery process the data. Note that this is a rare occurrence and should be reported to oracle support immediately.

Another thing PMON does for the example is to register with the Oracle TNS listener. When an instance is turned on, the PMON process throws a well-known port address unless it points to something else to see if the listener is open and running. It is well known / the default port is to use 1521. Now, what happens if the listener is turned on on some different ports? In this case, the mechanism is the same, except that the listener address needs to be explicitly specified by the LOCAL_LISTENER parameter. If the listener is running when the library instance is turned on, the PMON communicates with the listener and passes its relevant parameters, such as the server name and the load measurement of the instance. If the listener is not turned on, PMON will periodically try to contact it to register itself.

SMON process: this process performs instance recovery when the process instance starts, and is also responsible for cleaning up temporary segments that are no longer in use. In an environment with a parallel server option, SMON performs instance recovery on a failed CPU or instance. SMON processes are regularly woken up to check if they are needed, or other processes can be called when they find they need them.

SMON is also responsible for all system-level work. In contrast to PMON's interest in a single process, SMON is a system-level view, a "garbage collector" for libraries. The work it does includes the following seven items:

1 cleaning up temporary tablespaces: with the emergence of this "real" temporary tablespace, the chores of cleaning up temporary tablespaces have been reduced, but it has not completely disappeared. For example, when an index is created, the extent assigned to the index during creation is marked TEMPORARY. If the Create Index session is abnormally interrupted for some reason, SMON is responsible for cleaning them up. SMON is also responsible for temporary extents created by other operations.

2 join free space: if you are using a data dictionary to manage tablespaces, SMON is responsible for joining extent that are idle in the tablespace and are adjacent to each other into a larger free extension. This occurs only in dictionary-managed tablespaces with storage clauses with the default pctincrease set to non-zero.

3 restore transactions for unavailable files to active state: its role is similar to that during library startup. At this point, because files are not available for recovery, SMON restores failed transactions that were skipped during instance / crash recovery. For example, the file may already be on a disk that is not available or mounted. When the file becomes available, SMON will restore it.

4 perform instance recovery of a failed node in RAC: in an oracle RAC configuration, when a library instance in the cluster fails (for example, the machine that the instance is running fails), other nodes in some clusters will open the redo log file of the failed instance and perform the recovery of all data for the failed instance.

5 Clean OBJ$:OBJ$ is a row-level data dictionary table that contains records for almost every object in the library (tables, indexes, triggers, views, etc.). Many times, records that exist here represent deleted objects, or objects that are not here, and are used in oracle's trust mechanism. SMON is the process of deleting lines that are no longer needed.

6 shrink rollback segment: SMON will perform automatic contraction of the rollback segment to its optimal size if it is set.

7 "offline" rollback segment: for DBA, it is possible to make a rollback segment with active transactions offline or unavailable. It is possible that Active transactions are using this offline rollback segment. In this case, the rollback is not really offline; it is marked "hanging offline". In the background process, SMON will periodically try to make it really offline until it succeeds. It does many other things, such as the washing of monitoring statistics in the DBA_TAB_MONITORING view, the SCN washing of the timestamp positioning information found in the SMON_SCN_ time table, and so on. It should be considered normal that SMON can consume a lot of CPU during this period. SMON periodically wakes up (or is woken up by other background processes) to perform these housekeepers' household chores.

DBWR process: this process performs writing buffers to a data file and is an ORACLE background process responsible for managing the buffer store. When a buffer in the buffer is modified and it is marked as "dirty", the main task of DBWR is to write the "dirty" buffer to disk to keep the buffer "clean". The number of unused buffers is reduced because the buffers of the buffer store are filled into the database or soiled by user processes. When the number of unused buffers drops to so few that the user process cannot find the unused buffer when it wants to read blocks from disk to the memory store, DBWR manages the buffer so that the user process can always get the unused buffer.

ORACLE uses the LRU (LEAST RECENTLY USED) algorithm (the least recently used algorithm) to keep blocks in memory recently used, minimizing Imax O. Indicates that DBWR will write a dirty buffer to disk in the following situations:

1. When a server process moves a buffer into the "dirty" table, the dirty table reaches the critical length.

The service process notifies DBWR to write. The critical length is the parameter DB-BLOCK-WRITE-BATCH

Half of the value of.

2. When a server process looks for a DB-BLOCK-MAX-SCAN-CNT buffer in the LRU table, no

If an unused buffer is found, it stops looking and tells DBWR to write.

3. If a timeout occurs (3 seconds at a time), DBWR will notify itself.

4. When a checkpoint occurs, LGWR will inform DBWR that in the first two cases, DBWR will write the blocks in the dirty table to disk, and the number of blocks that can be written each time is specified by the initialization parameter DB-BLOCK-WRITE-BATCH. If there is no buffer in the dirty table for the number of blocks specified by this parameter, DBWR looks for another dirty buffer from the LUR table. If DBWR is not active within three seconds, a timeout occurs. In this case, DBWR looks for a specified number of buffers on the LRU table and writes any dirty buffers found to disk. Whenever a timeout occurs, DBWR looks for a new buffer group. The number of buffers looked up by DBWR each time is twice the value of the sleeping parameter DB-BLOCK-WRITE-BATCH. If the database is empty, DBWR eventually writes the entire buffer store to disk. When a checkpoint occurs, LGWR specifies that a modified buffer table must be written to disk. DBWR writes the specified buffer to disk.

On some platforms, an instance can have multiple DBWR. In such an example, some blocks can be written to one disk, while others can be written to other disks. The parameter DB-WRITERS controls the number of DBWR processes.

LGWR process: this process writes the log buffer to a log file on disk, which is an ORACLE background process responsible for managing the log buffer. The LGWR process outputs all log entries since it was last written to disk, LGWR output:

1. Write a commit record when the user process commits a transaction.

2. Output the log buffer every three seconds.

3. Output the log buffer when the log buffer is full.

4. When DBWR writes the modification buffer to disk, it outputs the log buffer.

The LGWR process writes synchronously to the active mirror online log filegroup. If a file in a group is deleted or unavailable, LGWR can continue to write to other files in that group.

The log buffer is a circular buffer. When LGWR writes the log entries of the log buffer to the log file, the server process can write new log entries to the log buffer. LGWR usually writes quickly, ensuring that there is always room in the log buffer to write new log entries.

Note: sometimes when more log buffers are needed, LWGR writes out log entries before a transaction commits, and these log entries are made permanent only after a later transaction commits.

ORACLE uses a fast commit mechanism, where when a user issues a COMMIT statement, an COMMIT record is immediately put into the log buffer, but the corresponding data buffer changes are delayed until they are written to the data file when it is more efficient. When a transaction commits, it is assigned a system modification number (SCN), which is recorded in the log together with the transaction log entry. Because the SCN is recorded in the log, restore operations can be synchronized when the parallel server option is configured.

What are the functions of PMON, SMON, DBWR and LGWR? have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.