Oracle 後台進程深度解析：SMON 碎片整理與 ARCH 歸檔性能優化實戰

一、系統監視進程（SMON）：人小鬼大

核心職責

1. 表空間碎片合併：定期將各表空間的空閒碎片合併為較大連續空間，提升空間分配效率。
2. 實例恢復：實例異常終止（斷電、崩潰）後重啟時，自動讀取重做日志，前滾已提交事務、回滾未提交事務，保證數據一致性。
3. 臨時段釋放：清理不再需要的臨時段（排序、雜湊操作產生）。

關鍵參數：PCTINCREASE

若表空間 PCTINCREASE = 0，SMON 不會 對該表空間執行碎片合併。此時需手動 ALTER TABLESPACE ... COALESCE 或導出/導入重組。

-- 查看表空間 PCTINCREASE
SELECT tablespace_name, pct_increase FROM dba_tablespaces;

-- 建議：除非特殊需求（如 LOB 表空間），否則設置 > 0（如 10 或默認 50）

管理建議

• 啟動時機：實例啟動自動啟動；運行期定期喚醒檢查工作；可由其他進程觸發特定任務。
• PCTINCREASE = 0 僅影響碎片整理，不影響實例恢復功能。

二、歸檔進程（ARCH）：性能隱形殺手

工作機制

僅在歸檔模式下啟動。LGWR 切換日志組時，若目標組未歸檔，資料庫掛起等待 ARCH 完成歸檔。頻繁切換 + 慢歸檔 = 業務凍結。

優化策略 1：增加 ARCH 進程數

• 默認 1 個。LGWR 等待超時會自動啟動多個（最多 10 個）。
• 手動預啟動：ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=4 SCOPE=BOTH;（最大 10，9i 限制 9）。
• 與 DBWR 不同：DBWR 進程數受 CPU 核心數限制（1 進程/核），ARCH 無此限制（單 CPU 可跑多個）。

優化策略 2：增大重做日志文件，延長切換間隔

• 日志文件越大 → 切換越頻繁 → ARCH 啟動越少。
• 建議：單組日志 1GB~4GB（視負載），至少 4~6 組，確保切換間隔 > 15~20 分鐘。

優化策略 3：大批量數據載入時臨時調整

1. 載入前：ALTER DATABASE NOARCHIVELOG; 或增大日志文件/增加組數。
2. 載入中：使用 /*+ APPEND */ 直載路徑（最小化重做生成），或臨時設為 NOLOGGING 操作。
3. 載入後：恢復歸檔模式，執行 ALTER DATABASE ARCHIVELOG，立即進行 Level 0 備份建立基線。

總結：小進程，大影響

SMON 守護空間健康與數據一致性；ARCH 守護可恢復性但可能拖垮寫入性能。DBA 應：

• 確保 PCTINCREASE > 0 讓 SMON 自動整理碎片。
• 監控 V$ARCHIVE_DEST_STATUS、V$SESSION_WAIT (log file switch (archiving needed))。
• 根據負載預設 LOG_ARCHIVE_MAX_PROCESSES、優化日志文件大小、大載入窗口臨時調整策略。