Purpose of the SMON Process
The System Monitor (SMON, pronounced “ess-mahn”) process is responsible for:
- Instance crash recovery
- Cleaning up temporary segments
- Coalescing free spaces
Remember that Oracle buffers data in the SGA, and does not necessarily write out changes to the datafiles immediately after they occur. If the instance crashes, any changes buffered in memory are lost.
Whenever you start an Oracle instance, SMON checks to see if it has previously crashed. If it has, then SMON reads the redo log files, and applies any needed changes to the datafiles.
Cleaning up temporary spaces
Temporary segments are often used for sorting. When a sort finishes, SMON takes care of deallocating any segments used for that sort.
Coalescing free space
Coalescing free space refers to the practice of taking two adjacent areas of free space with a datafile and converting them into one larger area of free space. This procedure is repeated over and over in order to minimize fragmentation in the files.
System Monitor Process (SMON)
The system monitor process (SMON) performs recovery, if necessary, at instance startup. SMON is also responsible for cleaning up temporary segments that are no longer in use and for coalescing contiguous free extents
within dictionary managed tablespaces. If any terminated transactions were skipped during instance recovery because of file-read or offline errors, SMON recovers them when the tablespace or file is brought back online.
SMON checks regularly to see whether it is needed. Other processes can call SMON if they detect a need for it. With Real Application Clusters, the SMON process of one instance can perform instance recovery for a failed CPU or instance.
The system monitor process (SMON) is in charge of a variety of system-level cleanup duties. The duties assigned to SMON include:
- Performing instance recovery, if necessary, at instance startup. In an Oracle RAC database, the SMON process of one database instance can perform instance recovery for a failed instance.
- Recovering terminated transactions that were skipped during instance recovery because of file-read or tablespace offline errors. SMON recovers the transactions when the tablespace or file is brought back online.
- Cleaning up unused temporary segments. For example, Oracle Database allocates extents when creating an index. If the operation fails, then SMON cleans up the temporary space.
- Coalescing contiguous free extents within dictionary-managed tablespaces.
SMON checks regularly to see whether it is needed. Other processes can call SMON if they detect a need for it.