Purpose of SMON Process

The System Monitor Process, commonly denoted as SMON, is an indispensable background process in an Oracle Database instance, serving multiple vital functions that pertain to instance recovery, space management, and overall database health. This process is automatically initiated upon the startup of an Oracle Database instance and operates throughout the lifetime of that instance, contributing significantly to database integrity, reliability, and optimal performance.

1. Instance Recovery: In the event of a system failure or abrupt database shutdown, SMON plays a crucial role in instance recovery. It performs transaction recovery by rolling back uncommitted transactions and rolling forward committed transactions that were not yet written to the data files. This ensures database consistency, thereby maintaining the integrity of the data.
2. Temporary Segment Cleanup: SMON is tasked with reclaiming space occupied by temporary segments that are no longer needed, typically those associated with temporary tables and sorts. This contributes to more efficient space utilization and better database performance.
3. Coalescing Free Space: In fragmented tablespaces, SMON automatically coalesces adjacent free extents into larger, contiguous free extents. This operation is vital for optimal space management, especially in databases employing dictionary-managed tablespaces.
4. Monitoring Distributed Transactions: SMON also oversees the resolution of pending distributed transactions that could be in-doubt due to network failures or other issues affecting a distributed database setup.
5. Deadlock Resolution: Although not a primary function, SMON assists in resolving lock conflicts and deadlocks, particularly in Real Application Clusters (RAC) environments. It detects and resolves these conflicts to facilitate the smooth continuation of database operations.
6. Buffer Cache Monitoring: SMON indirectly contributes to the management of the buffer cache. While it doesn’t directly handle cache operations, its auxiliary functions can influence the effectiveness of buffer cache utilization.
7. Purging Materialized Views: SMON is responsible for the removal of materialized views that are flagged for purging, either because they are stale or have been manually designated for removal. This operation ensures the freshness of the data and the efficiency of query operations.
8. Segment Advisor: SMON works in conjunction with the Automatic Segment Advisor to identify segments that would benefit from online segment shrink or table reorganization. It thereby assists in making recommendations for optimizing space utilization.

Given its multi-faceted role, SMON is integral to Oracle Database's robustness and resilience. It is a cornerstone process that facilitates the seamless functioning of database operations, mitigates disruptions caused by system failures, and optimizes space for enhanced performance. Database administrators should have a comprehensive understanding of SMON’s functions as it is pivotal for both routine maintenance and contingency planning in Oracle Database management.

Multiple sessions can exist concurrently for a single database user. As shown in the following figure, user one can have multiple connections to a database. In dedicated server connections, the database creates a server process on behalf of each connection. Only the client process that causes the dedicated server to be created uses it. In a shared server connection, many client processes access a single shared server process.

The System Monitor (SMON, pronounced “ess-mahn”) process is responsible for:

1. Instance crash recovery
2. Cleaning up temporary segments
3. Coalescing free spaces

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:

1. 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.
2. 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.
3. 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.
4. 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.

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.

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 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.