Oracle SMON 與 ARCH 進程深度解析：空間整理、實例恢復、歸檔效能優化三大策略

SMON (System Monitor) —— 人小鬼大的關鍵進程

核心職責

1. 空間碎片合併：定期掃描表空間，將相鄰自由區塊合併為較大區塊，提升空間分配效率
2. 實例恢復：非正常關閉後啟動時，讀取線上重做日志，前向滾動已提交交易、回滾未提交交易
3. 臨時段清理：清理排序、雜湊等操作產生的臨時段

PCTINCREASE 參數對 SMON 的影響

• PCTINCREASE = 0：SMON 不會對該表空間執行碎片合併
• 需 DBA 手工 EXP/IMP 重組解決碎片
• 不影響實例恢復功能 (日志讀取恢復仍正常)
• 建議：除非特殊需求 (如嚴格控制區塊大小)，勿設為 0

SMON 喚醒機制

• 實例啟動時自動執行實例恢復
• 定期喚醒檢查是否有碎片合併工作
• 其他進程可觸發 SMON 執行特定任務

ARCH (Archiver) —— 歸檔進程

運作模式

• 歸檔模式：日志切換前將滿載日志組複製至歸檔目的地，防止覆蓋
• 非歸檔模式：直接覆蓋循環使用，無 ARCH 進程
• 日志切換時若歸檔未完成，資料庫暫時掛起 等待歸檔完成

歸檔效能優化三大策略

策略一：增加 ARCH 進程數量

• 預設 1 個 ARCH，最多 10 個 (參數 LOG_ARCHIVE_MAX_PROCESSES，實際上限 9)
• LGWR 偵測等待時間長時自動啟動多 ARCH
• DBA 可手工預設啟動多個：ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES = 4;
• 與 DBWR 差異：DBWR 需 1:1 CPU 核心，ARCH 無此限制 (單 CPU 可跑多 ARCH)

策略二：調大重做日志檔案延長切換間隔

• 日志檔越大 → 切換頻率越低 → ARCH 啟動越少
• 平衡點：避免單一檔案過大導致恢復時間過長
• 建議：根據峰值產生日志量，設定 15-30 分鐘切換一次

策略三：大量載入期間暫時調整

• 初始化/大量載入時：大量 DML → 頻繁日志切換 → ARCH 風暴
• 對策：
  1. 暫時關閉歸檔模式 (無法接受任何資料遺失風險時不可用)
  2. 暫時大幅增加日志檔大小/數量
  3. 使用 NOLOGGING 操作 (如 CREATE TABLE ... NOLOGGING、ALTER INDEX ... REBUILD NOLOGGING)
• 作業完成後恢復正常配置

SMON vs ARCH 關鍵差異表

最佳實踐建議

1. 監控 V$ARCHIVE_DEST_STATUS 確保歸檔無錯誤
2. 設定多重歸檔目的地 (LOG_ARCHIVE_DEST_n) 異地備份
3. 定期檢查表空間碎片度：DBA_FREE_SPACE 統計
4. 大量載入窗口預先規劃 NOLOGGING/日志調大策略
5. 將 SMON/ARCH 視為「隱形守護者」，納入日常巡檢清單

1. 上一篇文章： Oracle 數據庫物理文件導入導出實戰指南
2. 下一篇文章： Oracle 兩表資料比對實戰：手動導出法 vs SQL 集合運算法優劣勢分析

Oracle 資料庫基礎

Oracle 監聽配置全攻略：listener.ora、tnsnames.ora、sqlnet.ora 三劍合璧

監聽器角色 獨立於數據庫進程的後台服務，監聽端口（默認 15

Oracle 分區表降低磁碟 I/O 衝突：三大分區模式選型指南

背景痛點 單表 500 萬筆，所有資料放在同一顆實體磁碟，併

Oracle 資料導入實戰：SQL Developer 完勝 TOAD 的 Excel 匯入體驗

背景 公司上線 ERP，需將大量基礎資料從 Excel 匯入

Oracle 死鎖原理圖解：從阻塞到死鎖的必然演進與犧牲者選擇機制

死鎖是並發資料庫系統的經典難題。本文以「兩會話、兩表、各一列