Oracle 後台進程深度解析：SMON 整理碎片與崩潰恢復、ARCH 歸檔機制

Oracle 實例啟動後會啟動多個後台進程，其中 SMON (System Monitor) 與 ARCH (Archiver) 雖體量小，卻關鍵影響資料安全與效能。本文深度解析兩者運作機制、參數控制與調優建議。

SMON (System Monitor) - 系統監視進程

核心職責

1. 整理表空間碎片：合併相鄰空閒區塊，提升程度分配效率。
2. 執行個體崩潰恢復：啟動時讀取 Redo Log，前滾已提交交易、回滾未提交交易。
3. 清理臨時段：釋放排序、雜湊等操作產生的臨時段。
4. 處理異常終止的交易：如分散式交易失敗，SMON 協調恢復。

碎片整理觸發機制

• 實例啟動時自動執行一次。
• 運行中定期喚醒（約每 5 分鐘），檢查是否有碎片需整理。
• 可手動觸發：ALTER SYSTEM SET EVENTS 'IMMEDIATE TRACE NAME COALESCE LEVEL 1';（10g+ 建議用 DBMS_SPACE_ADMIN）。

關鍵參數：PCTINCREASE

PCTINCREASE 控制程度擴展增長比例。

• 設為 0：SMON **不會**對該表空間執行碎片合併，需人工 EXP/IMP 或 ALTER TABLESPACE ... COALESCE。
• 建議 > 0（預設 50）：讓 SMON 自動管理，減少 DBA 維護負擔。

⚠️ PCTINCREASE = 0 僅影響碎片整理，**不影響**崩潰恢復功能。Redo-based recovery 依然正常運作。

ARCH (Archiver) - 歸檔進程

運作模式

歸檔流程與效能影響

1. LGWR 寫滿當前 Redo Log Group，發起 Log Switch。
2. 若目標 Group 尚未歸檔，**LGWR 等待 ARCH 完成**（資料庫暫時掛起）。
3. ARCH 將 Redo Log 複製至 LOG_ARCHIVE_DEST_n 指定路徑（本地/遠端/ASM）。
4. 歸檔完成，LGWR 繼續寫入新 Group。

頻繁大量 DML → 頻繁 Log Switch → ARCH 壓力大 → LGWR 等待 → 吞吐量下降。

調優建議

• 多歸檔目的地：LOG_ARCHIVE_DEST_1='LOCATION=/u01/arch', LOG_ARCHIVE_DEST_2='SERVICE=standby'。
• 啟用多 ARCH 進程：LOG_ARCHIVE_MAX_PROCESSES = 4（最大 30，11g+），並行歸檔減少 LGWR 等待。
• 加大 Redo Log 檔案：延長 Log Switch 間隔（建議每 15~30 分鐘切一次）。
• 使用快速歸檔：11g+ LOG_ARCHIVE_DEST_n='LOCATION=USE_DB_RECOVERY_FILE_DEST' 配合 FRA。
• 大量載入時暫時關閉歸檔：ALTER DATABASE NOARCHIVELOG → 載入 → ALTER DATABASE ARCHIVELOG → 立即備份（需停機窗口）。

SMON vs ARCH 快速比較

理解 SMON 與 ARCH 的運作細節，並根據業務負載調整參數，是打造高可用、高效能 Oracle 環境的基石功課。