Oracle MTS 多執行緒伺服器配置實戰：突破記憶體限制支援高併發連線

MTS 核心價值

Oracle MTS (Multi-Threaded Server，後更名為 Shared Server) 以共享服務進程取代專用進程，在不增加物理記憶體前提下支援更多併發連線。典型場景：2GB 記憶體需支援 2000 連線，專用模式每連線 150-200KB PGA，MTS 僅 3-4MB 總共享，極大緩解記憶體壓力。

運作機制：餐廳服務生模型

• 專用模式 (Dedicated)：每位客人專屬服務生，服務佳但人力成本高（每連線一進程）
• MTS 模式：共享服務生池，客人請求 → 分派器 → 請求佇列 → 共享服務進程處理 → 回應佇列 → 分派器 → 客人

六步驟工作流程

1. 用戶端向分派器發送服務請求
2. 分派器將請求放入 SGA 請求佇列
3. 共享服務進程從佇列取出請求處理
4. 處理結果放入分派器 SGA 回應佇列
5. 分派器從回應佇列取得結果
6. 結果回傳用戶端

MTS vs Dedicated 全維度對比

關鍵配置參數

啟用 MTS 完整步驟

-- 1. 設定初始化參數 (spfile)
ALTER SYSTEM SET DISPATCHERS='(PROTOCOL=TCP)(DISPATCHERS=5)' SCOPE=SPFILE;
ALTER SYSTEM SET SHARED_SERVERS=10 SCOPE=SPFILE;
ALTER SYSTEM SET MAX_SHARED_SERVERS=100 SCOPE=SPFILE;
ALTER SYSTEM SET LARGE_POOL_SIZE=200M SCOPE=SPFILE;
ALTER SYSTEM SET SHARED_SERVER_SESSIONS=2000 SCOPE=SPFILE;

-- 2. 重啟實例生效
SHUTDOWN IMMEDIATE;
STARTUP;

-- 3. 驗證
SELECT * FROM V$DISPATCHER;
SELECT * FROM V$SHARED_SERVER;
SELECT * FROM V$QUEUE;  -- 請求/回應佇列狀態

效能調優黃金法則

1. 監控佇列等待：V$QUEUE.WAIT 持續增長 → 增加 SHARED_SERVERS
2. 觀察分派器負載：V$DISPATCHER.BUSY_RATE > 50% → 增加 DISPATCHERS
3. Large Pool 充足性：V$SGASTAT 確認 Large Pool free memory > 20%
4. 避免長時間運算佔用共享進程：報表/批次改用專用連線 (SERVER=DEDICATED in TNS)
5. 設定閒置超時：SQLNET.EXPIRE_TIME 清理死連線

連線字串區分

-- MTS 連線 (預設若啟用 MTS)
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=...)(PORT=1521))
 (CONNECT_DATA=(SERVICE_NAME=orcl)(SERVER=SHARED)))

-- 強制專用連線 (報表/批次專用)
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=...)(PORT=1521))
 (CONNECT_DATA=(SERVICE_NAME=orcl)(SERVER=DEDICATED)))

避坑清單

• ❌ CPU 已達瓶頸時強行啟用 MTS（調度開銷加劇 CPU 壓力）
• ❌ Large Pool 太小導致 UGA 分配失敗 (ORA-04031)
• ❌ 長跑 SQL 佔用共享進程導致其他會話飢餓
• ❌ 未監控 V$QUEUE/V$DISPATCHER 導致效能惡化無感知
• ✅ 混合模式：OLTP 用 MTS，DSS/批次用 Dedicated，TNS 區分

MTS 以「共享」換取「規模」，是高併發 OLTP 系統突破記憶體牆的利器。科學配置參數、持續監控佇列、混合連線策略，方能發揮最大效益。