Oracle SMON 與 ARCH 進程深度解析：碎片整理、故障恢復與歸檔效能優化

兩大「身軀渺小、作用巨大」的後台進程

SMON (System Monitor) 與 ARCH (Archiver) 常被 DBA 忽視，實則關鍵影響資料安全與效能。善用特性可減少大量人工運維。

一、SMON：系統監視進程

核心職責

1. 空間碎片合併：定期掃描表空間，將相鄰空閒區塊合併 (Coalesce)，提升空間分配效率。
2. 執行個體恢復：非正常關閉 (斷電、Crash) 後啟動時，自動讀取 Redo Log 完成：
   • 前滾：已提交交易從 Redo 寫入資料檔
   • 回滾：未提交交易回滾
3. 臨時段釋放：清理不再需要的臨時段。

管理關鍵點

1. 啟動時機

• 執行個體啟動時自動啟動
• 運行期定期喚醒檢查工作
• DBA 可透過其他進程觸發 SMON 執行特定任務

2. PCTINCREASE 參數影響

表空間屬性 PCTINCREASE = 0 時，**SMON 停止對該表空間執行碎片合併**。此時需人工 EXP/IMP 或 ALTER TABLESPACE ... COALESCE 整理。

建議： 除特殊需求 (如精確控制擴展大小)，**勿設為 0**。讓 SMON 自動管理碎片。注意：PCTINCREASE=0 不影響執行個體恢復功能。

二、ARCH：歸檔進程

運作模式

• NOARCHIVELOG：Redo Log 循環覆寫，無歸檔，僅支援離線完整備份，故障只能恢復至最近備份點。
• ARCHIVELOG：LGWR 切換前，ARCH 將滿載 Redo Log 複製至歸檔目的地，支援時間點恢復 (PITR)、線上熱備份。

效能衝擊

LGWR 切換需等待歸檔完成，**頻繁大量 DML 導致頻繁 Log Switch → ARCH 啟動頻繬 → 資料庫暫時掛起 → 效能抖動**。

三大優化策略

1. 增加 ARCH 進程數

• 預設 1 個，上限 10 個 (9i/10g) / 30 個 (11g+)
• 自動：LGWR 等待過久自動啟動額外 ARCH
• 手動：LOG_ARCHIVE_MAX_PROCESSES = n (n>1)，啟動時建立多進程
• 與 DBWR 不同：ARCH 不受 CPU 核心數限制，單 CPU 也可跑多進程

2. 增大 Redo Log 檔案延長切換間隔

Redo Log 越大 → Log Switch 越不頻繁 → ARCH 啟動間隔越長 → 效能衝擊越小。建議單組 Redo Log 容納 15~30 分鐘產生量。

3. 大量載入/初始化階段暫時調整

• NOLOGGING 操作：ALTER TABLE ... NOLOGGING、INSERT /*+ APPEND */、CREATE INDEX ... NOLOGGING 減少 Redo 產生
• 臨時增大 Redo Log：新增大尺寸 Group，載入完成再切回標準尺寸
• 斷開「大量 DML → Log Switch → ARCH」鏈條，載入完成後恢復歸檔模式

對照表：SMON vs ARCH

結語

SMON 守護空間與資料一致性，ARCH 守護可恢復性。靈活調校兩者參數，遠比單純 SQL 調優更能從根本提升系統穩定度與效能。DBA 請給這兩個「小巨人」應有的重視。