System Monitor (SMON): Instance Recovery and Housekeeping

SMON (System MONitor) is a permanent Oracle background process that protects database consistency and performs periodic cleanup. It runs automatically from instance startup to shutdown and can be invoked on demand when recovery or cleanup is needed.

What SMON actually does

• Instance crash recovery at startup - Applies redo (roll forward) to bring datafiles to the last consistent SCN, then rolls back uncommitted work to restore transactional consistency.
• Cleanup of orphaned temporary segments - Reclaims temp extents left behind by failed sessions or aborted operations (e.g., sorts, index builds that did not complete).
• Recovery of skipped work - If some transactions were deferred during startup due to offline files/tablespaces, SMON completes their recovery once those files/tablespaces return online.
• RAC instance recovery - In Oracle RAC, the SMON of a surviving instance may perform recovery for a failed instance.

What SMON does not do (common misconceptions)

• Distributed transactions - Handled by RECO (recovery) for in-doubt distributed transactions, not SMON.
• Deadlock detection - Detected and resolved by the lock manager during statement execution; not a SMON duty.
• Buffer cache “monitoring” - Cache management is automatic (server process + DBWn/LGWR/CKPT). SMON does not tune cache contents.
• Materialized view “purging” or Segment Advisor - Automated advisors and autotasks (MMON/MMNL + Scheduler) handle these; not SMON.
• Coalescing free extents in modern tablespaces - With Locally Managed Tablespaces (LMT) and ASSM, extent management is bitmap-driven and does not rely on SMON coalesce. (Historical note below.)

Crash recovery: the fast path

1. Roll forward: Read online redo (and, if needed, archived redo) to apply committed changes to datafiles.
2. Open with RESETLOGS? Only in media-recovery scenarios; typical instance recovery does not require this.
3. Transaction rollback: Uncommitted work is rolled back using transaction tables/undo to guarantee read consistency.

Temporary-space cleanup

Temp segments are used for sorts, hash joins, and index creation. Normally they are released when a session finishes; SMON performs periodic sweeps to reclaim any orphaned temp extents left by failures.

Observability and quick checks

Use these checks to understand recovery targets and activity. (Replace view names as appropriate for your exact version.)

-- Target recovery window (seconds)
SHOW PARAMETER fast_start_mttr_target;

-- Estimated MTTR (seconds)
SELECT estimated_mttr
FROM   v$instance_recovery;

-- Recent temp usage by sessions (current, not historical)
SELECT s.sid, s.serial#, u.tablespace, u.blocks, u.segtype
FROM   v$session s
JOIN   v$tempseg_usage u ON s.saddr = u.session_addr
ORDER  BY u.blocks DESC;

Modernization notes (historical vs. current behavior)

• Dictionary-Managed Tablespaces (DMT): Historically, SMON could coalesce contiguous free extents in DMT. Modern Oracle deployments should use LMT + ASSM; coalescing by SMON is no longer a normal requirement.
• Space shape vs. size: For large, hot objects, prefer Keep/Recycle pools and appropriate indexing/partitioning over manual “coalescing” tactics.

Practical guidance

1. Keep FAST_START_MTTR_TARGET aligned with business RTOs; verify with V$INSTANCE_RECOVERY.
2. Use LMT + ASSM for all tablespaces; avoid legacy DMT content and guidance.
3. Investigate frequent instance recovery (alert log/AWR). Address root causes (I/O, OS restarts, storage timeouts) rather than tuning SMON.
4. For distributed TXNs, monitor DBA_2PC_PENDING/DBA_2PC_NEIGHBORS and ensure RECO is healthy.