Oracle 核心後台進程揭秘：SMON 與 ARCH 的關鍵作用與調優策略

SMON（System Monitor）：碎片整理與實例恢復雙重衛士

核心職責

1. 表空間碎片合併：定期喚醒，掃描各表空間空閒塊，合併相鄰空閒區塊（Coalesce），提升空間分配效率，防止 ORA-01652/01653。
2. 實例恢復：實例異常終止（斷電、崩潰）後重啟時，自動讀取聯機重做日志，前滾已提交事務（重做日志有、數據文件無），回滾未提交事務（Undo 段還原），保證數據庫一致性打開。

管理關鍵點

• 喚醒機制：實例啟動自動啟動 → 定期內部喚醒檢查工作 → 手動觸發（如 ALTER SYSTEM SET EVENTS 'IMMEDIATE TRACE NAME COALESCE LEVEL 1' 強制合併）。
• PCTINCREASE 參數陷阱：字典管理表空間（DMT）中，若 PCTINCREASE=0，SMON **不再**自動合併該表空間碎片，需手動 ALTER TABLESPACE ... COALESCE 或導出導入重組。建議：除非極特殊原因，保持 PCTINCREASE > 0（如默認 50），或遷移至本地管理表空間（LMT）徹底解決。
• 不影響恢復：即使 PCTINCREASE=0，實例恢復功能完全正常。

ARCH（Archiver）：歸檔日志的搬運工與性能隱形殺手

觸發條件

僅在 ARCHIVELOG 模式下啟動。LGWR 切換日志組時，若目標組未歸檔，數據庫**掛起**等待 ARCH 完成複製，然後繼續。

性能影響鏈

大批量 DML → 大量 Redo → 頻繁日志切換 → 高頻 ARCH 啟動 → I/O 爭用 + 數據庫周期性掛起 → 整體吞吐下降。

三大調優策略

對比：ARCH vs DBWR 並行度限制

• DBWR 進程數受限於 CPU 核心數（1 進程綁 1 核）。
• ARCH 進程**不受 CPU 核心限制**，單核也可運行多個 ARCH 進程（I/O 密集型，CPU 佔用低）。

總結

SMON 與 ARCH 雖非前台核心進程，但直接決定空間健康度與恢復能力/寫入吞吐。DBA 應將其納入常規巡檢：監控碎片合併狀態、歸檔延遲、日志切換頻率，並掌握大載入場景下的臨時調優手段。