| Pmon: Process Monitoring process
The process is responsible for cleanup after an abnormally interrupted connection. For example, if a dedicated service "fails" or is killed for some reason, Pmon is responsible for handling (resuming or rolling back work) and releasing your resources. Pmon will issue a rollback of uncommitted work, release the lock, and release the SGA resource assigned to the failed process.
In addition to cleanup after an exception outage, Pmon monitors other Oracle daemon processes and restarts them if necessary (and possible). If a shared service or a allocator fails (crashes), Pmon will intervene and reboot another (after the failure process is cleaned up). Pmon will observe Oracle processes as long as they are appropriate or restart them or abort the process. For example, in database log write process events, LGWR failures, instance failures. This is a serious mistake, the safest way to do this 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 immediately to Oracle support).
Another thing Pmon does for instance is to register with Oracle TNS listeners. When an instance is turned on, the Pmon process casts a well-known port address, unless pointing to the other, to see if the listener is running and operating. Known/default port is to use 1521. Now, what happens if the listener opens 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 open, the Pmon communicates with the listener, passing it the relevant parameters, such as the server name and the load metric for the instance. If the listener is not turned on, Pmon will periodically try to contact it to register itself. Smon: System Monitoring
Smon is responsible for doing all the system-level work. Relative 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 7 pieces:
• Clean up temporary tablespaces: the chore of cleaning up temporary tablespaces has been mitigated by the presence of this "real" temporary tablespace, but it's not completely gone. For example, when an index is established, the extents assigned to the index during creation are marked as temporary. If the CREATE index session is abnormally interrupted for some reason, Smon cleans them. The temporary extension area created by other operations, Smon will also be responsible.
L JOIN the free space: If you are using a data dictionary to manage the tablespace, Smon is responsible for synthesizing a large free expansion area of the extent that is idle in the tablespace and is adjacent to each other. This occurs only in the Dictionary management table space with a default pctincrease set of storage clauses that are non-zero.
L restores a transaction to an unusable file to an active state: its role is similar to that during library startup. At this point, because the file cannot be used for recovery, Smon restores the failed transaction that was skipped during instance/crash recovery. For example, a file might already be on a disk that is not available or is not mounted. When the file becomes available, Smon restores it.
L Perform an instance recovery of a failed node in a RAC: in an Oracle RAC configuration, when one of the library instances in the cluster fails (for example, the machine being executed by the instance fails), some other nodes in the cluster will open the Redo log files for the failed instance and perform all data recovery for the failed instance.
L Cleanup obj$:obj$ is a row-level data dictionary table that contains records for almost every object (table, index, trigger, view, and so on) in the library. Many times, the records present here represent deleted objects, or objects that are not here, are used in Oracle's trust mechanism. Smon is the process of removing these rows that are not needed.
L Shrink Rollback segment: Smon will perform automatic contraction of the rollback segment to its optimal size if it is set.
L "Offline" rollback segment: It is possible for a DBA to have a rollback segment with an active transaction offline or unavailable. It is possible that an active transaction is using this offline rollback segment. In this case, the rollback is not really offline; it is marked as "Hanging offline." In the background process, Smon will periodically try to make it truly offline until it is successful.
That should give you a taste of Smon. It does many other things, such as the scrubbing of monitoring statistics in the dba_tab_monitoring view, the SCN of the timestamp location information found in the Smon_scn_time table, and so on. Smon can consume a lot of CPUs during the period, which should be considered normal. Smon periodically wakes (or wakes up by other background processes) to perform the housekeeping chores. |
